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