On 17/03/2020 11.02, Wolfgang Denk wrote: > Dear Rasmus, > > In message <[email protected]> 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
