sf: Support querying write-protect
authorSimon Glass <sjg@chromium.org>
Mon, 15 Mar 2021 05:11:17 +0000 (18:11 +1300)
committerSimon Glass <sjg@chromium.org>
Sat, 27 Mar 2021 02:04:31 +0000 (15:04 +1300)
commitb3b60f59124a1f4fdcee5b7eff3f057e33cfa4c7
tree8bcfb8bb918a6007988aec60342ce9647f65ec5f
parenteb26d88d55e6ed92214d98b81457ddcc743347a0
sf: Support querying write-protect

This feature was dropped from U-Boot some time ago:

   f12f96cfaf5 (sf: Drop spl_flash_get_sw_write_prot")

However, we do need a way to see if a flash device is write-protected,
since if it is, it may not be possible to write to do (i.e. failing to
write is expected).

I am not sure of the correct layer to implement this, so this patch is a
stab at it. If spi-flash makes sense then I will add to the 'sf' also.

Re the points mentioned in the removal commit:

    1) This kind of requirement can be achieved using existing
       flash operations and flash locking API calls instead of
       making a separate flash API.

Which uclass is this?

    2) Technically there is no real hardware user for this API to
       use in the source tree.

I do want coral (at least) to support this.

    3) Having a flash operations API for simple register read bits
       also make difficult to extend the flash operations.

This new patch only mentions write-protect being on or off, rather than
the actual mechanism.

    4) Instead of touching generic code, it is possible to have
       this functionality inside spinor operations in the form of
       flash hooks or fixups for associated flash chips.

That sounds to me like what drivers are for. But we still need some sort
of API for it to be accessible.

Signed-off-by: Simon Glass <sjg@chromium.org>
drivers/mtd/spi/sf-uclass.c
drivers/mtd/spi/sf_internal.h
drivers/mtd/spi/sf_probe.c
drivers/mtd/spi/spi-nor-core.c
drivers/mtd/spi/spi-nor-tiny.c
include/spi_flash.h
test/dm/sf.c