[PATCH] mtd: spi-nor-core: call WATCHDOG_RESET() in spi_nor_ready()

[Vignesh Raghavendra]

On 19/03/20 6:14 pm, Rasmus Villemoes wrote:
>> Hmm, Watchdog seems to be set to trigger after ~2s of inactivity. Isn't
>> that too small? WATCHDOG_RESET() resets only once per second, so 2
>> second timeout is too close IMO.
>>
>> Typical watchdog timeouts are usually in tens of seconds
> Nope, not with this external gpio-triggered one. The data sheet says
> 
> Watchdog timeout period 1.12/1.60/2.24 (min/typ/max)
> 
> so ~2 seconds sounds about right - and I have to account for other
> instances of the board that may be a lot closer to the minimum. The
> timeout is fixed, nothing in software can affect it. So you see why I
> cannot afford to let spi flash operations take several seconds to
> complete without a WATCHDOG_RESET().
> 
> And yes, I'm very well aware of the rate-limiting imposed by the
> wdt-provided watchdog_reset() function - that's mostly a solved problem:
> https://patchwork.ozlabs.org/project/uboot/list/?series=164254
> 

Understood.

> For the read side, it seems that just replacing the UINT_MAX in the two
> copies of spi_nor_read_data with some smaller constant should suffice.
> But I don't know if I should make that smaller constant a CONFIG_*
> option or just pick something like 256K. Thoughts?

Breaking reads into smaller units unconditionally will cause performance
regressions. But I would like to avoid adding new CONFIG option as well.

How about resetting the watchdog in the SPI driver's read
implementation? Or setting max_read_size (in struct spi_slave) to
smaller value in the SPI controller driver to force fragmentation of reads?