Re: [PATCH v4 02/16] spi: dt-bindings: add spi-phy-pattern-partition property
Santhosh Kumar K <[email protected]> Thu, 16 Jul 2026 11:24:15 +0530
| Newsgroups | gmane.linux.kernel.spi.devel,gmane.linux.drivers.devicetree,gmane.linux.kernel,gmane.linux.drivers.mtd |
|---|---|
| Message-ID | <[email protected]> |
Hello Krzysztof and Miquel, Apologies for the delayed response. On 22/06/26 22:41, Miquel Raynal wrote: > Hello, > >>> + spi-phy-pattern-partition: >> >> Is this specific to SPI-based MTD/NAND or rather broader - specific to >> MTD/NAND memories, regardless of interface? Feels like the second, thus >> maybe should be placed into the NAND bindings. >> >> If the first, then in below description: >> >> s/PHY/SPI PHY/ to be clear that this is about SPI, not the memory >> itself. > > As far as I know, there is no raw NAND controller with such > capability. In the raw/parallel NAND world, timings are well defined by > the ONFI specification, it covers both the bus timings and the minimal > requirements for the chips. There is a method to query what "timing mode" > the NAND chip supports, and then we tune the controller registers to fit > the highest supported timings (capped by possible controller limits). > > In the SPI world it is different. No specific timing has ever been > globally defined, so every manufacturer has its own capabilities which > are not discoverable dynamically. The routing also weights a lot. I > would say that we can safely keep this property SPI related, because it > is about the SPI bus being used with optimized timings, rather than some > kind of memory specific feature. > > The reason why we need a property in those memories for the feature to > work, is because we need to make data transfers with a known pattern, > thus requiring to read the pattern from the internal array somehow. > > Therefore, we shall indeed go for the s/PHY/SPI PHY/ naming indeed. Agreed, will replace 'PHY' with 'SPI PHY' in the description. Thanks, Santhosh. > > Thanks, > Miquèl