mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bean Huo <beanhuo@iokpp.de>
To: Tudor Ambarus <tudor.ambarus@linaro.org>,
	pratyush@kernel.org,  mwalle@kernel.org
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	 zaizhang@cisco.com, Bean Huo <beanhuo@micron.com>
Subject: Re: [PATCH] mtd: spi-nor: micron-st: fix FSR read fallback for controllers returning -ENOTSUPP
Date: Wed, 18 Mar 2026 14:44:56 +0100	[thread overview]
Message-ID: <3c94f0e1c5a8bf184d7a81f49b7beb999355dcd3.camel@iokpp.de> (raw)
In-Reply-To: <639bd964-b499-4e9f-9035-0010fecfb17c@linaro.org>

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

  reply	other threads:[~2026-03-18 13:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18 13:18 Bean Huo
2026-03-18 13:26 ` Tudor Ambarus
2026-03-18 13:44   ` Bean Huo [this message]
     [not found]     ` <DS0PR11MB8668FC8E62236D0893A8CEFFC84EA@DS0PR11MB8668.namprd11.prod.outlook.com>
2026-03-18 17:17       ` Bean Huo
2026-03-19  9:10         ` Tudor Ambarus
2026-03-19 11:19           ` Pratyush Yadav

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3c94f0e1c5a8bf184d7a81f49b7beb999355dcd3.camel@iokpp.de \
    --to=beanhuo@iokpp.de \
    --cc=beanhuo@micron.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mwalle@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=tudor.ambarus@linaro.org \
    --cc=zaizhang@cisco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®