Re: AW: [PATCH 1/4] spi: Add parameter for clock to rx delay

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Fri, Oct 27, 2023 at 08:38:54AM +0000, Stoll, Eberhard wrote:

...

> > Can you be more specific? I am wondering how big the need is.
> 
> In our case it's a QSPI NAND chip (Winbond W25N02KV). This device
> can operate at 104MHz SPI clock. But it also has a tCLQV value of 7ns.
> The tCLQV value limits the SPI clock speed for this device to 2x7ns
> (if it is not adjustable in the SPI controller) which is approximately
> 70MHz.
> 
> Without the ability to set the tCLQV value, the SPI clock has to be
> limited to 70MHz in device tree for this bus.
> 
> In our case the Winbond W25N02KV chip is a replacement of an
> older chip. The older chip can operate at 104MHz and does not
> have the tCLQV restrictions as this new one.
> The new chip is mostly is better than the data sheet and meet the
> timing requirements for 104MHz. But on higher temperatures
> devices fail.
> 
> In device tree QSPI NAND chips are configured by a compatible
> property of 'spi-nand'. The mtd layer detects the real device
> and fetches the properties of this device from the appropriate
> driver.
> 
> So for our case (boards containing the old and new chip) we well
> have to reduce the SPI clock for the entire QSPI bus to 70MHz, even
> for the elder chips which can operate well also with 104MHz. 

So, to me sounds like device tree source issue. I.e. you need to provide
different DT(b)s depending on the platform (and how it should be).
The cleanest solution (as I see not the first time people I trying quirks like
this to be part of the subsystems / drivers) is to make DT core (OF) to have
conditionals or boot-time modifications allowed.

This, what you are doing, does not scale and smells like an ugly hack.

-- 
With Best Regards,
Andy Shevchenko