[PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Miquel Raynal]

Commit 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support") adds a
controller check to make sure the core will not use CR reads on
controllers not supporting them. The approach is valid but the fix is
incorrect. Unfortunately, the author could not catch it, because the
expected behavior was met. The patch indeed drops the RDCR capability,
but it does it for all controllers!

The issue comes from the use of spi_nor_spimem_check_op() which is an
internal helper dedicated to check page operations, ie. it is only used
for page reads and page programs (despite its generic name).

This helper looks for the biggest number of address bytes that can be
used for a page operation and tries 4 then 3. It then calls the usual
spi-mem helpers to do the checks. These will always fail because there
is now an inconsistency: the address cycles are forced to 4 (then 3)
bytes, but the bus width during the address cycles rightfully remains 0:
impossible, the operation is invalid.

The correct check in this case is to directly call spi_mem_supports_op()
which doesn't messes up with the operation content.

Fixes: 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/spi-nor/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index d3f8a78efd3b..1f2e312feec7 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2466,7 +2466,7 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps)
 
 		spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
 
-		if (spi_nor_spimem_check_op(nor, &op))
+		if (!spi_mem_supports_op(nor->spimem, &op))
 			nor->flags |= SNOR_F_NO_READ_CR;
 	}
 }
-- 
2.51.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH 2/2] mtd: spi-nor: Rename spi_nor_spimem_check_op()

[Miquel Raynal]

This helper really is just a little helper for internal purposes, and is
page operation oriented, despite its name. It has already been misused
in commit 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support"), so
rename it to clarify its purpose.

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

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 1f2e312feec7..8d91052cc21e 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2345,15 +2345,15 @@ int spi_nor_hwcaps_pp2cmd(u32 hwcaps)
 }
 
 /**
- * spi_nor_spimem_check_op - check if the operation is supported
- *                           by controller
+ * spi_nor_spimem_check_page_op - check if a page operation is supported
+ *                                by controller
  *@nor:        pointer to a 'struct spi_nor'
  *@op:         pointer to op template to be checked
  *
  * Returns 0 if operation is supported, -EOPNOTSUPP otherwise.
  */
