So far all the chips supported in the driver apparently have support for
the same kind of operation (typically, single, dual and quad). The
future introduction of W35N chips will change that as these chips only
support single and octal modes. Let's rename the variants accordingly to
make these future additions more understandable.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/spi/winbond.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/spi/winbond.c b/drivers/mtd/nand/spi/winbond.c
index 861fb8d59760c83c3fa31879cb6ff027e7dc92ff..99b9f333eb3142999d8f73d43537f1ed9789c975 100644
--- a/drivers/mtd/nand/spi/winbond.c
+++ b/drivers/mtd/nand/spi/winbond.c
@@ -23,7 +23,7 @@
  * "X4" in the core is equivalent to "quad output" in the datasheets.
  */
 
-static SPINAND_OP_VARIANTS(read_cache_dtr_variants,
+static SPINAND_OP_VARIANTS(read_cache_dual_quad_dtr_variants,
 		SPINAND_PAGE_READ_FROM_CACHE_1S_4D_4D_OP(0, 8, NULL, 0, 80 * HZ_PER_MHZ),
 		SPINAND_PAGE_READ_FROM_CACHE_1S_1D_4D_OP(0, 2, NULL, 0, 80 * HZ_PER_MHZ),
 		SPINAND_PAGE_READ_FROM_CACHE_1S_4S_4S_OP(0, 2, NULL, 0),
@@ -213,7 +213,7 @@ static const struct spinand_info winbond_spinand_table[] = {
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xbc, 0x21),
 		     NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1),
 		     NAND_ECCREQ(1, 512),
-		     SPINAND_INFO_OP_VARIANTS(&read_cache_dtr_variants,
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_dual_quad_dtr_variants,
 					      &write_cache_variants,
 					      &update_cache_variants),
 		     0,
@@ -242,7 +242,7 @@ static const struct spinand_info winbond_spinand_table[] = {
 		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0xbf, 0x22),
 		     NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 2, 1),
 		     NAND_ECCREQ(1, 512),
-		     SPINAND_INFO_OP_VARIANTS(&read_cache_dtr_variants,
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_dual_quad_dtr_variants,
 					      &write_cache_variants,
 					      &update_cache_variants),
 		     0,

-- 
2.48.1

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.

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@linaro.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
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?

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

Hello Tudor,

On 03/04/2025 at 07:19:15 +01, Tudor Ambarus <tudor.ambarus@linaro.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@linaro.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

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