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: <D8KX1NO755U3.2HC0O2OX5MJUL@kernel.org>
Date: Thu, 20 Mar 2025 08:30:43 +0100
From: "Michael Walle" <mwalle@...nel.org>
To: "Rob Herring" <robh@...nel.org>, "Takahiro Kuwano"
 <tkuw584924@...il.com>
Cc: "Tudor Ambarus" <tudor.ambarus@...aro.org>, "Pratyush Yadav"
 <pratyush@...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 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