u-boot.git/include/spi_flash.h, branch v2022.01 Unnamed repository; edit this file 'description' to name the repository. mtd: spi-flash: Check for zero length in legacy spi_flash_*() 2021-10-23T10:17:33+00:00 Marek Behún marek.behun@nic.cz 2021-10-05T13:56:01+00:00 a67b3719f32673a9890700c72b980acbd2749e49 Check for zero length in the legacy spi_flash_read() / spi_flash_write() / spi_flash_erase() functions. On zero length, return 0 immediately, don't call the underlying method. Rationale: - these legacy functions call the _read(), _write() and _erase() methods of struct mtd - the DM callers of these methods already check for zero length - making all callers of these methods check for zero length makes it possible to remove the check from implementations of these _read(), _write() and _erase() methods Signed-off-by: Marek Behún <marek.behun@nic.cz> 
Check for zero length in the legacy spi_flash_read() /
spi_flash_write() / spi_flash_erase() functions.
On zero length, return 0 immediately, don't call the underlying method.

Rationale:
- these legacy functions call the _read(), _write() and _erase() methods
  of struct mtd
- the DM callers of these methods already check for zero length
- making all callers of these methods check for zero length makes it
  possible to remove the check from implementations of these _read(),
  _write() and _erase() methods

Signed-off-by: Marek Behún <marek.behun@nic.cz>
sf: Support querying write-protect 2021-03-27T02:04:31+00:00 Simon Glass sjg@chromium.org 2021-03-15T05:11:17+00:00 b3b60f59124a1f4fdcee5b7eff3f057e33cfa4c7 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> 
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>
mtd: spi_flash_free() 2021-03-27T00:59:36+00:00 Heinrich Schuchardt xypron.glpk@gmx.de 2021-03-10T17:23:57+00:00 b09c74f66d46fac7f25e53a0c06f832cf0638a5c 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> 
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>
sf: Drop dm.h header file from spi_flash.h 2020-08-04T02:19:54+00:00 Simon Glass sjg@chromium.org 2020-07-19T16:15:40+00:00 a00867b47a4be848c400f74b97479193a41d327c This header file should not be included in other header files. Remove it and use a forward declaration instead. Signed-off-by: Simon Glass <sjg@chromium.org> 
This header file should not be included in other header files. Remove it
and use a forward declaration instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
spi: Convert CONFIG_DM_SPI* to CONFIG_$(SPL_TPL_)DM_SPI* 2020-06-29T17:34:43+00:00 Lukasz Majewski lukma@denx.de 2020-06-04T15:11:53+00:00 56c404603825a4e3229dcf0d3d88318b20493fa6 This change allows more fine tuning of driver model based SPI support in SPL and TPL. It is now possible to explicitly enable/disable the DM_SPI support in SPL and TPL via Kconfig option. Before this change it was necessary to use: /* SPI Flash Configs */ #if defined(CONFIG_SPL_BUILD) #undef CONFIG_DM_SPI #undef CONFIG_DM_SPI_FLASH #undef CONFIG_SPI_FLASH_MTD #endif in the ./include/configs/<board>.h, which is error prone and shall be avoided when we strive to switch to Kconfig. The goal of this patch: Provide distinction for DM_SPI support in both U-Boot proper and SPL (TPL). Valid use case is when U-Boot proper wants to use DM_SPI, but SPL must still support non DM driver. Another use case is the conversion of non DM/DTS SPI driver to support DM/DTS. When such driver needs to work in both SPL and U-Boot proper, the distinction is needed in Kconfig (also if SPL version of the driver supports OF_PLATDATA). In the end of the day one would have to support following use cases (in single driver file - e.g. mxs_spi.c): - U-Boot proper driver supporting DT/DTS - U-Boot proper driver without DT/DTS support (deprecated) - SPL driver without DT/DTS support - SPL (and TPL) driver with DT/DTS (when the SoC has enough resources to run full blown DT/DTS) - SPL driver with DT/DTS and SPL_OF_PLATDATA (when one have constrained environment with no fitImage and OF_LIBFDT support). Some boards do require SPI support (with DM) in SPL (TPL) and some only have DM_SPI{_FLASH} defined to allow compiling SPL. This patch converts #ifdef CONFIG_DM_SPI* to #if CONFIG_IS_ENABLED(DM_SPI) and provides corresponding defines in Kconfig. Signed-off-by: Lukasz Majewski <lukma@denx.de> Tested-by: Adam Ford <aford173@gmail.com> #da850-evm Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com> [trini: Fixup a few platforms] Signed-off-by: Tom Rini <trini@konsulko.com> 
This change allows more fine tuning of driver model based SPI support in
SPL and TPL. It is now possible to explicitly enable/disable the DM_SPI
support in SPL and TPL via Kconfig option.

Before this change it was necessary to use:
    /* SPI Flash Configs */
    #if defined(CONFIG_SPL_BUILD)
    #undef CONFIG_DM_SPI
    #undef CONFIG_DM_SPI_FLASH
    #undef CONFIG_SPI_FLASH_MTD
    #endif

in the ./include/configs/<board>.h, which is error prone and shall be
avoided when we strive to switch to Kconfig.

The goal of this patch:

Provide distinction for DM_SPI support in both U-Boot proper and SPL (TPL).
Valid use case is when U-Boot proper wants to use DM_SPI, but SPL must
still support non DM driver.

Another use case is the conversion of non DM/DTS SPI driver to support
DM/DTS. When such driver needs to work in both SPL and U-Boot proper, the
distinction is needed in Kconfig (also if SPL version of the driver
supports OF_PLATDATA).

In the end of the day one would have to support following use cases (in
single driver file - e.g. mxs_spi.c):

