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 :)

-michael