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

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