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 for Android: free password hash cracker in your pocket

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

Message-ID: <3078c954-7863-4d32-aa03-3dc75a129592@linaro.org>
Date: Thu, 3 Apr 2025 10:48:48 +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/3/25 9:53 AM, Miquel Raynal wrote:
> Hello Tudor,
> 

Hi, Miquel!

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

okay

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

sounds good. It's common in SPI NOR too to have octal/single dtr but no
dual or quad dtr.

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

okay, the ONFI table I guess.

Cheers,
ta