[PATCH] mtd: spi-nor: micron-st: Add n25q064a WP support

[Brian Norris]

Hi Tudor,

On Wed, Jul 31, 2024 at 1:51 AM Tudor Ambarus <tudor.ambarus at linaro.org> wrote:
> A shasum on the SFDP dump would be good to have some sort of integrity
> assurance, e.g.:
> sha256sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp

# sha256sum /sys/bus/spi/devices/spi0.0/spi-nor/sfdp
2030d04758164491e414e1d55e16b04803f5653fb591fda50991c728c49c1c37
/sys/bus/spi/devices/spi0.0/spi-nor/sfdp

> Some test in mtd-utils would be good indeed, but narrative shall be also
> ok for now. What I fear is that people just use just a flash lock/unlock
> all sectors test, which is not ideal. We shall also test locking on some
> sectors from the top and bottom, to verify the correctness of the TB
> bit, check if BP3 is working by locking some sectors in that area.
> Haven't looked at the BP area in a while, but you get my point, I feel
> testing is not ideal and a guideline would help.
>
> If you ever feel that you can spend some time on this, help is appreciated.

OK. It's possible, but no guarantees. I think in the distant past
(when I was still maintaining some of this area), I actually started
to write such a mtd-utils test, but I never cleaned it up and
submitted it. For one, a proper exhaustive test would be rather slow,
as we'd want to test all the possible protection ranges, and then
erase/write/read the whole thing. Some rough measurement on my system
shows about a minute for erasing the whole chip, 25 seconds for
writing, and 7 seconds for reading -- which means with 5 bits of
protection range (4 bits, plus top/bottom bit) we have 32 combinations
* ~1.5 minutes test = 48 minutes. That's ... doable I guess, and it
could probably be optimized a bit to reduce the number of erase
cycles. But it's not great.

Anyway, maybe I'll play with it.

Brian