On 17/03/2020 11.02, Wolfgang Denk wrote:
Dear Rasmus,
In message 20200316212337.30204-1-rasmus.villemoes@prevas.dk you wrote:
wait_ticks() is only used by the ppc-specific __udelay() function. Having the powerpc version of __udelay implicitly call WATCHDOG_RESET() is inconsistent with other architectures' (and the generic __udelay() in lib/time.c) implementations. It also means a driver cannot use __udelay() as the raw primitive it is supposed to be
- e.g. a watchdog driver that needs to do a short delay between two
operations needed to perform a ping sequence.
Many PPC processors implement the watchdog differently than other sysytems - for example, on many systems the watchdog is automatically enabled after power on / reset.
Yes, and? I don't see why the __udelay() implementation on ppc should have a watchdog_reset call when the generic udelay() function already has, and no other __udelay has - that makes it very hard to reason about what kind of code might get called if one chooses udelay() vs __udelay(). While the SOC's watchdog typically only requires poking a few mmapped registers, there are other cases of a watchdog_reset implementation (e.g. the generic one one gets from CONFIG_WDT) that is quite a lot more involved.
Or do you not agree that __udelay is supposed to be a raw primitive that does the delay and nothing else?
There are not that many __udelay() calls, so I doubt this causes a regression for anyone. Callers of udelay() are not affected, since udelay() itself does one WATCHDOG_RESET() per __udelay() call.
Which exact platforms have you tested this on?
An MPC8309-derived board which does not utilize the SOCs watchdog but has an external gpio-triggered (always-running) watchdog circuit.
Rasmus