u-boot.git/drivers/spi, branch v2025.01

spi: renesas: Fix R-Car spelling

2024-12-11T07:36:24Z

The correct spelling is R-Car, including the dash, update the usage. Kconfig strings and comment changes only, no functional change. Signed-off-by: Marek Vasut

spi: Fix missed rename from SPI_ADVANCE to SPI_STACKED_PARALLEL

2024-11-25T21:29:45Z

Fix missed rename from SPI_ADVANCE to SPI_STACKED_PARALLEL. This fixes an issue encountered while testing the Zynq-7000 QSPI parallel Flash implementation. Fixes: f896aa656774 ("mtd: spi-nor: Rename SPI_ADVANCE to SPI_STACKED_PARALLEL") Reviewed-by: Venkatesh Yadav Abbarapu Reviewed-by: Marek Vasut Signed-off-by: Dominik Wernberger

spi: cadence_qspi: Fix OSPI boot issue

2024-11-19T14:56:44Z

Moving the hw_reset function from the controller driver to the NOR framework has caused the OSPI reset not to be triggered in the Cadence driver's probe function. As a result, reading the flash ID during SPI calibration is incorrect, and the CQSPI_REG_RD_DATA_CAPTURE is set with an invalid value.This makes it unable to read the flash ID properly. To solve this problem, it's suggested to skip SPI calibration and instead retrieve the read_delay directly from the device tree. Skipping SPI calibration doesn't bring harm since there's no need for the flash golden values stored during SPI calibration. Instead, they are now read during the spi_nor_read_id call in the NOR framework. Signed-off-by: Tejas Bhumkar Signed-off-by: Venkatesh Yadav Abbarapu Link: https://lore.kernel.org/r/20241114062045.17581-1-venkatesh.abbarapu@amd.com Signed-off-by: Michal Simek

mtd: spi-nor: Fix integer overflow in stacked memories support

2024-11-11T02:21:07Z

The 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support") adds new SPI bus flags, but also introduces a completely new set of SPI bus flags in another location. The existing flags field is type u8, while the new separate flags are BIT(8) and higher. Use of those new flags triggers integer overflow. Drop the newly introduced flags which were never used anywhere in the code. Move the one remaining flag which was used in the correct place and change it from BIT(8) to BIT(6) so it fits the u8 flags. Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support") Addresses-Coverity-ID: 510804 Extra high-order bits Reported-by: Heinrich Schuchardt Signed-off-by: Marek Vasut Reviewed-by: Venkatesh Yadav Abbarapu

mtd: spi-nor: Rename SPI_ADVANCE to SPI_STACKED_PARALLEL

2024-10-31T16:49:47Z

The SPI_ADVANCE description does not explain what the switch does. It does not have anything to do with any advanced functionality, it only gates off support for stacked and parallel SPI NORs. Rename the Kconfig symbol, update description, and move it right next to Xilinx hardware as it seems to be specific to this hardware. Make sure the symbol is also protected by if DM_SPI in Kconfig. Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support") Signed-off-by: Marek Vasut

spi: zynq_qspi: Add missing prototype for update_stripe

2024-10-25T14:19:55Z

Add missing prototype to fix the sparse warning, warning: no previous prototype for 'update_stripe' [-Wmissing-prototypes]. Signed-off-by: Venkatesh Yadav Abbarapu Link: https://lore.kernel.org/r/20241016044402.18052-1-venkatesh.abbarapu@amd.com Signed-off-by: Michal Simek

Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"

2024-10-11T18:23:25Z

Simon Glass says: When the SPL build-phase was first created it was designed to solve a particular problem (the need to init SDRAM so that U-Boot proper could be loaded). It has since expanded to become an important part of U-Boot, with three phases now present: TPL, VPL and SPL Due to this history, the term 'SPL' is used to mean both a particular phase (the one before U-Boot proper) and all the non-proper phases. This has become confusing. For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL' phases, not just SPL. So code which can only be compiled for actual SPL, for example, must use something like this: #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) In Makefiles we have similar issues. SPL_ has been used as a variable which expands to either SPL_ or nothing, to chose between options like CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was updated to support 'VPL_' as well. This series starts a change in terminology and usage to resolve the above issues: - The word 'xPL' is used instead of 'SPL' to mean a non-proper build - A new CONFIG_XPL_BUILD define indicates that the current build is an 'xPL' build - The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now defined for TPL and VPL phases - The existing SPL_ Makefile variable is renamed to SPL_ - The existing SPL_TPL Makefile variable is renamed to PHASE_ It should be noted that xpl_phase() can generally be used instead of the above CONFIGs without a code-space or run-time penalty. This series does not attempt to convert all of U-Boot to use this new terminology but it makes a start. In particular, renaming spl.h and common/spl seems like a bridge too far at this point. The series is fully bisectable. It has also been checked to ensure there are no code-size changes on any commit.

global: Rename SPL_TPL_ to PHASE_

2024-10-11T17:44:48Z

Use PHASE_ as the symbol to select a particular XPL build. This means that SPL_TPL_ is no-longer set. Update the comment in bootstage to refer to this symbol, instead of SPL_ Signed-off-by: Simon Glass

drivers: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILD

2024-10-11T17:44:48Z

Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass

log: global: Rename warn_non_spl()

2024-10-11T17:44:47Z

This should now refer to xPL rather than SPL, so update it throughout the tree. Signed-off-by: Simon Glass