Some SPI controllers like Intel's one on the PCI bus do not support
opcode 35h. This opcode is used to read the Configuration Register on
SPI-NOR chips that have 16-bit Status Register configured regardless
of the controller support for it. Adding a check call in the setup step
allows disabling use of the 35h opcode and falling back to the manual
Status Registers management.

Before:
openat(AT_FDCWD, "/dev/mtd0", O_RDWR)   = 4
ioctl(4, MIXER_WRITE(6) or MEMUNLOCK, {start=0, length=0x2000000}) = -1
EOPNOTSUPP

After:
openat(AT_FDCWD, "/dev/mtd0", O_RDWR)   = 4
ioctl(4, MIXER_WRITE(6) or MEMUNLOCK, {start=0, length=0x2000000}) = 0
ioctl(4, MIXER_WRITE(5) or MEMLOCK, {start=0x1800000, length=0x800000}) = 0

Suggested-by: Adeel Arshad <adeel.arshad@intel.com>
Signed-off-by: Jakub Czapiga <czapiga@google.com>
---
 drivers/mtd/spi-nor/core.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ac4b960101cc..79deee3a50d3 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2608,6 +2608,10 @@ static int spi_nor_setup(struct spi_nor *nor,
 		}
 	}
 
+	/* Some SPI controllers might not support CR read opcode. */
+	if (spi_nor_read_cr(nor, nor->bouncebuf) == -EOPNOTSUPP)
+		nor->flags |= SNOR_F_NO_READ_CR;
+
 	/* Select the (Fast) Read command. */
 	err = spi_nor_select_read(nor, shared_mask);
 	if (err) {
-- 
2.51.0.384.g4c02a37b29-goog

Hi Jakub,

> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index ac4b960101cc..79deee3a50d3 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2608,6 +2608,10 @@ static int spi_nor_setup(struct spi_nor *nor,
>  		}
>  	}
>  
> +	/* Some SPI controllers might not support CR read opcode. */
> +	if (spi_nor_read_cr(nor, nor->bouncebuf) == -EOPNOTSUPP)

There is a spi_nor_spimem_check_op() helper which might be better suited
for this purpose?

Thanks,
Miquèl

Hi Miquèl,

On Wed, Sep 10, 2025 at 2:05 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Jakub,
>
> > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > index ac4b960101cc..79deee3a50d3 100644
> > --- a/drivers/mtd/spi-nor/core.c
> > +++ b/drivers/mtd/spi-nor/core.c
> > @@ -2608,6 +2608,10 @@ static int spi_nor_setup(struct spi_nor *nor,
> >               }
> >       }
> >
> > +     /* Some SPI controllers might not support CR read opcode. */
> > +     if (spi_nor_read_cr(nor, nor->bouncebuf) == -EOPNOTSUPP)
>
> There is a spi_nor_spimem_check_op() helper which might be better suited
> for this purpose?

spi_nor_spimem_check_op() works only for spi-mem devices. spi_nor_read_cr()
handles both spi-mem and spi-nor controller. Using spi_nor_spimem_check_op()
would require adding a variation of spi_nor_read_cr() that would use
spi_nor_spimem_check_op() for spi-mem and spi_nor_controller_ops_read_reg()
for spi-nor controller.
Another way would be to do this check only for the spi-mem as spi-nor
controllers seem to be deprecated in favour of spi-mem.

Thanks,
Jakub

Hello,

On 10/09/2025 at 16:30:43 +02, "Jakub \"Kuba\" Czapiga" <czapiga@google.com> wrote:

> Hi Miquèl,
>
> On Wed, Sep 10, 2025 at 2:05 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>>
>> Hi Jakub,
>>
>> > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> > index ac4b960101cc..79deee3a50d3 100644
>> > --- a/drivers/mtd/spi-nor/core.c
>> > +++ b/drivers/mtd/spi-nor/core.c
>> > @@ -2608,6 +2608,10 @@ static int spi_nor_setup(struct spi_nor *nor,
>> >               }
>> >       }
>> >
>> > +     /* Some SPI controllers might not support CR read opcode. */
>> > +     if (spi_nor_read_cr(nor, nor->bouncebuf) == -EOPNOTSUPP)
>>
>> There is a spi_nor_spimem_check_op() helper which might be better suited
>> for this purpose?
>
> spi_nor_spimem_check_op() works only for spi-mem devices. spi_nor_read_cr()
> handles both spi-mem and spi-nor controller. Using spi_nor_spimem_check_op()
> would require adding a variation of spi_nor_read_cr() that would use
> spi_nor_spimem_check_op() for spi-mem and spi_nor_controller_ops_read_reg()
> for spi-nor controller.
> Another way would be to do this check only for the spi-mem as spi-nor
> controllers seem to be deprecated in favour of spi-mem.

I'll let that choice to SPI NOR maintainers but we've collectively asked
to switch in favor of the spi memory API for quite some time, I would
not care too much about compatibility with the two remaining controllers
that have not yet been converted.

But here is a proper illustration why spi-mem rocks and why SPI NOR
controllers, besides making no sense (because we also have SPI NANDs
now) have a flacky API as of today's standards.

Thanks,
Miquèl

On 9/10/25 3:45 PM, Miquel Raynal wrote:
> Hello,
> 
> On 10/09/2025 at 16:30:43 +02, "Jakub \"Kuba\" Czapiga" <czapiga@google.com> wrote:
> 
>> Hi Miquèl,
>>
>> On Wed, Sep 10, 2025 at 2:05 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>>>
>>> Hi Jakub,
>>>
>>>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>>>> index ac4b960101cc..79deee3a50d3 100644
>>>> --- a/drivers/mtd/spi-nor/core.c
>>>> +++ b/drivers/mtd/spi-nor/core.c
>>>> @@ -2608,6 +2608,10 @@ static int spi_nor_setup(struct spi_nor *nor,
>>>>               }
>>>>       }
>>>>
>>>> +     /* Some SPI controllers might not support CR read opcode. */
>>>> +     if (spi_nor_read_cr(nor, nor->bouncebuf) == -EOPNOTSUPP)
>>>
>>> There is a spi_nor_spimem_check_op() helper which might be better suited
>>> for this purpose?
>>
>> spi_nor_spimem_check_op() works only for spi-mem devices. spi_nor_read_cr()
>> handles both spi-mem and spi-nor controller. Using spi_nor_spimem_check_op()
>> would require adding a variation of spi_nor_read_cr() that would use
>> spi_nor_spimem_check_op() for spi-mem and spi_nor_controller_ops_read_reg()
>> for spi-nor controller.
>> Another way would be to do this check only for the spi-mem as spi-nor
>> controllers seem to be deprecated in favour of spi-mem.
> 
> I'll let that choice to SPI NOR maintainers but we've collectively asked
> to switch in favor of the spi memory API for quite some time, I would
> not care too much about compatibility with the two remaining controllers
> that have not yet been converted.
> 

That's correct. It's been a few years now since we stopped adding new
support for the SPI NOR controllers, so feel free to ignore that part.
All we did on that front was to make sure we don't break anything.

> But here is a proper illustration why spi-mem rocks and why SPI NOR
> controllers, besides making no sense (because we also have SPI NANDs
> now) have a flacky API as of today's standards.

Right. I'd very much like to see the SPI NOR controllers converted to
spimem or removed altogether.

Cheers,
ta