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: <87cydty6aq.fsf@bootlin.com>
Date: Thu, 03 Apr 2025 10:53:49 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Tudor Ambarus <tudor.ambarus@...aro.org>
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

Hello Tudor,

On 03/04/2025 at 07:19:15 +01, Tudor Ambarus <tudor.ambarus@...aro.org> wrote:

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

Yes, I do not know any chip not supporting single SDR mode, just because
we need a common ground to perform the discovery? The core would anyway
not be ready for such chips if they were about to come.

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

Unfortunately not. Chips supporting quad may also support dual, but not
always. These chips flagged 'dual_quad' indeed support both. However in
this particular case, octal chips do not support dual or quad
opcodes. Hence my idea to name the variants about what is supported,
behind 1S opcodes.

> 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 at all! SPI NANDs commonly advertise a parameter page which is way
more succinct, but no SFDP table.

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

Ok, thanks.

Miquèl