[PATCH 1/5] mtd: spi-nor: Refactor Read Status/Write Status support

[Miquel Raynal]

On 10/08/2026 at 09:18:07 +02, "Michael Walle" <mwalle at kernel.org> wrote:

> On Thu Aug 6, 2026 at 9:38 AM CEST, Miquel Raynal wrote:
>> Hello Michael,
>>
>>>> One thing that comes to mind is hardware write protection. If
>>>> there's nothing before that code which checks it, the verify might
>>>> fail if the hardware write protection is enabled. So we should
>>>> somehow check for that and drop the verify here.
>>>
>>> But how do you think we should handle it? Will the QE bit writing
>>> verification fail if HW WP is enabled?
>
> It should, because you cannot alter the SR.
>
>> Looking into this further: we shall return an error if the QE bit is not
>> set. It just tells the caller that quad mode cannot be used. Then up to
>> the caller to either hard fail or just degrade into single mode (maybe
>> because of a strapped WP). What we should do is to propose a DT property
>> to flag when WP is strapped in hardware, this would make the content of
>> the status registers immutable and we would just skip the entire write
>> operation in the first place, instead of deliberately trying and get a
>> 100% failure rate. Nevertheless, the changes introduced here are kind of
>> orthogonal and do not alter the current behaviour; we shall however
>> listen if people start complaining about this and perhaps implement the
>> solution proposed above.
>
> There is already a property in the DT, where you almost certainly
> know that quad mode is impossible. Iff there are four rx/tx lines
> (spi-{rx,tx}-bus-width). I haven't seen a flash (even in larger
> packages) where there is a dedicated WP# pin.
>
> What do you mean by a dt property? If (1) the flash is using the WP#
> pin? Or (2) if it is using the WP# pin and it's tied to low?
>
> For (1) you have the QE bit, if it's set, WP is turned off and vice
> versa.
>
> For (2), that doesn't make sense, because that pin could be tied
> to some kind of logic which can change during runtime.
>
> FWIW, I don't care too much, you've asked why there is a
> verification step, I've just answered :)

Thank you :) Anyway, I've reinstated these checks in my last version.

If you look at it, don't focus on the commit about the names, I need to
fix that up again by adding some kind of "hide" flag for the RV chips,
instead of dropping the names (the rest won't change much).

Thanks,
Miquèl