[PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP

[PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP

[Bean Huo]

From: Bean Huo <beanhuo@micron.com>

micron_st_nor_ready() falls back to SR-only polling when the SPI
controller does not support low-level FSR reads, but only checks for
-EOPNOTSUPP (95).  Some SPI master drivers return the kernel-internal
-ENOTSUPP (524) for the same condition.  The two codes carry identical
semantics but have different numeric values, so the fallback is never
reached when the master returns -ENOTSUPP; the function propagates the
error instead, causing all subsequent erase/program operations on the
Micron flash to fail.

Fix this by treating -ENOTSUPP equivalently to -EOPNOTSUPP in the FSR
error path.  Note that spi-mem.c already treats both error codes as
equivalent in its own fallback logic, so this aligns micron_st_nor_ready()
with that existing convention.

Fixes: 90c517f435a9 ("mtd: spi-nor: micron-st: Skip FSR reading if SPI controller does not support it")
Reported-by: Zailiang Zhang <zaizhang@cisco.com>
Signed-off-by: Bean Huo <beanhuo@micron.com>
---
 drivers/mtd/spi-nor/micron-st.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c
index 88033384a71e..4be6a76fc3e5 100644
--- a/drivers/mtd/spi-nor/micron-st.c
+++ b/drivers/mtd/spi-nor/micron-st.c
@@ -598,7 +598,7 @@ static int micron_st_nor_ready(struct spi_nor *nor)
 		 * operations to the software. If this is the case we use
 		 * only the status register value.
 		 */
-		return ret == -EOPNOTSUPP ? sr_ready : ret;
+		return (ret == -EOPNOTSUPP || ret == -ENOTSUPP) ? sr_ready : ret;
 	}
 
 	if (nor->bouncebuf[0] & (FSR_E_ERR | FSR_P_ERR)) {
-- 
2.34.1

Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP

[Tudor Ambarus]

Hi, Bean!

On 3/18/26 3:18 PM, Bean Huo wrote:
> From: Bean Huo <beanhuo@micron.com>
> 
> micron_st_nor_ready() falls back to SR-only polling when the SPI
> controller does not support low-level FSR reads, but only checks for
> -EOPNOTSUPP (95).  Some SPI master drivers return the kernel-internal
> -ENOTSUPP (524) for the same condition.  The two codes carry identical

Isn't it a better fix to update the spi controllers to use EOPNOTSUPP?

Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP

[Bean Huo]

On Wed, 2026-03-18 at 15:26 +0200, Tudor Ambarus wrote:
> Hi, Bean!
> 
> On 3/18/26 3:18 PM, Bean Huo wrote:
> > From: Bean Huo <beanhuo@micron.com>
> > 
> > micron_st_nor_ready() falls back to SR-only polling when the SPI
> > controller does not support low-level FSR reads, but only checks for
> > -EOPNOTSUPP (95).  Some SPI master drivers return the kernel-internal
> > -ENOTSUPP (524) for the same condition.  The two codes carry identical
> 
> Isn't it a better fix to update the spi controllers to use EOPNOTSUPP?


Hi Zailiang Zhang, 

Can you forward this to your colleagues and check if the SPI master driver can
be fixed to return -EOPNOTSUPP instead of -ENOTSUPP?


Hi Tudor,
                                                                                                                      
Thank you for the review.
                                                                                                                      
You are right that fixing the spi controller to return -EOPNOTSUPP is the ideal
solution, and I have reached out to the reporter to investigate on their end.  
                                                                                                                      
However, I would suggest keeping this fix in micron-st.c for the following
reasons:                           
   
1, The offending SPI master driver appears to be out-of-tree/downstream, so we
cannot guarantee an upstream fix will reach all affected platforms.
2, spi-mem.c already treats both -ENOTSUPP and -EOPNOTSUPP as equivalent in
spi_mem_exec_op() so this one-liner aligns micron_st_nor_ready() with the
convention already established in the SPI mem framework.
3, there may be other SPI controllers in the field with the same behavior that
we are not aware of. A defensive fix here costs nothing and prevents future
reports. 

I am happy to drop this patch if you feel strongly that the fix belongs only in
the controller driver and the reporter confirms they can fix it on their spi nor
master driver.

Kind regards,
Bean

Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP

[Bean Huo]

On Wed, 2026-03-18 at 17:04 +0000, Zailiang Zhang (zaizhang) wrote:
> Hi,
> 
> Our platform is using Intel Raptorlake CPU, so it’s not our own spi master
> driver.
> The kernel version we are using is 6.6.21.
> I think when micron read fsr function calls spi_mem_exec_op(), it has
> following return:
> > if (!spi_mem_internal_supports_op(mem, op))
> >     return -ENOTSUPP;
> Please correct me if I am wrong here. Also the latest upstream kernel may not
> use the same handling code.


Hi Zailiang,                                                                   
                                                                                                                      
You are correct. the commit cff49d58f57e ("spi: Unify error codes by replacing -
ENOTSUPP with -EOPNOTSUPP"), merged upstream on November 29, 2023, which changed
spi_mem_exec_op() to return -EOPNOTSUPP instead of -ENOTSUPP when an operation
is not supported. Kernel 6.6.21 predates this fix, which is why you see -NOTSUPP
on your platform with Intel Raptor Lake.                                       
                                                                  
                  
Hi Tudor,                                                                      
 
This changes the picture. The -ENOTSUPP Zailiang observed is coming directly
from spi_mem_exec_op() in kernel 6.6.21, before commit cff49d58f57e was in
place. That commit fixed the SPI mem framework itself, but it may not have been
backported to all stable trees.                                                
                  
I would therefore argue that our micron-st.c fix is still worth keeping for the
the reason that it provides a safety net for stable kernels that did not receive
cff49d58f57e as a backport.                     

That said, I am happy to follow your guidance on how to proceed. 
             
Kind regards,                                                                  
Bean

> 
> Please decide the fixup accordingly.
> 
> Thanks,
> Zailiang
> 
> From: Bean Huo <beanhuo@iokpp.de>
> Date: Wednesday, March 18, 2026 at 6:45 AM
> To: Tudor Ambarus <tudor.ambarus@linaro.org>, pratyush@kernel.org
> <pratyush@kernel.org>, mwalle@kernel.org <mwalle@kernel.org>
> Cc: linux-mtd@lists.infradead.org <linux-mtd@lists.infradead.org>,
> linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>, Zailiang Zhang
> (zaizhang) <zaizhang@cisco.com>, Bean Huo <beanhuo@micron.com>
> Subject: Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for
> controllers returning -ENOTSUPP
> 
> On Wed, 2026-03-18 at 15:26 +0200, Tudor Ambarus wrote:
> > Hi, Bean!
> > 
> > On 3/18/26 3:18 PM, Bean Huo wrote:
> > > From: Bean Huo <beanhuo@micron.com>
> > > 
> > > micron_st_nor_ready() falls back to SR-only polling when the SPI
> > > controller does not support low-level FSR reads, but only checks for
> > > -EOPNOTSUPP (95).  Some SPI master drivers return the kernel-internal
> > > -ENOTSUPP (524) for the same condition.  The two codes carry identical
> > 
> > Isn't it a better fix to update the spi controllers to use EOPNOTSUPP?
> 
> 
> Hi Zailiang Zhang,
> 
> Can you forward this to your colleagues and check if the SPI master driver can
> be fixed to return -EOPNOTSUPP instead of -ENOTSUPP?
> 
> 
> Hi Tudor,
>                                                                               
>                                        
> Thank you for the review.
>                                                                               
>                                        
> You are right that fixing the spi controller to return -EOPNOTSUPP is the
> ideal
> solution, and I have reached out to the reporter to investigate on their end. 
>                                                                               
>                                        
> However, I would suggest keeping this fix in micron-st.c for the following
> reasons:                          
>   
> 1, The offending SPI master driver appears to be out-of-tree/downstream, so we
> cannot guarantee an upstream fix will reach all affected platforms.
> 2, spi-mem.c already treats both -ENOTSUPP and -EOPNOTSUPP as equivalent in
> spi_mem_exec_op() so this one-liner aligns micron_st_nor_ready() with the
> convention already established in the SPI mem framework.
> 3, there may be other SPI controllers in the field with the same behavior that
> we are not aware of. A defensive fix here costs nothing and prevents future
> reports.
> 
> I am happy to drop this patch if you feel strongly that the fix belongs only
> in
> the controller driver and the reporter confirms they can fix it on their spi
> nor
> master driver.
> 
> Kind regards,
> Bean

Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP

[Tudor Ambarus]

On 3/18/26 7:17 PM, Bean Huo wrote:
> 
> 
> 
> 
> On Wed, 2026-03-18 at 17:04 +0000, Zailiang Zhang (zaizhang) wrote:
>> Hi,
>>
>> Our platform is using Intel Raptorlake CPU, so it’s not our own spi master
>> driver.
>> The kernel version we are using is 6.6.21.
>> I think when micron read fsr function calls spi_mem_exec_op(), it has
>> following return:
>>> if (!spi_mem_internal_supports_op(mem, op))
>>>     return -ENOTSUPP;
>> Please correct me if I am wrong here. Also the latest upstream kernel may not
>> use the same handling code.
> 
> 
> Hi Zailiang,                                                                   
>                                                                                                                       
> You are correct. the commit cff49d58f57e ("spi: Unify error codes by replacing -
> ENOTSUPP with -EOPNOTSUPP"), merged upstream on November 29, 2023, which changed
> spi_mem_exec_op() to return -EOPNOTSUPP instead of -ENOTSUPP when an operation
> is not supported. Kernel 6.6.21 predates this fix, which is why you see -NOTSUPP
> on your platform with Intel Raptor Lake.                                       
>                                                                   
>                   
> Hi Tudor,                                                                      
>  

Hi,

> This changes the picture. The -ENOTSUPP Zailiang observed is coming directly
> from spi_mem_exec_op() in kernel 6.6.21, before commit cff49d58f57e was in
> place. That commit fixed the SPI mem framework itself, but it may not have been
> backported to all stable trees.                                                
>                   
> I would therefore argue that our micron-st.c fix is still worth keeping for the
> the reason that it provides a safety net for stable kernels that did not receive
> cff49d58f57e as a backport.                     
> 

I advise against this, otherwise we'll carry dead weight on our shoulders.

> That said, I am happy to follow your guidance on how to proceed. 

I would backport the patch to the stable kernel if that fixes things for you.
Then I would follow up with a patch and replace -ENOTSUPP/-EOPNOTSUPP in
spi-mem and spi.

Cheers,
ta

Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP

[Pratyush Yadav]

On Thu, Mar 19 2026, Tudor Ambarus wrote:

> On 3/18/26 7:17 PM, Bean Huo wrote:
>> On Wed, 2026-03-18 at 17:04 +0000, Zailiang Zhang (zaizhang) wrote:
>>> Hi,
>>>
>>> Our platform is using Intel Raptorlake CPU, so it’s not our own spi master
>>> driver.
>>> The kernel version we are using is 6.6.21.
>>> I think when micron read fsr function calls spi_mem_exec_op(), it has
>>> following return:
>>>> if (!spi_mem_internal_supports_op(mem, op))
>>>>     return -ENOTSUPP;
>>> Please correct me if I am wrong here. Also the latest upstream kernel may not
>>> use the same handling code.
>> 
>> 
>> Hi Zailiang,                                                                   
>>                                                                                                                       
>> You are correct. the commit cff49d58f57e ("spi: Unify error codes by replacing -
>> ENOTSUPP with -EOPNOTSUPP"), merged upstream on November 29, 2023, which changed
>> spi_mem_exec_op() to return -EOPNOTSUPP instead of -ENOTSUPP when an operation
>> is not supported. Kernel 6.6.21 predates this fix, which is why you see -NOTSUPP
>> on your platform with Intel Raptor Lake.                                       
>>                                                                   
>> This changes the picture. The -ENOTSUPP Zailiang observed is coming directly
>> from spi_mem_exec_op() in kernel 6.6.21, before commit cff49d58f57e was in
>> place. That commit fixed the SPI mem framework itself, but it may not have been
>> backported to all stable trees.                                                
>>                   
>> I would therefore argue that our micron-st.c fix is still worth keeping for the
>> the reason that it provides a safety net for stable kernels that did not receive
>> cff49d58f57e as a backport.                     
>> 
>
> I advise against this, otherwise we'll carry dead weight on our shoulders.

+1

There is little sense in carrying a fix for a bug we don't have.

>
>> That said, I am happy to follow your guidance on how to proceed. 
>
> I would backport the patch to the stable kernel if that fixes things for you.
> Then I would follow up with a patch and replace -ENOTSUPP/-EOPNOTSUPP in
> spi-mem and spi.

+1 here too.

You would need to backport a patch to your kernel anyway. Better to
backport one that is already upstream and is a more general fix.

-- 
Regards,
Pratyush Yadav