Unfortunately I don't really have time to review clock patches. When I
initially started maintaining this subsystem I had more free time than I do
now. But I also found it hard to motivate myself to review patches. Many
clock patches add support for new SoCs and they are time consuming to
review properly. You effectively have to spend a few hours reading the
reference manual (if it's public!) and reviewing drivers is no small feat
either. This is made more difficult since clocking is often very different
between SoCs and it can be difficult to determine whether something is a
bug in the driver or a workaround for some hardware behavior. I mostly
don't care about any given SoC unless I'm hacking on it so I ended up with
a ton (more than 7000) of unreviewed patches piling up in my inbox. I'd
love to be more active, but I have a day job and I usually want to work on
something more interesting when I get home. I still think the clock
subsystem is a major mess but I don't care enough to fix it :l
The subsystem itself should probably get orphaned since AFAICT all patches
go through the mach/arch maintainer or to Tom.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
When I modified this code I meant to accept the LGPL offer to convert the
license to GPL. However, while there is an LGPL 2.1, the next version of
the GPL after 2.0 is 3.0. Fix the license version
Fixess: c4ac52f55d ("test: Add test for strlcat")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Python 3.7 and 3.8 lack the files attribute in importlib.resources.
Use importlib_resources to fix build errors with Python 3.8:
binman: module 'importlib.resources' has no attribute 'files'
Fixes: 538719cb6a ("binman: migrate from pkg_resources to importlib")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Acked-by: Quentin Schulz <quentin.schulz@cherry.de>
[trini: Re-add # pragma: no cover line]
Signed-off-by: Tom Rini <trini@konsulko.com>
The MAINTAINERS files for B&R boards are not in sync
with the current file names. Update the files so
that they are correct again.
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
B&R Industrial Automation has been acquired by ABB in 2017, and this
will be reflected in our email addresses beginning from December 2025.
The email addresses change as follows:
@br-automation.com -> @<country-code>.abb.com
The existing email addresses will be valid until December 2026.
Add entries for Bernhard Messerklinger and myself to .mailmap, and
update the MAINTAINERS files.
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@at.abb.com>
The current implementation of clk_set_parent() unconditionally enables
the new parent clock, even if the target clock was not previously enabled.
To avoid this implicit behavior, this patch adds a check for whether
the target clock has been enabled before parent enabling..
Fixes: ac30d90f33 ("clk: Ensure the parent clocks are enabled while reparenting")
Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Heiko Schocher <hs@nabladev.com> says:
Add SM3 secure hash, as specified by OSCCA GM/T 0004-2012 SM3 and described
at https://datatracker.ietf.org/doc/html/draft-sca-cfrg-sm3-02
TPMv2 defines hash algo sm3_256, which is currently
not supported and prevented TPMv2 chip with newer
firmware to work with U-Boot. Seen this on a ST33TPHF2XI2C
u-boot=> tpm2 init
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
u-boot=>
Implement sm3 hash, so we can fix this problem.
Link: https://lore.kernel.org/r/20251118043042.27726-1-hs@nabladev.com
In dm_test_cmd_hash_md5 accidentially sha256 hash
ist used. Use the correct md5 hash instead.
Signed-off-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
add sm3 256 hash support, so TPM2 chips which report
5 pcrs with sm3 hash do not fail with:
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
Signed-off-by: Heiko Schocher <hs@nabladev.com>
Implement SM3_256 Hash algorithm, based on
linux commit f83a4f2a4d8c: ("Merge tag 'erofs-for-6.17-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs")
Therefore add the needed parts from linux.
Signed-off-by: Heiko Schocher <hs@nabladev.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
sm3 crypto algorithm uses rol32 function from linux, so
import it. Linux base was:
commit ca91b9500108:("Merge tag 'v6.15-rc4-ksmbd-server-fixes' of git://git.samba.org/ksmbd")
Signed-off-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Andrew Goodbody <andrew.goodbody@linaro.org> says:
The function clk_get_rate() returns a ulong with 0 meaning an invalid
clock rate and also negative error codes being returned for other
errors. But being an unsigned return value this cannot simply be tested
for with a < 0 test. Instead use the IS_ERR_VALUE() macro to check for
negative errors appearing as very large positive values. Fix those
places that test for <= 0. Also fix some places checking the return of
clk_register() that incorrectly used ERR_PTR().
Link: https://lore.kernel.org/r/20251021-clk_funcs-v1-0-acf51a40eea7@linaro.org
Testing an unisgned ivariable to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Testing an unisgned ivariable to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
clk_register() will return standard error codes so the use of ERR_PTR()
is incorrect. Furthermore the code was ineffective as it lacked a return
statement that would have actually made use of the result. Add the
return statement and remove the use of ERR_PTR to correct this.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
clk_get_rate() returns a ulong and that return value is assigned to a
member of a struct that is an unsigned int. So testing this value to <=
0 will only detect a return of 0. Also the code in the if block assumes
ret holds the return value when it does not. So update the test to one
that will work as intended and update the if block to actually refer to
the return value.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Quentin Schulz <foss+uboot@0leil.net> says:
u-boot,boot-led and u-boot,error-led aren't actually handled by some
generic code but rather by board or architecture specific code. They
also aren't properties that are part of the official dt-binding so they
cannot be upstreamed. For u-boot,boot-led, there's actually a proper
replacement which is /options/u-boot/boot-led[1] (+ CONFIG_LED_BOOT=y).
For Rockchip boards, either nothing (for RK3066, PX30 and RK3399) was
using that property or (for RK3188) the code handling it was guarded by
symbols that were not enabled in the defconfig. For those, the property
and guarded code are removed.
For the Sam9x60 Curiosity, it seems that even though the LED is
controlled whenever CONFIG_LED is enabled, it isn't enabled by default
in the defconfig (but the code was added without modifying the
defconfig, explicitly leaving a choice to the user). I decided to keep
that feature by simply migrating it to the new API, though I cannot test
it as I do not own the device.
The STM32 boards will be migrated in the near future once their upstream
(kernel) Device Trees gain the new way to specify this (via
/options/u-boot/boot-led). I'll let Patrice handle this, see
https://lore.kernel.org/u-boot/94ed1988-13e8-4fe3-bdff-ba2c9973c556@foss.st.com/
and
https://lore.kernel.org/u-boot/2a3aa43a-ce19-41e1-ab56-556629ce5cf9@foss.st.com/
After this, only one user of u-boot,boot-led will be left, based on
STM32: board/dhelectronics/dh_stm32mp1/board.c. @Patrice, maybe that's
something you want to have a look at as well, this seems to be some
evaluation kit?
The only users of u-boot,error-led are STM32 boards, so I'll leave this
to Patrice as well, I do not know what's the way to go for that one.
In any case, I would like to not encourage people to use out-of-spec DT
properties when there is another option (u-boot,boot-led), so I remove
the properties from the dt-binding document from U-Boot.
The help text for the blink subcommand of the led command was misleading
so this is now fixed.
This also moves the content of doc/README.LED into the doc/api/led.rst,
while clearly stating one shouldn't be using this anymore.
This also gets rid of dt-binding that we already have in dts/upstream.
Finally, this adds documentation for the led shell command.
[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116
Link: https://lore.kernel.org/r/20251112-led-old-dt-v1-0-2892d49517db@cherry.de
We're aiming to reduce the amount of U-Boot-specific and out-of-spec
Device Tree additions.
Those two properties haven't been doing anything for a long time
already, except when read by board files manually. This is still the
case for STM32 boards but those will be migrated in the near future
according to their maintainer. In any case, let's not encourage people
to add either of these properties to new or existing Device Trees and
remove it from the bindings.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This board is one of the last users of /config/u-boot,boot-led property
which is a U-Boot property out of the DT spec.
Let's migrate it to use the in-spec /options/u-boot/boot-led property.
When enabling LED_BOOT, U-Boot proper will lit the LED right before
entering the main loop, so nothing needs to be done in board files.
As explained in the commit adding support for this u-boot,boot-led
property, let's keep backward compatibility in case LED_BOOT isn't
selected.
Note that this is not tested as I do not own this device.
Cc: Alexander Dahl <ada@thorsis.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Alexander Dahl <ada@thorsis.com>
There's no code to make use of it.
Further more, the HW default state of that LED is on and migrating this
to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot
reaches its main-loop. Blinking the LED_BOOT also doesn't help because
it doesn't blink for long enough to be noticeable before it's kept on.
This is by design, c.f.
https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34
If we want this LED to be doing something different, it'll need to be
handled by a board file anyway.
Considering it hasn't worked in many years (if ever), let's just remove
it.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
There's no code to make use of it.
Further more, the HW default state of that LED is on and migrating this
to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot
reaches its main-loop. Blinking the LED_BOOT also doesn't help because
it doesn't blink for long enough to be noticeable before it's kept on.
This is by design, c.f.
https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34
If we want this LED to be doing something different, it'll need to be
handled by a board file anyway.
Considering it hasn't worked in many years, let's just remove it.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
There's not a single device making use of that code and it anyway
shouldn't be using the old deprecated u-boot,boot-led /config property
anymore but rather boot-led from /options/u-boot[1] Device Tree node.
Because spl_board_init() is only present to call this now removed
function, we can remove it as well as SPL_BOARD_INIT which is the symbol
guarding calls to spl_board_init() (which is now also removed).
[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This property is only read in arch/arm/mach-rockchip/rk3188/rk3188.c
when CONFIG_SPL_LED is enabled, which isn't the case for this board, so
let's remove dead code.
Additionally, if we ever want to enable this LED as Boot LED, we should
instead be using boot-led phandle property in /options/u-boot[1] Device
Tree node with the "new" LED UCLASS devices.
[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
doc/device-tree-bindings/leds/leds-bcm6328.txt can be found at
dts/upstream/Bindings/leds/leds-bcm6328.yaml.
doc/device-tree-bindings/leds/leds-bcm6358.txt can be found at
dts/upstream/Bindings/leds/leds-bcm6358.txt.
doc/device-tree-bindings/leds/leds-gpio.txt can be found at
dts/upstream/Bindings/leds/leds-gpio.yaml.
doc/device-tree-bindings/leds/leds-lp5562.txt can be found at
dts/upstream/Bindings/leds/leds-lp55xx.yaml.
Only two LED dt-bindings are left in U-Boot: leds-bcm6858.txt and
leds-pwm.txt. The former is partially supported by
dts/upstream/Bindings/leds/leds-bcm63138.yaml but is lacking all
optional properties we have listed in "downstream" dt-binding in U-Boot.
However, there doesn't seem to exist any user of that compatible.
The latter is partially supported by
dts/upstream/Bindings/leds/leds-pwm.yaml but is missing the
u-boot,default-brightness property, which is used by
arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi at the moment. The
default-brightness property is probably not what we want here as it
defaults to max-brightness if missing. I'm assuming we want a different
value for U-Boot (127) and the kernel (255 via max-brightness as a
default), which would prevent us from upstreaming this property, which
doesn't change the status quo, so let it be for now.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This moves the content of the legacy LED API from doc/READ.LED to
doc/api/led.rst, applying minimal cosmetic changes to "nicely" integrate
it with the current docs and adding a small introduction to the legacy
API section.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
The blink subcommand actually requires an additional parameter
(blink-freq) but not the others.
In order to simplify the help text, split the blink subcommand help text
from the off|on|toggle subcommands.
Then, fix the help text so that it is clear that the frequency is
required.
While at it, specify the duty cycle.
Fixes: ffe2052d6e ("dm: led: Add a new 'led' command")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
This is R-Car X5H support. It was originally posted before rc1 and the
changes are well isolated. This is the final patchset which enables the
Gen5 drivers that are already in tree. I waited with this a bit until
the SCMI ID discussion stabilized and TFA X5H support landed. So now, I
can add the final piece into U-Boot too.
Note that this is still very much experimental, the X5H upstreaming is
in very early stages. The OF_UPSTREAM conversion will happen likely in
2026.04 or 2026.07 window, depending on when the Linux DTs land. The
compound-clock.c is surely going to go away once SCP gets updated and
the MFIS mailbox will be reworked once upstream bindings get developed.
This also includes SH DT alignment fix.
Extend the stub PSCI implementation with support for R-Car Gen5.
R-Car Gen5 uses different register to perform reset, therefore
add a compile-time conditional. This is __secure code, therefore
the runtime SoC detection parts are not available to it, hence
the compile time conditional.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Tweak commit message
Add initial support for Renesas R-Car X5H R8A78000 Ironhide board.
This consists mainly of DTs, Makefile and Kconfig entries and board
specific configuration files.
The DTs will be gradually switched over to Linux DTs via OF_UPSTREAM
once Linux DTs become available upstream, as upstreaming progresses.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add initial device trees for Renesas R-Car X5H R8A78000 SoC.
Include very basic clock, reset, power domain headers which
are used to control supported peripherals via SCMI / SCP. The
headers are currently kept limited to avoid possible ABI break.
A lot of clock are still stubbed via fixed-clock, this is going
to be gradually removed over time, as more of the platform is
upstreamed.
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Khanh Le <khanh.le.xr@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add initial changes to support Renesas R-Car Gen5 SoC.
Introduce Kconfig entries, architecture headers and PRR IDs for Renesas
R-Car Gen5 and R-Car X5H R8A78000 SoC. Add Makefile change to produce
u-boot-elf.srec with correct offset for installation tooling. Update
MAINTAINERS entry to cover both r8a77nnn and r8a78nnn .
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add support for the Renesas MFIS mailbox, which provides an interface
between the different CPU Cores, such as AP System Core domain and the
Realtime Core domain, SCP Core domain and AP System Core domain or
Realtime Core domain and AP System Core domain or Realtime Core domain.
Signed-off-by: Tuyen Dang <tuyen.dang.xa@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Update the driver
[Marek: Rename the driver to renesas-mfis, simplify the driver.
Always use only one TX channel and no RX channel, drop all
unnecessary code. Perform 1ms delay in send callback which
is perfectly fine to do in U-Boot which does RX polling]
The current state of SCP on Renesas R-Car Gen5 is not yet final and
is still missing full clock control, the clock control is exposed as
separate enable/disable and rate controls.
Temporarily introduce custom local compound clock, which are used as
an adaptation layer between U-Boot clock tree and current state of
SCP, and which bind two SCP clock into a single compound clock, which
provides both enable/disable and rate controls.
This is mainly meant to be used by SD/eMMC controller, to allow the
driver to both turn its clock on and off, and also obtain the current
clock rate. This is going to be removed once the SCP clock protocol
solidifies.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Make sure the end of U-Boot is at 8-byte aligned offset, not 4-byte
aligned offset. This allows safely appending DT at the end of U-Boot
with the guarantee that the DT will be at 8-byte aligned offset. This
8-byte alignment is now checked by newer libfdt 1.7.2 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The Linux kernel can discover SMBIOS tables through two primary methods:
1. Via EFI tables, when using EFI boot;
2. Via the 'smbios3-entrypoint' property in the /chosen node of the
device tree.
When U-Boot boots a Linux kernel using a non-EFI command ("bootm",
"bootz", or "booti"), the kernel relies on the device tree to detect
the hardware. If SMBIOS tables are available in U-Boot, they should
be passed to the kernel via this device tree property.
This patch modifies boot_fdt_prepare(), to inject the SMBIOSv3 table
address into the device tree if there is a table generated by U-boot.
The "board_fdt_chosen_smbios" is weak in order to leave the possibilty
for specific boards to select custom SMBIOS addresses.
The changes in this patch are added in the context of supporting this
device tree property in linux kernel:
https://lkml.org/lkml/2025/10/24/1393
Device tree schema was updated to include the "smbios3-entrypoint" node
in pull request: https://github.com/devicetree-org/dt-schema/pull/177
Signed-off-by: Adriana Nicolae <adriana@arista.com>
The redundant environment offset is already set in board configuration,
but the redundant environment itself is not explicitly enabled. Make
sure the redundant environment is enabled, as we most certainly do want
to have two copies of the environment.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The CONFIG_ENV_OVERWRITE allows easy rewrite of environment variables
like 'ethaddr' and 'serial#' without any protection against accidental
removal of those variables. Remove this setting to add extra layer of
protection to those variables. The variables can still be overridden
using 'env set -f' (force set) if really needed.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