- U-Boot proper driver supporting DT/DTS
- U-Boot proper driver without DT/DTS support (deprecated)
- SPL driver without DT/DTS support
- SPL (and TPL) driver with DT/DTS (when the SoC has enough resources to
  run full blown DT/DTS)
- SPL driver with DT/DTS and SPL_OF_PLATDATA (when one have constrained
  environment with no fitImage and OF_LIBFDT support).

Some boards do require SPI support (with DM) in SPL (TPL) and some only
have DM_SPI{_FLASH} defined to allow compiling SPL.

This patch converts #ifdef CONFIG_DM_SPI* to #if CONFIG_IS_ENABLED(DM_SPI)
and provides corresponding defines in Kconfig.

Signed-off-by: Lukasz Majewski <lukma@denx.de>
Tested-by: Adam Ford <aford173@gmail.com> #da850-evm
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
[trini: Fixup a few platforms]
Signed-off-by: Tom Rini <trini@konsulko.com>
sf: Drop spl_flash_get_sw_write_prot 2020-06-01T12:25:24+00:00 Jagan Teki jagan@amarulasolutions.com 2020-05-13T12:46:39+00:00 f12f96cfaf53d47aa58eb640744542446aac44dd The get_sw_write_prot API is used to get the write-protected bits of flash by reading the status register and other wards it's API for reading register bits. 1) This kind of requirement can be achieved using existing flash operations and flash locking API calls instead of making a separate flash API. 2) Technically there is no real hardware user for this API to use in the source tree. 3) Having a flash operations API for simple register read bits also make difficult to extend the flash operations. 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. Considering all these points, this patch drops the get_sw_write_prot and associated code bases. Cc: Simon Glass <sjg@chromium.org> Cc: Vignesh R <vigneshr@ti.com> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> 
The get_sw_write_prot API is used to get the write-protected
bits of flash by reading the status register and other wards
it's API for reading register bits.

1) This kind of requirement can be achieved using existing
   flash operations and flash locking API calls instead of
   making a separate flash API.
2) Technically there is no real hardware user for this API to
   use in the source tree.
3) Having a flash operations API for simple register read bits
   also make difficult to extend the flash operations.
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.

Considering all these points, this patch drops the get_sw_write_prot
and associated code bases.

Cc: Simon Glass <sjg@chromium.org>
Cc: Vignesh R <vigneshr@ti.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
mtd: spi: Export spi_flash_std_probe() 2019-12-15T03:44:24+00:00 Simon Glass sjg@chromium.org 2019-12-07T04:42:50+00:00 4806fcea1a4b0143fc57932bc5cbdffdf8afca4e With of-platdata we need to create drivers for particular chips, or at least drivers that are separate from the standard code, since C structures are created by dtoc which are private to that driver. To avoid duplicating the probing code, export this probe function for use by these drivers. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> 
With of-platdata we need to create drivers for particular chips, or at
least drivers that are separate from the standard code, since C structures
are created by dtoc which are private to that driver.

To avoid duplicating the probing code, export this probe function for use
by these drivers.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Convert CONFIG_ENV_SPI_* to Kconfig 2019-03-25T21:36:59+00:00 Patrick Delaunay patrick.delaunay@st.com 2019-02-27T14:20:38+00:00 abe66b1b5decf9cc2fb5daad42c9e870e5b99b67 This converts the following to Kconfig: CONFIG_ENV_SPI_BUS CONFIG_ENV_SPI_CS CONFIG_ENV_SPI_MAX_HZ CONFIG_ENV_SPI_MODE Most of time these value are not needed, CONFIG_SF_DEFAULT with same value is used, so I introduced CONFIG_USE_ENV_SPI_* to force the associated value for the environment. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> 
This converts the following to Kconfig:
  CONFIG_ENV_SPI_BUS
  CONFIG_ENV_SPI_CS
  CONFIG_ENV_SPI_MAX_HZ
  CONFIG_ENV_SPI_MODE

Most of time these value are not needed, CONFIG_SF_DEFAULT
with same value is used, so I introduced CONFIG_USE_ENV_SPI_*
to force the associated value for the environment.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Convert CONFIG_SF_DEFAULT_* to Kconfig 2019-03-25T21:36:53+00:00 Patrick Delaunay patrick.delaunay@st.com 2019-02-27T14:20:36+00:00 14453fbfadc2f98ca35d6033140466c7a4b4947a This converts the following to Kconfig: CONFIG_SF_DEFAULT_BUS CONFIG_SF_DEFAULT_CS CONFIG_SF_DEFAULT_MODE CONFIG_SF_DEFAULT_SPEED I use moveconfig script and then manual check on generated u-boot.cfg to solve the remaining issue. Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> 
This converts the following to Kconfig:
  CONFIG_SF_DEFAULT_BUS
  CONFIG_SF_DEFAULT_CS
  CONFIG_SF_DEFAULT_MODE
  CONFIG_SF_DEFAULT_SPEED

I use moveconfig script and then manual check on generated u-boot.cfg
to solve the remaining issue.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
mtd: spi: Switch to new SPI NOR framework 2019-02-07T10:03:21+00:00 Vignesh R vigneshr@ti.com 2019-02-05T05:59:23+00:00 c4e8862308d420e85c227498797c32410d9e47a8 Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD layer. Fix up sf_dataflash to work in legacy way. And update sandbox to use new interfaces/definitions Signed-off-by: Vignesh R <vigneshr@ti.com> Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Tested-by: Stefan Roese <sr@denx.de> Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Jagan Teki <jagan@openedev.com> Tested-by: Jagan Teki <jagan@amarulasolutions.com> #zynq-microzed 
Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD
layer. Fix up sf_dataflash to work in legacy way. And update sandbox to
use new interfaces/definitions

Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> #zynq-microzed