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@xxxxxxxx>
> Date: Wednesday, March 18, 2026 at 6:45 AM
> To: Tudor Ambarus <tudor.ambarus@xxxxxxxxxx>, pratyush@xxxxxxxxxx
> <pratyush@xxxxxxxxxx>, mwalle@xxxxxxxxxx <mwalle@xxxxxxxxxx>
> Cc: linux-mtd@xxxxxxxxxxxxxxxxxxx <linux-mtd@xxxxxxxxxxxxxxxxxxx>,
> linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx>, Zailiang Zhang
> (zaizhang) <zaizhang@xxxxxxxxx>, Bean Huo <beanhuo@xxxxxxxxxx>
> 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@xxxxxxxxxx>
> > > 
> > > 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