linux-kernel - Re: [PATCH 15/21] mtd: spinand: winbond: Rename DTR variants

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: <5463acad-ee29-45de-9d22-16eb7947002c@linaro.org>
Date: Thu, 3 Apr 2025 07:19:15 +0100
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: Richard Weinberger <richard@....at>, Vignesh Raghavendra
 <vigneshr@...com>, Santhosh Kumar K <s-k6@...com>,
 Pratyush Yadav <pratyush@...nel.org>, Michael Walle <michael@...le.cc>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 Steam Lin <stlin2@...bond.com>, linux-mtd@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 15/21] mtd: spinand: winbond: Rename DTR variants

On 4/2/25 5:57 PM, Miquel Raynal wrote:
> Hello Tudor,
> 
> First, thanks a lot for the time spent reviewing, much appreciated.
> 
> On 02/04/2025 at 16:19:00 +01, Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
> 
>> Hi, Miquel,
>>
>> On 3/7/25 3:08 PM, Miquel Raynal wrote:
>>> -static SPINAND_OP_VARIANTS(read_cache_dtr_variants,
>>> +static SPINAND_OP_VARIANTS(read_cache_dual_quad_dtr_variants,
>>
>> why not read_cache_single_dual_quad_dtr_variants? I see single dtr too
>> in the supported ops.
> 
> That's true, but single modes are literally always supported, so it is

literally, meaning from experience I guess, or is it mandatory that
dual, quad or octal dtr to imply single dtr as well? That's fine either
way, just curious.

Does quad dtr imply dual dtr? And octal dtr imply quad dtr and dual dtr?
If so, then maybe name it by the maximum IO dtr supported.

btw, not strictly related to this patch, but for the overall
architecture picture, why do the SPI NAND flashes need to define their
supported ops? SPI NORs for example are capable of discovering their
supported ops by parsing at runtime some SFDP tables that describe most
of the flash parameters and setting. I see SFDP standard (jesd216g)
mentions SPI NAND devices as well. Have you or anybody else played with
SPI NANDs SFDP?

> not very discriminant, and here my goal is to differentiate the variants
> supported by the dual/quad chips vs. the variants supported by the octal
> chips (which are not capable of dual/quad transfers). What do you think?

I find it fine to differentiate between the variants.