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>

dfu_free_entities() invoking dfu_free_entity_sf() has let to segementation
faults due to double freeing the same device.

spi_flash_free() is not relevant for the driver model but exists only for
compatibility with old drivers.

We must not remove any device here:

* The device may still be referenced.
* We don't want to have to probe again.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

In case of big area write/erase on spi nor, watchdog timeout may occurs.
Issue reproduced on stm32mp157c-ev1 with following commands:

sf write 0xC0000000 0 0x3000000
or
sf erase 0 0x1000000

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

The NOR flash w25q128 denoted by JEDEC ID 0xef4018 actually represents
various models. From Winbond's website, I could only find 3 types of
them:

    W25Q128JV-IQ/JQ
    datasheet:https://www.winbond.com/resource-files/
w25q128jv%20revg%2004082019%20plus.pdf

    W25Q128FV (SPI Mode)
    datasheet: https://www.winbond.com/resource-files/
w25q128fv%20rev.m%2005132016%20kms.pdf

    W25Q128BV
    datesheet: https://www.winbond.com/resource-files/
w25q128bv_revh_100313_wo_automotive.pdf

According to the datasheets, all of these 3 types support BP(0,1,2) and
TB bits in the status register (SR), so it could reuse the flash
protection logic for ST Micro.

So it should be safe to add the SPI_NOR_HAS_LOCK and SPI_NOR_HAS_TB
flags to the w25q128 entry of spi_nor_ids table.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[jagan: remove comments in spi-nor-ids.c]
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>

Add GD25LQ24C 64Mbit chip to spi-nor id table. This chip is used on
rk3399-gru-kevin:

    => sf probe
    SF: Detected gd25lq64c with page size 256 Bytes, erase size 4 KiB, total 8 MiB
    => sf erase 0x600000 0x200000
    SF: 2097152 bytes @ 0x600000 Erased: OK
    => sf test 0x700000 0x1000
    SPI flash test:
    0 erase: 52 ticks, 76 KiB/s 0.608 Mbps
    1 check: 5 ticks, 800 KiB/s 6.400 Mbps
    2 write: 14 ticks, 285 KiB/s 2.280 Mbps
    3 read: 3 ticks, 1333 KiB/s 10.664 Mbps
    Test passed
    0 erase: 52 ticks, 76 KiB/s 0.608 Mbps
    1 check: 5 ticks, 800 KiB/s 6.400 Mbps
    2 write: 14 ticks, 285 KiB/s 2.280 Mbps
    3 read: 3 ticks, 1333 KiB/s 10.664 Mbps

The values are the same as in Linux, except adjusted for the U-Boot
definition of INFO().

Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>

- Merge the patch to take <asm/global_data.h> out of <common.h>

Provide an explicit configuration option to disable default "unlock all"
of any flash chip which supports locking. It doesn't make sense to
automatically unprotect the entire flash on each u-boot startup if the
block protection bits are actually used.

Traditionally, the unlock was there to be able to write to flash devices
which powered-up with the block protection bits set. Over time this
feature creeped into all flash devices which support locking.

For a more detailed description and discussion see:
https://lore.kernel.org/linux-mtd/20201203162959.29589-8-michael@walle.cc/

Keep things simple in u-boot and just provide a configration option to
disable this behavior which can be set per board.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

Move this out of the common header and include it only where needed.  In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly.   Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

Driver model: make some udevice fields private
Driver model: Rename U_BOOT_DEVICE et al.
dtoc: Tidy up and add more tests
ns16550 code clean-up
x86 and sandbox minor fixes for of-platdata
dtoc prepration for adding build-time instantiation

Prepare v2021.01-rc5

Signed-off-by: Tom Rini <trini@konsulko.com>