Re: [PATCH 2/3] mtd: spi-nor: use rdid-dummy-ncycles DT property

["Michael Walle" <mwalle@kernel.org>]

On Thu Mar 20, 2025 at 12:30 AM CET, Rob Herring wrote:
> On Wed, Mar 19, 2025 at 06:47:44PM +0900, Takahiro Kuwano wrote:
> > There are infineon flashes [1] that require 8 dummy cycles for the
> > 1-1-1 Read ID command. Since the command is not covered by JESD216
> > or any other standard, get the number of dummy cycles from DT and use
> > them to correctly identify the flash.
>
> If Read ID fails, then couldn't you just retry with dummy cycles? Or 
> would unconditionally adding dummy cycles adversely affect other chips?

Yes exactly. IIUC, the first byte of the auto discovery (RDID
command) would return random data, because the output driver of the
flash is disabled. The second byte would then return the
manufacturer id and third and fourth the device id. This makes auto
discovery fundamentally broken with this chip as the first byte
might randomly match any manufacturer within our database.

Takahiro, if you can reach designer of this chip, you might tell
them, that this was not the greatest idea :o

> Otherwise, add a specific compatible to imply this requirement. Adding 
> quirk properties doesn't scale.

Since auto discovery doesn't work at all, you might just add,
"infineon,cyrs17b512" *instead of* "jedec,spi-nor" (because it doesn't
support the usual RDID command").

Alternatively, we could introduce a "generic" compatible which just
uses the standard RDSFDP command instead of RDID for discovery. Rob?
Then we'd need some SFDP fingerprinting mechanism to match the SFDP
to a particular flash type.

-michael

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/