-static int spi_nor_spimem_check_op(struct spi_nor *nor,
-				   struct spi_mem_op *op)
+static int spi_nor_spimem_check_page_op(struct spi_nor *nor,
+					struct spi_mem_op *op)
 {
 	/*
 	 * First test with 4 address bytes. The opcode itself might
@@ -2396,7 +2396,7 @@ static int spi_nor_spimem_check_readop(struct spi_nor *nor,
 	if (spi_nor_protocol_is_dtr(nor->read_proto))
 		op.dummy.nbytes *= 2;
 
-	return spi_nor_spimem_check_op(nor, &op);
+	return spi_nor_spimem_check_page_op(nor, &op);
 }
 
 /**
@@ -2414,7 +2414,7 @@ static int spi_nor_spimem_check_pp(struct spi_nor *nor,
 
 	spi_nor_spimem_setup_op(nor, &op, pp->proto);
 
-	return spi_nor_spimem_check_op(nor, &op);
+	return spi_nor_spimem_check_page_op(nor, &op);
 }
 
 /**
-- 
2.51.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 2/2] mtd: spi-nor: Rename spi_nor_spimem_check_op()

[Tudor Ambarus]

On 1/8/26 2:14 PM, Miquel Raynal wrote:
> This helper really is just a little helper for internal purposes, and is
> page operation oriented, despite its name. It has already been misused
> in commit 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support"), so
> rename it to clarify its purpose.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  drivers/mtd/spi-nor/core.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 1f2e312feec7..8d91052cc21e 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2345,15 +2345,15 @@ int spi_nor_hwcaps_pp2cmd(u32 hwcaps)
>  }
>  
>  /**
> - * spi_nor_spimem_check_op - check if the operation is supported
> - *                           by controller
> + * spi_nor_spimem_check_page_op - check if a page operation is supported
> + *                                by controller
>   *@nor:        pointer to a 'struct spi_nor'
>   *@op:         pointer to op template to be checked
>   *
>   * Returns 0 if operation is supported, -EOPNOTSUPP otherwise.
>   */
> -static int spi_nor_spimem_check_op(struct spi_nor *nor,
> -				   struct spi_mem_op *op)
> +static int spi_nor_spimem_check_page_op(struct spi_nor *nor,
> +					struct spi_mem_op *op)

page is a bit misleading as it can indicate it's used just for page
programs. We need to focus on operations that need address bytes,
reads, pp, page scrub, erase, write/read any register, etc.

Maybe rename it to spi_nor_spimem_check_mem_op?
Or spi_nor_spimem_check_addr_op?

Cheers,
ta
>  {
>  	/*
>  	 * First test with 4 address bytes. The opcode itself might
> @@ -2396,7 +2396,7 @@ static int spi_nor_spimem_check_readop(struct spi_nor *nor,
>  	if (spi_nor_protocol_is_dtr(nor->read_proto))
>  		op.dummy.nbytes *= 2;
>  
> -	return spi_nor_spimem_check_op(nor, &op);
> +	return spi_nor_spimem_check_page_op(nor, &op);
>  }
>  
>  /**
> @@ -2414,7 +2414,7 @@ static int spi_nor_spimem_check_pp(struct spi_nor *nor,
>  
>  	spi_nor_spimem_setup_op(nor, &op, pp->proto);
>  
> -	return spi_nor_spimem_check_op(nor, &op);
> +	return spi_nor_spimem_check_page_op(nor, &op);
>  }
>  
>  /**


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 2/2] mtd: spi-nor: Rename spi_nor_spimem_check_op()

[Miquel Raynal]

>> -static int spi_nor_spimem_check_op(struct spi_nor *nor,
>> -				   struct spi_mem_op *op)
>> +static int spi_nor_spimem_check_page_op(struct spi_nor *nor,
>> +					struct spi_mem_op *op)
>
> page is a bit misleading as it can indicate it's used just for page
> programs. We need to focus on operations that need address bytes,
> reads, pp, page scrub, erase, write/read any register, etc.

This helper is only used for reads and page programs. The point is
to not use it when reading/writing registers.

What about spi_nor_spimem_check_io_op() ? or _iorw_op() ?

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 2/2] mtd: spi-nor: Rename spi_nor_spimem_check_op()

[Tudor Ambarus]

On 3/17/26 11:33 AM, Miquel Raynal wrote:
> 
>>> -static int spi_nor_spimem_check_op(struct spi_nor *nor,
>>> -				   struct spi_mem_op *op)
>>> +static int spi_nor_spimem_check_page_op(struct spi_nor *nor,
>>> +					struct spi_mem_op *op)
>>
>> page is a bit misleading as it can indicate it's used just for page
>> programs. We need to focus on operations that need address bytes,
>> reads, pp, page scrub, erase, write/read any register, etc.
> 
> This helper is only used for reads and page programs. The point is
> to not use it when reading/writing registers.
> 

you're right, it comes from hwcaps, where we verify the reads and pp.

> What about spi_nor_spimem_check_io_op() ? or _iorw_op() ?

spi_nor_spimem_check_hwcaps_op?

IO is involved with read/write any reg.
rw may work, but it can be applied to registers too.

or maybe spi_nor_spimem_check_read_pp_op?

I'm sure you'll choose the best, go ahead with what works for you.

Cheers,
ta

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 2/2] mtd: spi-nor: Rename spi_nor_spimem_check_op()

[Miquel Raynal]

On 17/03/2026 at 13:39:36 +02, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:

> On 3/17/26 11:33 AM, Miquel Raynal wrote:
>> 
>>>> -static int spi_nor_spimem_check_op(struct spi_nor *nor,
>>>> -				   struct spi_mem_op *op)
>>>> +static int spi_nor_spimem_check_page_op(struct spi_nor *nor,
>>>> +					struct spi_mem_op *op)
>>>
>>> page is a bit misleading as it can indicate it's used just for page
>>> programs. We need to focus on operations that need address bytes,
>>> reads, pp, page scrub, erase, write/read any register, etc.
>> 
>> This helper is only used for reads and page programs. The point is
>> to not use it when reading/writing registers.
>> 
>
> you're right, it comes from hwcaps, where we verify the reads and pp.
>
>> What about spi_nor_spimem_check_io_op() ? or _iorw_op() ?
>
> spi_nor_spimem_check_hwcaps_op?
>
> IO is involved with read/write any reg.
> rw may work, but it can be applied to registers too.
>
> or maybe spi_nor_spimem_check_read_pp_op?

Ah, this one I almost proposed it, so let's go for it!

Thanks for the feedback!

Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Miquel Raynal]

Hello SPI NOR folks :-)

+ Takahiro

On 08/01/2026 at 13:14:29 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> Commit 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support") adds a
> controller check to make sure the core will not use CR reads on
> controllers not supporting them. The approach is valid but the fix is
> incorrect. Unfortunately, the author could not catch it, because the
> expected behavior was met. The patch indeed drops the RDCR capability,
> but it does it for all controllers!
>
> The issue comes from the use of spi_nor_spimem_check_op() which is an
> internal helper dedicated to check page operations, ie. it is only used
> for page reads and page programs (despite its generic name).
>
> This helper looks for the biggest number of address bytes that can be
> used for a page operation and tries 4 then 3. It then calls the usual
> spi-mem helpers to do the checks. These will always fail because there
> is now an inconsistency: the address cycles are forced to 4 (then 3)
> bytes, but the bus width during the address cycles rightfully remains 0:
> impossible, the operation is invalid.
>
> The correct check in this case is to directly call spi_mem_supports_op()
> which doesn't messes up with the operation content.
>
> Fixes: 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support")
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

These two patches are fixes which need to get in, I'd like to pick them
for the next fixes MTD PR that I am preparing, but I was expecting some
kind of acknowledgement on it.

Cheng Ming already faced the same issue on his side an identical patch
already.

Thanks,
Miquèl

> ---
>  drivers/mtd/spi-nor/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index d3f8a78efd3b..1f2e312feec7 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2466,7 +2466,7 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps)
>  
>  		spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
>  
> -		if (spi_nor_spimem_check_op(nor, &op))
> +		if (!spi_mem_supports_op(nor->spimem, &op))
>  			nor->flags |= SNOR_F_NO_READ_CR;
>  	}
>  }

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Tudor Ambarus]

On 3/9/26 4:55 PM, Miquel Raynal wrote:
> Hello SPI NOR folks :-)
> 
> + Takahiro
> 
> On 08/01/2026 at 13:14:29 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> 
>> Commit 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support") adds a
>> controller check to make sure the core will not use CR reads on
>> controllers not supporting them. The approach is valid but the fix is
>> incorrect. Unfortunately, the author could not catch it, because the
>> expected behavior was met. The patch indeed drops the RDCR capability,
>> but it does it for all controllers!
>>
>> The issue comes from the use of spi_nor_spimem_check_op() which is an
>> internal helper dedicated to check page operations, ie. it is only used
>> for page reads and page programs (despite its generic name).
>>
>> This helper looks for the biggest number of address bytes that can be
>> used for a page operation and tries 4 then 3. It then calls the usual
>> spi-mem helpers to do the checks. These will always fail because there
>> is now an inconsistency: the address cycles are forced to 4 (then 3)
>> bytes, but the bus width during the address cycles rightfully remains 0:
>> impossible, the operation is invalid.

I like Cheng's details on how it's failing. Would you please add what he
detailed there?
```
This modified operation is then rejected by spi_mem_check_op() in the
core spi-mem.c because it has a non-zero address length but a zero address
buswidth, which is an invalid combination.
```
Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>

>>
>> The correct check in this case is to directly call spi_mem_supports_op()
>> which doesn't messes up with the operation content.
>>
>> Fixes: 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support")
>> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> 
> These two patches are fixes which need to get in, I'd like to pick them
> for the next fixes MTD PR that I am preparing, but I was expecting some
> kind of acknowledgement on it.
> 
> Cheng Ming already faced the same issue on his side an identical patch
> already.
> 
> Thanks,
> Miquèl
> 
>> ---
>>  drivers/mtd/spi-nor/core.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index d3f8a78efd3b..1f2e312feec7 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -2466,7 +2466,7 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps)
>>  
>>  		spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
>>  
>> -		if (spi_nor_spimem_check_op(nor, &op))
>> +		if (!spi_mem_supports_op(nor->spimem, &op))
>>  			nor->flags |= SNOR_F_NO_READ_CR;
>>  	}
>>  }


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Tudor Ambarus]

On 3/10/26 11:24 AM, Tudor Ambarus wrote:
> for page reads and page programs (despite its generic name).
ah, and there's no such thing as page reads in SPI NORs, one can use
a single read instruction to read the entire flash memory. We all
understood what you meant, but please reword this so that's clear for
newcomers.

Cheers,
ta


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Miquel Raynal]

On 10/03/2026 at 11:38:47 +02, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:

> On 3/10/26 11:24 AM, Tudor Ambarus wrote:
>> for page reads and page programs (despite its generic name).
> ah, and there's no such thing as page reads in SPI NORs, one can use
> a single read instruction to read the entire flash memory. We all
> understood what you meant, but please reword this so that's clear for
> newcomers.

True. I changed the commit log and mentioned "reads and writes" instead.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Miquel Raynal]

Hello,

>>> These will always fail because there
>>> is now an inconsistency: the address cycles are forced to 4 (then 3)
>>> bytes, but the bus width during the address cycles rightfully remains 0:
>>> impossible, the operation is invalid.
>
> I like Cheng's details on how it's failing. Would you please add what he
> detailed there?
> ```
> This modified operation is then rejected by spi_mem_check_op() in the
> core spi-mem.c because it has a non-zero address length but a zero address
> buswidth, which is an invalid combination.
> ```

I've added the precision about the invalid combination of non-zero
address length and zero bus width. I feel like it's a repetition of my
previous sentence, but I'm fine with it if it clarifies.

Thanks!
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Tudor Ambarus]

On 3/17/26 11:20 AM, Miquel Raynal wrote:
> Hello,
> 
>>>> These will always fail because there
>>>> is now an inconsistency: the address cycles are forced to 4 (then 3)
>>>> bytes, but the bus width during the address cycles rightfully remains 0:
>>>> impossible, the operation is invalid.
>>
>> I like Cheng's details on how it's failing. Would you please add what he
>> detailed there?
>> ```
>> This modified operation is then rejected by spi_mem_check_op() in the
>> core spi-mem.c because it has a non-zero address length but a zero address
>> buswidth, which is an invalid combination.
>> ```
> 
> I've added the precision about the invalid combination of non-zero
> address length and zero bus width. I feel like it's a repetition of my

oh, yes, I missed that.

> previous sentence, but I'm fine with it if it clarifies.

I'm fine either way. Thanks!

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Takahiro.Kuwano]

> Hello SPI NOR folks :-)
> 
> + Takahiro
> 
Hello!

> On 08/01/2026 at 13:14:29 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> 
> > Commit 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support") adds a
> > controller check to make sure the core will not use CR reads on
> > controllers not supporting them. The approach is valid but the fix is
> > incorrect. Unfortunately, the author could not catch it, because the
> > expected behavior was met. The patch indeed drops the RDCR capability,
> > but it does it for all controllers!
> >
> > The issue comes from the use of spi_nor_spimem_check_op() which is an
> > internal helper dedicated to check page operations, ie. it is only used
> > for page reads and page programs (despite its generic name).
> >
> > This helper looks for the biggest number of address bytes that can be
> > used for a page operation and tries 4 then 3. It then calls the usual
> > spi-mem helpers to do the checks. These will always fail because there
> > is now an inconsistency: the address cycles are forced to 4 (then 3)
> > bytes, but the bus width during the address cycles rightfully remains 0:
> > impossible, the operation is invalid.
> >
> > The correct check in this case is to directly call spi_mem_supports_op()
> > which doesn't messes up with the operation content.
> >
> > Fixes: 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support")
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> 
> These two patches are fixes which need to get in, I'd like to pick them
> for the next fixes MTD PR that I am preparing, but I was expecting some
> kind of acknowledgement on it.
> 
> Cheng Ming already faced the same issue on his side an identical patch
> already.
> 
> Thanks,
> Miquèl
> 
> > ---
> >  drivers/mtd/spi-nor/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > index d3f8a78efd3b..1f2e312feec7 100644
> > --- a/drivers/mtd/spi-nor/core.c
> > +++ b/drivers/mtd/spi-nor/core.c
> > @@ -2466,7 +2466,7 @@ spi_nor_spimem_adjust_hwcaps(struct spi_nor *nor, u32 *hwcaps)
> >
> >               spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
> >
> > -             if (spi_nor_spimem_check_op(nor, &op))
> > +             if (!spi_mem_supports_op(nor->spimem, &op))
> >                       nor->flags |= SNOR_F_NO_READ_CR;
> >       }
> >  }

Acked-by: Takahiro Kuwano <takahiro.kuwano@infineon.com>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Pratyush Yadav]

On Mon, Mar 09 2026, Miquel Raynal wrote:

> Hello SPI NOR folks :-)
>
> + Takahiro
>
> On 08/01/2026 at 13:14:29 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
>> Commit 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support") adds a
>> controller check to make sure the core will not use CR reads on
>> controllers not supporting them. The approach is valid but the fix is
>> incorrect. Unfortunately, the author could not catch it, because the
>> expected behavior was met. The patch indeed drops the RDCR capability,
>> but it does it for all controllers!
>>
>> The issue comes from the use of spi_nor_spimem_check_op() which is an
>> internal helper dedicated to check page operations, ie. it is only used
>> for page reads and page programs (despite its generic name).
>>
>> This helper looks for the biggest number of address bytes that can be
>> used for a page operation and tries 4 then 3. It then calls the usual
>> spi-mem helpers to do the checks. These will always fail because there
>> is now an inconsistency: the address cycles are forced to 4 (then 3)
>> bytes, but the bus width during the address cycles rightfully remains 0:
>> impossible, the operation is invalid.
>>
>> The correct check in this case is to directly call spi_mem_supports_op()
>> which doesn't messes up with the operation content.
>>
>> Fixes: 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support")
>> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>
> These two patches are fixes which need to get in, I'd like to pick them
> for the next fixes MTD PR that I am preparing, but I was expecting some
> kind of acknowledgement on it.

With Tudor's suggestions:

Reviewed-by: Pratyush Yadav <pratyush@kernel.org>

I am going through the SPI NOR patch backlog. Since you plan to take
these directly via mtd/fixes, I'll not queue these.

[...]

-- 
Regards,
Pratyush Yadav

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Miquel Raynal]

On 13/03/2026 at 11:10:50 GMT, Pratyush Yadav <pratyush@kernel.org> wrote:

> On Mon, Mar 09 2026, Miquel Raynal wrote:
>
>> Hello SPI NOR folks :-)
>>
>> + Takahiro
>>
>> On 08/01/2026 at 13:14:29 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>>
>>> Commit 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support") adds a
>>> controller check to make sure the core will not use CR reads on
>>> controllers not supporting them. The approach is valid but the fix is
>>> incorrect. Unfortunately, the author could not catch it, because the
>>> expected behavior was met. The patch indeed drops the RDCR capability,
>>> but it does it for all controllers!
>>>
>>> The issue comes from the use of spi_nor_spimem_check_op() which is an
>>> internal helper dedicated to check page operations, ie. it is only used
>>> for page reads and page programs (despite its generic name).
>>>
>>> This helper looks for the biggest number of address bytes that can be
>>> used for a page operation and tries 4 then 3. It then calls the usual
>>> spi-mem helpers to do the checks. These will always fail because there
>>> is now an inconsistency: the address cycles are forced to 4 (then 3)
>>> bytes, but the bus width during the address cycles rightfully remains 0:
>>> impossible, the operation is invalid.
>>>
>>> The correct check in this case is to directly call spi_mem_supports_op()
>>> which doesn't messes up with the operation content.
>>>
>>> Fixes: 5008c3ec3f89 ("mtd: spi-nor: core: Check read CR support")
>>> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>>
>> These two patches are fixes which need to get in, I'd like to pick them
>> for the next fixes MTD PR that I am preparing, but I was expecting some
>> kind of acknowledgement on it.
>
> With Tudor's suggestions:
>
> Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
>
> I am going through the SPI NOR patch backlog. Since you plan to take
> these directly via mtd/fixes, I'll not queue these.

I was too busy this week to follow-up, but indeed I might just apply
with the suggestions from Tudor if I'm able to send a fixes PR by
Saturday, otherwise I'll go for the normal route and submit a v2. Patch
2 however is not eligible for -fixes, it clearly is an enhancement that
is not a bug fix or whatever, so you can take it when I send a v2
through SPI NOR next, as AFAIR it will not conflict with patch 1.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH 1/2] mtd: spi-nor: Fix RDCR controller capability core check

[Pratyush Yadav]

On Fri, Mar 13 2026, Miquel Raynal wrote:

> On 13/03/2026 at 11:10:50 GMT, Pratyush Yadav <pratyush@kernel.org> wrote:
>
>> On Mon, Mar 09 2026, Miquel Raynal wrote:
[...]
>>>
>>> These two patches are fixes which need to get in, I'd like to pick them
>>> for the next fixes MTD PR that I am preparing, but I was expecting some
>>> kind of acknowledgement on it.
>>
>> With Tudor's suggestions:
>>
>> Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
>>
>> I am going through the SPI NOR patch backlog. Since you plan to take
>> these directly via mtd/fixes, I'll not queue these.
>
> I was too busy this week to follow-up, but indeed I might just apply
> with the suggestions from Tudor if I'm able to send a fixes PR by
> Saturday, otherwise I'll go for the normal route and submit a v2. Patch
> 2 however is not eligible for -fixes, it clearly is an enhancement that
> is not a bug fix or whatever, so you can take it when I send a v2
> through SPI NOR next, as AFAIR it will not conflict with patch 1.

Sounds good.

-- 
Regards,
Pratyush Yadav

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/