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

[Rasmus Villemoes]

On 19/03/2020 14.23, Vignesh Raghavendra wrote:
> 

>> 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.

Hm, but how much are we talking about? I can't imagine WATCHDOG_RESET()
taking much more than 10us - especially the rate-limited one that has an
early return just based on reading the current time will be practically
free to call. For me, reading 256K takes about 200ms, which I assume is
a rather typical value. Even if I'm off by an order of magnitude on both
numbers, we're talking about adding an extra 100us for every 20ms, i.e.
0.5%. And that's extremely pessimistic.

> How about resetting the watchdog in the SPI driver's read
> implementation? 

I'd prefer something done in the generic layer, not something specific
to this SOC (because next month I'll have another customer with another
board based on some ARM SOC that also decided to put on an aggressive
gpio watchdog, and next month yet another...).

Or setting max_read_size (in struct spi_slave) to
> smaller value in the SPI controller driver to force fragmentation of reads?

Even if one forces fragmentation in that way, the generic layer would
still need to grow a WATCHDOG_RESET() call in the read loop, no? It also
seems to be an abuse of max_read_size.

Rasmus