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

[Pratyush Yadav <pratyush@kernel.org>]

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