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: <a3818477-5a67-43ad-8961-88fa02916968@linaro.org>
Date: Thu, 20 Mar 2025 07:44:50 +0000
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Rob Herring <robh@...nel.org>, Takahiro Kuwano <tkuw584924@...il.com>
Cc: 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

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"? 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.

Thanks,
ta