Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP
From: Bean Huo
Date: Wed Mar 18 2026 - 09:45:24 EST
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