Re: [PATCH v5 03/25] mtd: spi-nor: Refactor Read Status/Write Status support

[Jon Hunter <jonathanh@nvidia.com>]

Hi Miguel,

On 04/09/2026 19:12, Miquel Raynal wrote:

...

> This is a really hard to review patch, it is big, full of changes
> everywhere, but I cannot really split it further. The commit log is
> really important, it tries to explain the steps I went through when
> trying to refactor the whole QE/SR handling for which I received
> feedback from Michael, Tudor and Sashiko.
> 
> Ideally we could expect test coverage of each case:
> - BFPT_DWORD15_QER_NONE: Probably not needed
> - BFPT_DWORD15_QER_SR2_BIT1_BUGGY: Expected from Hsin-Yi (flag is being
>    renamed _NO_1B_WR)
> - BFPT_DWORD15_QER_SR2_BIT1_NO_RD: Tested with a chip re-enabling RDCR
>    in a fixup
> - BFPT_DWORD15_QER_SR1_BIT6: TBD
> - BFPT_DWORD15_QER_SR2_BIT7: TBD
> - BFPT_DWORD15_QER_SR2_BIT1: TBD
> - BFPT_DWORD15_QER_SR2_BIT1_1B: Done.
> There will probably be breakages on older chips. These cannot be
> guessed because they are not properly listed in manufacturer
> fixups (yet). If we want a cleanup/simplification, we will have to cope
> with this risk.
> 
> I hope the diff stats will motivate people to have a look and report
> their testing.
> 
> I will also eagerly monitor Sashiko's output which will probably be
> very useful to catch niche weird cases where these changes might break.


Since this landed in -next I am seeing a flash/boot issue on one of our
Jetson boards. This board, Tegra234 Jetson Orin Nano
(tegra234-p3768-0000+p3767-0005.dts), uses a QSPI flash device and the
kernel is used to flash this device. Following this commit, on boot I
now see ...

spi-nor spi0.0: probe with driver spi-nor failed with error -22

Some quick AI analysis states ...

"The commit contains a probe-blocking regression in its new generic
  quad-enable path.

   ### Finding: -EINVAL from an unavailable SR2 read

   For BFPT_DWORD15_QER_SR1_BIT6 flashes, commit 63489002d397
   configures:

   params->opcodes.read_sr2 = 0;
   params->opcodes.write_sr1_and_sr2 = 0;
   params->qe_mask[0] = BIT(6);

   That correctly describes Macronix-style parts whose QE bit lives
   in SR1. However, spi_nor_generic_quad_enable() then unconditionally
   calls:

   spi_nor_read_sr1_and_sr2(nor, sr);

   That helper always calls spi_nor_read_sr2(), which does:

   if (!params->opcodes.read_sr2)
           return -EINVAL;

   The resulting probe path is:

   spi_nor_scan()
     → spi_nor_setup() selects quad I/O
     → spi_nor_init()
     → spi_nor_quad_enable()
     → spi_nor_generic_quad_enable()
     → spi_nor_read_sr1_and_sr2()
     → spi_nor_read_sr2()
     → -EINVAL

   This exactly explains:

   spi-nor spi0.0: probe with driver spi-nor failed with error -22"


I added a dump_stack() in spi_nor_read_sr2() and this does appear to
correlate with the above.

Let me know if you any any further inputs.

Thanks
Jon

-- 
nvpublic