[PATCH] powerpc: remove WATCHDOG_RESET call from wait_ticks()

[Rasmus Villemoes]

On 17/03/2020 11.02, Wolfgang Denk wrote:
> Dear Rasmus,
> 
> In message <20200316212337.30204-1-rasmus.villemoes at 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