u-boot.git/drivers/misc/Makefile, branch v2025.01 Unnamed repository; edit this file 'description' to name the repository. Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD" 2024-10-11T18:23:25+00:00 Tom Rini trini@konsulko.com 2024-10-11T18:23:25+00:00 47e544f576699ca4630e20448db6a05178960697 Simon Glass <sjg@chromium.org> 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. 
Simon Glass <sjg@chromium.org> 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:48+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:54+00:00 5c10c8badf8233cac1593cd2bef4d0379ac9e5bd 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 <sjg@chromium.org> 
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 <sjg@chromium.org>
global: Rename SPL_ to XPL_ 2024-10-11T17:44:48+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:53+00:00 c46760d5967d12b6f7d37402878d1607a98b2b84 Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is no-longer set. Signed-off-by: Simon Glass <sjg@chromium.org> 
Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.

Signed-off-by: Simon Glass <sjg@chromium.org>
drivers: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILD 2024-10-11T17:44:48+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:48+00:00 371dc068bbf50c6ed6146c04ec83b644bcc79249 Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass <sjg@chromium.org> 
Use the new symbol to refer to any 'SPL' build, including TPL and VPL

Signed-off-by: Simon Glass <sjg@chromium.org>
rockchip: Provid SPL control over otp presence 2024-10-04T14:59:30+00:00 Jonas Karlman jonas@kwiboo.se 2024-10-04T06:21:34+00:00 7fea4f21142da0b35b95f064bbccb9d9b80bb1bd The series "rockchip: Add efuse and otp support to more SoCs" [1], merged in v2023.04, refactored and extended the Rockchip efuse and otp driver to support reading eFUSE/OTP for all supported Rockchip SoCs. Due to use of different licenses the drivers were never combined into a single driver, however anything non SoC specific should be applied to both drivers. The commit fe38b88453d2 ("rockchip: Provided SPL control over efuse presence") changed Makefile options for only one of the two drivers, apply same change to keep these two drivers in sync. [1] https://lore.kernel.org/r/20230222224436.1570224-1-jonas@kwiboo.se/ Fixes: fe38b88453d2 ("rockchip: Provided SPL control over efuse presence") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> 
The series "rockchip: Add efuse and otp support to more SoCs" [1],
merged in v2023.04, refactored and extended the Rockchip efuse and otp
driver to support reading eFUSE/OTP for all supported Rockchip SoCs.

Due to use of different licenses the drivers were never combined into a
single driver, however anything non SoC specific should be applied to
both drivers.

The commit fe38b88453d2 ("rockchip: Provided SPL control over efuse
presence") changed Makefile options for only one of the two drivers,
apply same change to keep these two drivers in sync.

[1] https://lore.kernel.org/r/20230222224436.1570224-1-jonas@kwiboo.se/

Fixes: fe38b88453d2 ("rockchip: Provided SPL control over efuse presence")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
rockchip: Provided SPL control over efuse presence 2024-10-03T17:52:17+00:00 Simon Glass sjg@chromium.org 2024-09-20T07:24:42+00:00 fe38b88453d2ed40e1009d22f3f4d4213d2016b7 This driver should not generally be present in SPL, even if misc devices are enabled. Update the Makefile rule accordingly. Signed-off-by: Simon Glass <sjg@chromium.org> 
This driver should not generally be present in SPL, even if misc devices
are enabled. Update the Makefile rule accordingly.

Signed-off-by: Simon Glass <sjg@chromium.org>
drivers: misc: Fixes: Rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG 2024-04-15T03:16:06+00:00 Wan Yee Lau wan.yee.lau@intel.com 2024-03-28T06:24:00+00:00 27ed98d491521a637f2b4468ac021511294f897f Commit 3f190c55a4211215914126b74357344342329943 ("drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGA") This commit rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG in Makefile. Signed-off-by: Wan Yee Lau <wan.yee.lau@intel.com> 
Commit 3f190c55a4211215914126b74357344342329943
("drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGA")

This commit rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG
in Makefile.

Signed-off-by: Wan Yee Lau <wan.yee.lau@intel.com>
gpio: turris_omnia_mcu: Add support for system power off via sysreset 2024-04-04T08:45:27+00:00 Marek Behún kabel@kernel.org 2024-04-04T07:51:03+00:00 a5505de01d384cc9e283705092830683494a8505 Add support for system power off via UCLASS_SYSRESET. Newer versions of Turris Omnia MCU firmware can power off the board (MCU will disable almost all voltage regulators and go into low power mode). Move the MCU driver into drivers/misc and register it under UCLASS_MISC. The sysreset and gpio device are bound as child devices of the MCU device. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> 
Add support for system power off via UCLASS_SYSRESET. Newer versions of
Turris Omnia MCU firmware can power off the board (MCU will disable
almost all voltage regulators and go into low power mode).

Move the MCU driver into drivers/misc and register it under UCLASS_MISC.
The sysreset and gpio device are bound as child devices of the MCU device.

Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGA 2024-03-18T03:05:09+00:00 Wan Yee Lau wan.yee.lau@intel.com 2024-02-05T03:47:16+00:00 3f190c55a4211215914126b74357344342329943 Add socfpga_dtreg driver enablement for Intel SoCFPGA. Signed-off-by: Wan Yee Lau <wan.yee.lau@intel.com> Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com> 
Add socfpga_dtreg driver enablement for Intel SoCFPGA.

Signed-off-by: Wan Yee Lau <wan.yee.lau@intel.com>
Reviewed-by: Tien Fong Chee <tien.fong.chee@intel.com>
smbios: copy QEMU tables 2024-01-16T22:05:29+00:00 Heinrich Schuchardt heinrich.schuchardt@canonical.com 2023-12-23T01:03:34+00:00 1c5aab803c0b0f07be1d3b0029f4031463497acf QEMU provides SMBIOS tables with detailed information. We should not try to replicate them in U-Boot. If we want to inform about U-Boot, we can add a Firmware Inventory Information (type 45) table in future. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
QEMU provides SMBIOS tables with detailed information. We should not try to
replicate them in U-Boot.

If we want to inform about U-Boot, we can add a Firmware Inventory
Information (type 45) table in future.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>