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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqKtz5+R1kjEzjo6bVicOX2c=UauC0_STAF0T02rSDqO+w@mail.gmail.com>
Date: Thu, 20 Mar 2025 09:06:44 -0500
From: Rob Herring <robh@...nel.org>
To: Tudor Ambarus <tudor.ambarus@...aro.org>
Cc: Takahiro Kuwano <tkuw584924@...il.com>, Pratyush Yadav <pratyush@...nel.org>, 
	Michael Walle <mwalle@...nel.org>, Miquel Raynal <miquel.raynal@...tlin.com>, 
	Richard Weinberger <richard@....at>, Vignesh Raghavendra <vigneshr@...com>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-mtd@...ts.infradead.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Bacem Daassi <Bacem.Daassi@...ineon.com>, Takahiro Kuwano <Takahiro.Kuwano@...ineon.com>
Subject: Re: [PATCH 2/3] mtd: spi-nor: use rdid-dummy-ncycles DT property

On Thu, Mar 20, 2025 at 2:44 AM Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
>
> Hi, Rob,
>
> On 3/19/25 11:30 PM, 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
>
> I think Read ID won't fail when the op requires 8 dummy cycles, it
> probably just reads garbage on the first 8 cycles, so we risk to wrongly
> match other flash IDs.
>
> > would unconditionally adding dummy cycles adversely affect other chips?
>
> Adding 8 dummy cycles to chips that don't need it, would mean ignoring
> the first byte of the flash ID, thus we again risk to wrongly match
> against other flash IDs.
>
> >
> > Otherwise, add a specific compatible to imply this requirement. Adding
> > quirk properties doesn't scale.
>
> Do you mean a flash name compatible, like "cyrs17b512,spi-nor"?

Yes, but that's not the format of compatible strings.

> The
> problem that I see with that is that we no longer bind against the
> generic jedec,spi-nor compatible, so people need to update their DT in
> case they use/plug-in a different flash on their board.

This chip is clearly *not* compatible with a generic chip.

You have the same problem with a property. Users have to add or remove
the property if the flash changes. Anyone thinking they can use this
chip as a compatible 2nd source is SOL.

Rob