Tom Rini [Tue, 18 Nov 2025 15:36:53 +0000 (16:36 +0100)]
nand: raw: Kconfig: Correct some dependency issues
The hidden symbol SPL_SYS_NAND_SELF_INIT was not being used correctly
leading to Kconfig dependency issues seen with "make allyesconfig". As
it's a select'd symbol we don't need to have a depends line on it, and
then in turn we need to also update the logic on SYS_NAND_PAGE_SIZE and
SYS_NAND_OOBSIZE.
Miquel Raynal [Tue, 18 Nov 2025 15:32:24 +0000 (16:32 +0100)]
mtd: spinor: winbond: Describe several chips
All these chips are dual and quad capable. They are also DTR capable,
but the core is not yet ready for that.
Performances of all chips are comparable at 30MHz and are as follow:
Eraseblock single read speed: 938kiB/s
Eraseblock dual read speed: 1068kiB/s
Eraseblock quad read speed: 3751kiB/s
Tom Rini [Tue, 18 Nov 2025 18:51:22 +0000 (12:51 -0600)]
Merge patch series "'part name' subcommand and some robustification"
Rasmus Villemoes <ravi@prevas.dk> says:
Implement a "part name" subcommand, mirroring the existing "part
number" subcommand.
In the discussion for v1 of that, it came up that there's a bit of
inconsistency in how much and what one can assume to be initialized in
'struct disk_partition' after a successful call of one of the
get_info* family of functions. Patch 1/2 tries to consolidate
that by making sure all ->get_info invocations go through a common
helper that at least always initializes the string members.
Quentin, I've taken the liberty of including your Acks, as the
incremental diff in patch 1 is quite minor, but do speak up if I
should not have done that.
Rasmus Villemoes [Mon, 10 Nov 2025 20:54:10 +0000 (21:54 +0100)]
disk/part.c: ensure strings in struct disk_partition are valid after successful get_info
Not all ->get_info implementations necessarily populate all the string
members of struct disk_partition.
Currently, only part_get_info_by_type() (and thereby part_get_info)
ensure that the uuid strings are initialized; part_get_info_by_type()
and part_get_info_by_uuid() do not. In fact, the latter could lead to
a false positive match - if the ->get_info backend does not populate
info->uuid, stale contents in info could cause the strncasecmp() to
succeed.
None of the functions currently ensure that the ->name and ->type
strings are initialized.
Instead of forcing all callers of any of these functions to
pre-initialize info, or all implementations of the ->get_info method
to ensure there are valid C strings in all four fields, create a small
helper function and factor all invocations of ->get_info through that.
This also consolidates the -ENOSYS check and standardizes on using
log_debug() for reporting absence, instead of the current mix of
PRINTF and log_debug(). It does mean we have to special-case -ENOSYS
in the error cases inside the loops in the _by_uuid() and _by_name()
functions, but it's still a net win in #LOC.
Tom Rini [Tue, 18 Nov 2025 18:50:38 +0000 (12:50 -0600)]
Merge patch series "remoteproc: k3-r5: Build fixes and security improvements"
Philippe Schenker <philippe.schenker@impulsing.ch> says:
This series fixes compilation errors when building for R5 cores and
addresses a security issue where authenticated images were not being
used correctly.
Patch 1: Cosmetic removal of duplicate code
Patches 2-3: Fix build errors caused by type mismatches between
function signatures and the types used in R5 builds.
Patches 4-5: fix a bug where ti_secure_image_post_process() relocates
images during authentication, but callers were still using the original
unverified addresses.
Add is_running callback to query the R5F core halt status via the
TI-SCI processor control API. This allows the remoteproc framework
to determine whether the R5F core is currently runnin.
The core is considered running when the PROC_BOOT_CTRL_FLAG_R5_CORE_HALT
bit is not set in the control flags.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch> Reviewed-by: Andrew Davis <afd@ti.com>
After ti_secure_image_post_process() authenticates the image, it may
relocate it to a different memory location and update image_addr to
point to the verified image.
However, rproc_elf_load_image() and rproc_elf_get_boot_addr() were
still using the original "addr" parameter, potentially operating on
the unverified or stale image location instead of the authenticated
image.
Use image_addr (cast to ulong to match function signatures) after
authentication to ensure all operations work with the verified image.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
The ti_secure_image_check() function may relocate the image during
authentication, updating image_addr to point to the verified location.
The caller was not updated with this new address, causing it to
reference the original unverified location.
Update p_image with the verified image address after authentication
to ensure subsequent operations use the correct location.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
When compiling for R5 with CONFIG_TI_PRUSS enabled, the
pruss_probe() function passed a u64* to ofnode_get_addr_size_index(),
which expects an fdt_size_t*. This caused a compiler error
about incompatible pointer types.
Cast the size pointer to fdt_size_t* to match the function
signature.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch>
When compiling for R5 core with CONFIG_REMOTEPROC_TI_K3_R5F,
passing 'size' (ulong) to ti_secure_image_post_process() caused
a type mismatch compiler error.
On platforms where ulong and size_t differ in size, directly
casting could lead to out-of-bounds memory access. Fix by
introducing a size_t temporary variable, passing it to the
function, and writing back the potentially modified value for
use in subsequent calls.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch> Acked-by: Andrew Davis <afd@ti.com>
The device tree contained a duplicate DT node 'main_mmc1_pins_default',
which was already defined a few lines below. This patch removes the
redundant entry.
Signed-off-by: Philippe Schenker <philippe.schenker@impulsing.ch> Reviewed-by: Anshul Dalal <anshuld@ti.com>
Partially reverted commit "soc: qcom: cmd-db: drop unused
functions" by restoring only the cmd_db_read_slave_id() and
cmd_db_read_aux_data() functions, which were removed in that
commit. These functions are required for the RPMH Power Domain
Driver.
dhelectronics:
- Move dh_add_item_number_and_serial_to_env() to common code
- Read values from M24256 write-lockable page on STM32MP13xx DHCOR
- Add MAC address readout from fuses on DH STM32MP1 DHSOM
- Keep the reg11 and reg18 regulators always enabled on STM32MP13xx DHCOR.
- Fix boot for stm32mp15xx-dhsom.
- Fix build of ST DFU virt code on DH STM32MP1 DHSOM
- Introduce DH STM32MP13x target.
STM32MP2:
- Add support for stm32mp257-dk board.
- Fix arm, smc-id value for stm32mp23/25.
- Fix stm32mp235f-dk boot (add syscon compatible, add txbyteclk).
- Add display support:
- Introduce LVDS driver.
- Add LTDC support.
- Add Ethernet support for stm32mp255.
STM32MP13:
- Add ADC support.
- Add power check for stm32mp135f-dk board.
Marek Vasut [Thu, 23 Oct 2025 21:48:26 +0000 (23:48 +0200)]
ARM: stm32: Add MAC address readout from fuses on DH STM32MP1 DHSOM
Add support for reading out the MAC address from SoC fuses on DH STM32MP1 DHSOM.
The DH STM32MP1 DHSOM may contain external ethernet MACs, which benefit from the
MAC address stored in SoC fuses as well, handle those consistently. This however
means the architecture setup_mac_address() cannot be used and instead a simpler
local fuse read out is implemented in the board file.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Thu, 23 Oct 2025 21:48:25 +0000 (23:48 +0200)]
ARM: stm32: Read values from M24256 write-lockable page on STM32MP13xx DHCOR
The STM32MP13xx DHCOR SoM is populated with M24256 EEPROM that contains
an additional write-lockable page called ID page, which is populated with
a structure containing ethernet MAC addresses, DH item number and DH serial
number.
Read out the MAC address from the WL page between higher priority SoC fuses
and lower priority plain EEPROM storage area. Read out the DH item and serial
numbers and set environment variables accordingly.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Fri, 31 Oct 2025 04:16:09 +0000 (05:16 +0100)]
ARM: stm32: Add missing build of ST DFU virt code on DH STM32MP1 DHSOM
Commit 6d91f0a3a14d ("board: st: common: cleanup dfu support") split
the vendor-specific DFU implementation into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
with plain simple dfu-util, but it makes the ST proprietary programmer
CLI tool end in an infinite loop. Update the Makefile accordingly to
allow even that kind of tooling to work.
Marek Vasut [Thu, 23 Oct 2025 21:46:05 +0000 (23:46 +0200)]
ARM: dts: stm32: Fix STM32MP15xx DHSOM boot breakage due to ETZPC
Switch etzpc bus to simple-bus to prevent breakage on non-TFA systems.
This fixes boot of every STM32MP15xx DHSOM device.
Fixes: ad3cdc677dda ("ARM: stm32mp: add ETZPC system bus driver for STM32MP1") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Asadeds [Tue, 28 Oct 2025 05:39:26 +0000 (11:09 +0530)]
arm: stm32mp25: add ethernet support for stm32mp255 series
Add missing CPU_STM32MP255* cases in get_eth_nb() so that U-Boot
correctly reports 2 Ethernet interfaces on stm32mp255 devices.
This fixes the "ethernet not found" error during boot.
video: stm32: ltdc: properly search the first available panel
Initially there was only one DSI bridge with one panel attached to this
device. This explained the call to uclass_first_device_err(UCLASS_PANEL,
...) which worked fine at the time.
Now that multiple bridges and panels, with different technologies, can
be plugged onto the board this way to get the panel device is outdated.
The lookup is done is two steps. First we circle through the
UCLASS_VIDEO_BRIDGE, and once we get one, we search through its
endpoints until we get a UCLASS_PANEL device available.
video: stm32: ltdc: support new hardware version for STM32MP25 SoC
STM32MP2 SoCs feature a new version of the LTDC IP. This new version
features a bus clock, as well as a 150MHz pad frequency. Add its
compatible to the list of device to probe and handle quirks. The new
hardware version features a bus clock.
The LVDS Display Interface Transmitter handles the LVDS protocol:
it maps the pixels received from the upstream Pixel-DMA (LTDC)
onto the LVDS PHY.
The LVDS controller driver supports the following high-level features:
• FDP-Link-I and OpenLDI (v0.95) protocols
• Single-Link or Dual-Link operation
• Single-Display or Double-Display (with the same content
duplicated on both)
• Flexible Bit-Mapping, including JEIDA and VESA
• RGB888 or RGB666 output
• Synchronous design, with one input pixel per clock cycle
• No resolution limitation.
video: simple_panel: add support for "panel-lvds" display
Add the compatible "panel-lvds" for simple-panel driver in U-Boot. In
Linux this compatible is managed by the driver
drivers/gpu/drm/panel/panel-lvds.c but in U-Boot the specific LVDS
features (bus_format/bus_flags) are not supported.
ofnode: support panel-timings in ofnode_decode_display_timing
The "Display Timings" in panel-common.yaml can be provided by 2 properties
- panel-timing: when display panels are restricted to a single resolution
the "panel-timing" node expresses the required timings.
- display-timings: several resolutions with different timings are supported
with several timing subnode of "display-timings" node
This patch update the parsing function to handle this 2 possibility
when index = 0.
Olivier Moysan [Fri, 14 Nov 2025 16:08:52 +0000 (17:08 +0100)]
adc: stm32mp13: add support of adc to stm32mp13
Add support of STM32 ADCs to STM32MP13x. This patch introduces
stm32_adc_regspec structure, as this is already done in kernel
driver, to manage smartly the differences in register set
between STMP32MP15 and STM32MP13 ADCs.
Tom Rini [Wed, 12 Nov 2025 21:18:41 +0000 (15:18 -0600)]
ufs: rcar-gen5: Use a unique U_BOOT_DRIVER name
All instances of U_BOOT_DRIVER must be unique or we will have link time
failures. It is possible to enable both ufs-renesas-rcar.c and
ufs-renesas-rcar-gen5.c at the same time, so give
ufs-renesas-rcar-gen5.c a new unique U_BOOT_DRIVER name.
Fixes: 3351fe7ecc1a ("ufs: Add UFS driver for Renesas R-Car X5H") Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://patch.msgid.link/20251112211841.1428696-1-trini@konsulko.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
* Correct the linux/arm64 platform string for Docker builds
* Complete pytest dependencies list with missing packages
UEFI:
* Use Sphinx style comments in efi_selftest_console.c
* Don't include asm/global_data.h in lib/efi_client/efi_app.c twice
* efi_client: correct memset() return value
* Assure fitImage from capsule is used from 8-byte aligned address
* Fix warning when building efi_selftest_snp with clang
Marek Vasut [Thu, 13 Nov 2025 11:55:49 +0000 (12:55 +0100)]
efi_loader: Assure fitImage from capsule is used from 8-byte aligned address
The fitImage may be stored in EFI update capsule at address that
is not aligned to 8 bytes. Since fitImage is a DT, new version of
libfdt 1.7.2 rejects such an unaligned DT. Patch the code and copy
the fitImage into aligned buffer in case it is not aligned. This
does increase overhead for unaligned fitImages in EFI capsules, but
tries to keep the overhead low for aligned ones.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tom Rini [Thu, 6 Nov 2025 23:28:39 +0000 (17:28 -0600)]
efi_selftest: efi_selftest_snp: Fix warning when building with clang
When building with clang, we see a warning:
lib/efi_selftest/efi_selftest_snp.c:63:18: error: field dhcp_hdr within
'struct dhcp' is less aligned than 'struct dhcp_hdr' and is usually due
to 'struct dhcp' being packed, which can lead to unaligned accesses
[-Werror,-Wunaligned-access]
when building lib/efi_selftest/efi_selftest_snp.c. Resolve this error by
packing struct dhcp_hdr as well, as the only place it is used also is
packed.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Rev.0.81 of the R-Car V4M Series Hardware User’s Manual removed the
"STPWT_EXTFXR" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Huy Bui [Fri, 7 Nov 2025 16:16:56 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779h0: Remove CC5_OSCOUT
Rev.0.71 of the R-Car V4M Series Hardware User’s Manual removed the
"CC5_OSCOUT" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Huy Bui [Fri, 7 Nov 2025 16:16:55 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779g0: Remove STPWT_EXTFXR
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"STPWT_EXTFXR" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Huy Bui [Fri, 7 Nov 2025 16:16:54 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779g0: Remove CC5_OSCOUT
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"CC5_OSCOUT" signal from the pin control register tables. As this is
further unused in the pin control driver, it can be removed safely.
Thanh Quan [Fri, 7 Nov 2025 16:16:53 +0000 (17:16 +0100)]
pinctrl: renesas: r8a779g0: Remove AVB[01]_MII
Rev.1.30 of the R-Car V4H Series Hardware User’s Manual removed the
"AVB[01]_MII_*" signals from the pin control register tables. As these
are further unused in the pin control driver, they can be removed
safely.
Signed-off-by: Thanh Quan <thanh.quan.xn@renesas.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tom Rini [Fri, 26 Sep 2025 15:30:34 +0000 (09:30 -0600)]
usb: gadget: Tighten CI_UDC dependencies
This driver cannot build when DM_USB_GADGET is enabled as both options
control building of files that use the same global namespace and
functionality. In this case make CI_UDC depend on DM_USB_GADGET being
disabled as non-DM support is the legacy choice.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Tom Rini [Fri, 26 Sep 2025 15:30:33 +0000 (09:30 -0600)]
usb: host: xhci: Make U_BOOT_DRIVER entries unique
All instances of the U_BOOT_DRIVER must use a unique name or they will
lead to link time failures due to name space conflicts when both are
present. Most of the XHCI drivers follow pattern of xhci_xxx in their
name, but a few used "usb_xhci". Change these to follow the pattern of
the rest of the XHCI glue drivers.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Peter Robinson [Fri, 26 Sep 2025 15:30:31 +0000 (09:30 -0600)]
usb: musb: drop musb legacy drivers
The last of the users of the legacy musb drivers have been
migrated so now remove the old musb stack, all users should
now be using the new musb stack if they need this functionality.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[trini: Remove a Makefile reference that was missed in v1] Signed-off-by: Tom Rini <trini@konsulko.com>
Peter Robinson [Fri, 26 Sep 2025 15:30:30 +0000 (09:30 -0600)]
omap3: evm: Drop old musb omap3 driver
The USB_OMAP3 driver was (re)added in commit e74e9f620a6 as part
of migrating to DM_USB but the config already had MUSB_OMAP2PLUS
which is the newer musb driver and what other omap3 devices use.
So drop it so we can drop the old driver.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Tom Rini [Fri, 3 Oct 2025 20:39:22 +0000 (14:39 -0600)]
usb: gadget: spl: Add missing dependency for SPL_USB_GADGET
It makes no sense to ask about nor enable SPL_USB_GADGET without
SPL_FRAMEWORK being enabled. Attempting to do so leads to Kconfig noting
dependency issues. Add the missing dependency.
Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Tom Rini [Wed, 12 Nov 2025 15:42:50 +0000 (09:42 -0600)]
Merge patch series "ti: add speed grades support for AM62a"
Anshul Dalal <anshuld@ti.com> says:
TI offers SoCs in various speed grades, each speed grade specifies a
certain maximum operating frequency of the clocks for each core.
In K3's boot flow, the R5 SPL starts the A53 or A72 core and configures
the correct clocks and power using the K3 ARM64 rproc driver
(compatible: ti,am654-rproc). However, the driver expects the dt node
for the ARM64 core to be set with a correct "assigned-clock-rates"
value.
Currently the dt has a value of 1.2GHz for the A53 core on AM62a, this
is incorrect for lower speed grades. Therefore this patch set adds
support for fixing this value at runtime based on the detected speed
grade from the efuse MMR.
For the speed grade table, refer to Table 6-1 of the AM62a datasheet.
Anshul Dalal [Thu, 30 Oct 2025 13:03:22 +0000 (18:33 +0530)]
mach-k3: am62a: add support for speed grades
Speed grades indicate the maximum operating frequency of any core on the
SoC. This patch adds support for the same to AM62a, this allows the A53
core to be started with the correct frequency by the R5 SPL.
The K3 ARM64 rproc driver uses the "assigned-clock-rates" value in the
respective "/a53@0" node to properly configure the clocks for the A53
core.
Although the clock value in the DT node might need to be fixed based on
SoC's speed grade at runtime. Certain SoCs such as AM62p and AM62x
already had this implemented, this patch moves the common code to
common.c to avoid duplication and simplify speed grade handling.
The logic to detect the correct entry in the "assigned-clock-rates"
property has also changed. Where we earlier relied on per SoC specific
device and clock IDs for the A53 core, we now use the "clock-names"
property which is device agnostic.
fdt_fixup_cpu_freq_nodes_am62p is used to delete unsupported opp table
entries at runtime based on the SoC's speed grade.
However, the ti-cpufreq driver in kernel already has support for
rejecting unsupported entries. Therefore this fdt fixup is not necessary
and can be dropped.
Fixes: 8d05cbef73ae ("arm: mach-k3: am62p: Fixup a53 max cpu frequency by speed-grade") Signed-off-by: Anshul Dalal <anshuld@ti.com>
Add the compatible string of Exynos7's PMU as defined in upstream
dt-schema. This also supports derivative PMUs as defined in schema.
There's no additional setup required here, so pmu_init is skipped.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Add the compatible for Exynos8895 UART as described in upstream
devicetree bindings. This enables support for Exynos8895 and other
similar UART devices, such as Exynos7870. Other than that, the driver
works as-is.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Reviewed-by: Henrik Grimler <henrik@grimler.se> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
pinctrl: exynos78x0: add proper support for exynos7870 pinctrl
The pinctrl blocks for Exynos7870 and Exynos7880 are similar, however in
Exynos7870, the CCORE block is actually referred to as MIF. Since
ordering happens lexically, it isn't directly compatible with
samsung,exynos78x0-pinctrl.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
pinctrl: exynos: bind GPIO driver along with pinctrl
The devicetree of Samsung devices typically have the pin controller and
GPIO bank descriptors under the same pinctrl node. In U-Boot, these are
handled by two separate drivers. It is not possible to invoke both
drivers from a single node compatible.
Bind the GPIO driver on pinctrl driver bind, with the same OF node as
the pinctrl driver. This solution is already being used in other pinctrl
drivers. The hierarchy, as represented in `dm tree`, is as follows:
There may be cases where the flags set for a clock is not available.
This is usually the case with clocks which have been retrieved using
clk_request(). However, clock flags are found in their respective
private clock struct, so use that instead.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Introduce a simple clock driver for Exynos7870's CMU blocks, more
specifically, CMU_MIF, CMU_FSYS, and CMU_PERI banks. This should be
enough to serve U-Boot's minimal requirements.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
clk: exynos: add function for Samsung CMU ops->request
The request function performs a simple check if the clock with the
provided ID is present or not. This is done with a simple call to
clk_get_by_id(). A non-zero return value indicates that the requested
clock is not available.
In some cases, clk->dev points to the clock bank device instead of
the clock device. This pointer is therefore overwritten in order to
reference to the correct device instance.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
PLL1417X seem to be compatible with PLL0822X, as also seen in the
respective Linux kernel driver. Add an enum entry for the type, while
merely being an alias for PLL0822X.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
clk: exynos: add support for fixed rate and fixed factor clocks
Add register functions for fixed rate and fixed factor clock drivers.
The vendor-specific structs defined are borrowed from the CCF driver
found in the Linux kernel.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
clk: exynos: provide device pointer to clk_register_* functions
The device pointer set as NULL causes problems when clock banks depend
on clocks from another clock bank. In such case, the appropriate clock
needs to be resolved from OF phandle arguments, which is not possible if
the associated device is not provided. Make necessary changes to make
the correct device pointer available.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Tom Rini [Tue, 11 Nov 2025 20:53:47 +0000 (14:53 -0600)]
Merge patch series "reenable dm_gpio tests, add support for gpio-line-names lookup"
Rasmus Villemoes <ravi@prevas.dk> says:
Hopefully third time's the charm.
I merely wanted to add support (mostly for use by the 'gpio' shell
command) for looking up a gpio via the gpio-line-names DT property. We
already have a "gpio_request_by_line_name()", but cmd/gpio.c does a
separate "lookup + request", so it felt more natural to teach the
lookup machinery this as well. That ran into
OF_CONTROL-but-not-OF_LIBFDT being a thing for SPL, so here's yet
another attempt.
Now, when trying to do my civic duty and add tests for this, I found
that test/dm/gpio.c has been defunct for a couple of years, and
reinstating it is not entirely trivial.
After a couple of rounds CI is now happy with this:
https://github.com/u-boot/u-boot/pull/828
gpio: search gpio-line-names property in dm_gpio_lookup_name
In scripts as well as interactively, it's much nicer to be able to
refer to GPIOs via their names defined in the device tree property
"gpio-line-names", instead of the rather opaque names derived from the
bank name with a _xx suffix. E.g.
gpio read factory_reset FACTORY_RESET
if test $factory_reset = 1 ; then ...
versus
gpio read factory_reset gpio@481ac000_16
if test $factory_reset = 1 ; then ...
This is also consistent with the move on the linux/userspace side towards
using line names instead of legacy chip+offset or the even more legacy
global gpio numbering in sysfs.
As dev_read_stringlist_search() depends on both OF_CONTROL and
OF_LIBFDT (which matters for the SPL case), we need some .config
conditional. However, it only adds about ~50 bytes of code to U-Boot
proper, and dm_gpio_lookup_name() most often ends up being GC'ed for
SPL, thus adds no overhead there, so for now make it a hidden symbol
which is merely a convenient shorthand for
CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(OF_LIBFDT).
Commit ebaa3d053e5 ("test: fix CONFIG_ACPIGEN dependencies"), which
got into v2022.10-rc1, accidentally left out a $
before (CONFIG_DM_GPIO), with the effect that test/dm/gpio.c has not
been built for three years.
Unsurprisingly, the code in there has bit-rotted.
- There's a missing ; causing plain build fail.
That code was added in 9bf87e256c2 ("test: dm: update test for
open-drain/open-source emulation in gpio-uclass"), which was part of
v2020.07-rc3, i.e. long before the commit causing gpio.c to not be
built at all. It did build at that time, but also, the missing
semicolon wasn't found when fa847bb409d ("test: Wrap assert macros
in ({ ... }) and fix missing semicolons") happened in 2023.
- Commit 592b6f394ae ("led: add function naming option from linux")
bumped sandbox,gpio-count for bank gpio_a in test.dts to 25, but
didn't update the expected global gpio numbers accordingly.
- The "lookup by label" test likely worked when it was added, but then I
inadvertently broke it when I noticed that dm_gpio_lookup_label()
seemed to be broken in commit 10e66449d7e ("gpio-uclass: fix gpio
lookup by label") - which landed in v2023.01-rc1, so after gpio.c
was no longer being built.
The "label" (which is a u-boot concept) that a "hogged gpio" gets is
<gpio hog node name>.gpio-hog, which is why it used to work with the
strncmp() but doesn't with strcmp().
We can either revert 10e66449d7e or append the ".gpio-hog" suffix as
done below. I don't really have a dog in that race; when I did 10e66449d7e, it was because I thought the "lookup by label" was
actually about the standardized gpio-line-names property, but then I
learnt it was not, so is not at all useful to me.
And it fails with the same differences (160/176) even if I
remove the three lines that actually exercise any of the gpio code,
i.e. make the whole function amount to
So I suspect that the leak is somewhere in the test framework
setup/teardown code - dm_leack_check_end() isn't really used
anywhere else except in a dm/core test. Bisecting to figure out
where that was introduced is somewhat of a hassle because of the
other bitrot, and because of the SWIG failure that makes it very
hard to build older U-Boots.
So since it's better to have most of the gpio tests actually
working instead of leaving all of gpio.c as dead code, #if 0 that
part out and leave it as an archeological exercise.
Tom Rini [Tue, 11 Nov 2025 20:53:33 +0000 (14:53 -0600)]
Merge patch series "rsa: fix dependency, rename and relocate RSASSA PSS symbols"
Quentin Schulz <foss+uboot@0leil.net> says:
While historically signature verification is mostly done for FIT such
FIT_SIGNATURE dependency for signature algorithm makes sense, it isn't
the only kind of file we can verify signatures of. It can also be done
manually with rsa_verify_hash() with an embedded public key.
Considering the impacted code is guarded by RSA_VERIFY, let's make the
symbol depend on that otherwise selecting it without RSA_VERIFY won't do
anything. The FIT_SIGNATURE dependency wasn't also enough before as it
only implied RSA_VERIFY.
Then, simply relocate the RSA SSA PSS padding with the other RSA symbols
in lib/rsa instead of in boot/ and rename it to remove the mention to
FIT.
Finally, add the PSS padding wherever PKCS1.5 padding is specified as
one or the other can be used.
Quentin Schulz [Fri, 31 Oct 2025 17:08:24 +0000 (18:08 +0100)]
rsa: update doxygen doc for RSA signature verification to mention PSS
While the verification step originally only supported PKCS1.5 as padding
algorithm for the signature, it was later extended to add support for
PSS but the doxygen doc wasn't updated to reflect that so let's fix
that oversight.
Fixes: 061daa0b61f0 ("rsa: add support of padding pss") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Quentin Schulz [Fri, 31 Oct 2025 17:08:23 +0000 (18:08 +0100)]
rsa: rename FIT_RSASSA_PSS to RSASSA_PSS and move symbols under lib/rsa
This renames FIT_RSASSA_PSS symbols to drop the FIT_ prefix to avoid
potential confusion since there's nothing FIT specific to those symbols.
It also isn't really related to booting, so boot/Kconfig is an odd place
for them to live. Since they make sense only in relation with RSA,
simply move them to lib/rsa where it makes more sense for them to
reside.
Quentin Schulz [Fri, 31 Oct 2025 17:08:20 +0000 (18:08 +0100)]
boot: fix incorrect dependency of FIT_RSASSA_PSS
This padding has nothing to do with FIT except that we can make use of
it when verifying the FIT signatures.
This padding can also be used to verify the signature "manually" e.g. by
calling rsa_verify_hash() directly with an embedded public key.
Additionally, this padding is only useful if RSA (and specifically
RSA_VERIFY) is enabled otherwise it's not used.
The only other place it's used is in rsa-sign.c which is only built for
the host tools and handled by TOOLS_FIT_RSASSA_PSS symbol instead, so no
need to care for that one.
Finally, the FIT_SIGNATURE dependency also wasn't enough because it only
implies RSA_VERIFY, meaning it can be disabled and still have
FIT_RSASSA_PSS enabled.
So add a dependency on RSA_VERIFY and reword the input prompt.
Tom Rini [Thu, 6 Nov 2025 23:28:35 +0000 (17:28 -0600)]
Gitlab: Optimize the job dependency list more
In general, we want to fail the whole pipeline as soon as we can if we
spot an error while also letting bigger jobs get started as soon as
possible. Currently we use the "Run binman, buildman, dtoc, Kconfig and
patman testsuites" job from the testsuite stage to unblock the next
stage as this test is complex enough that if it passes, likely the whole
stager will pass. Using this same logic, unblock the world build (and
sjg-lab) stages if "sandbox test.py" has completed as if there's no
failures here, there's likely not failures in the rest of the test.py
stages.
Bin Meng [Wed, 5 Nov 2025 11:07:24 +0000 (19:07 +0800)]
scsi: Fix the name string memory leak during scsi scan
There is a memory leak during the scsi scan process due to the
strdup'ed name string is never freed. Actually it is unnecessary
to pass a strdup'ed name string to blk_create_devicef() as we can
use the name string on the stack directly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
qfw: Fix segfault from uninitialized variables in sandbox
There are cases where qfw_read_entry() does not set the output parameter
passed by address. This occurs with qfw_sandbox_read_entry_dma, which
leaves the size variables uninitialized and causes a segfault when running
bootflow scan in U-Boot sandbox.
$ ./u-boot
...
U-Boot 2026.01-rc1-00199-gc2637036b8f0 (Nov 04 2025 - 10:32:21 +0100)
...
Hit any key to stop autoboot: 0
=> bootflow scan
efi_var_to_file() Cannot persist EFI variables without system partition
efi_tcg2_register() Missing TPMv2 device for EFI_TCG_PROTOCOL
efi_rng_register() Missing RNG device for EFI_RNG_PROTOCOL
scanning bus for devices...
[3] 1015761 segmentation fault (core dumped) ./u-boot
Initalize all these variables to 0 to fix this issue.
- Support scmi v3.2 CONFIG_SET for clock protocol
- A patchset from Marek to optimize the scmi clk booting time
- Fix scmi clk set_parent in non-CCF case
- Drop mmu_set_region_dcache_behaviour in firmware scmi
Tom Rini [Sat, 1 Nov 2025 15:32:01 +0000 (09:32 -0600)]
CI: Move to Ubuntu 24.04 'Noble' as the base
The changes here are that we need to ensure python setuptools are
in our build virtual environments as they will no longer come in via
python even in a virtual environment. As part of this ensure setuptools
is in our cache and also include pytest-azurepipelines as we should have
been doing. Next, we move away from using apt-key directly and move that
stanza towards the rest of the apt work. This also lets us drop
directly installing gnupg2. These steps are not strictly required for
24.04 but will be for later releases and are valid now. Finally, we drop
the unused PTYHONPATH ENV line.
In order to use these containers however, we need to stop running the
event_dump test as the 'addr2line' tool provided by binutils no longer
is able to decode those specific events in most cases. As this is a
problem with binutils and present for some time now, disabling the test
until someone has time to work with upstream this seems reasonable.
Tom Rini [Sun, 2 Nov 2025 20:08:12 +0000 (14:08 -0600)]
dm: Remove pre-schema tag support
Support for using "u-boot,dm-..." rather than "bootph-..." has been
deprecated since February 2023. Any platforms using this have had a
console message saying to migrate by 2023.07. Go and remove all support
here now, for the v2026.01 release.
The results of this change that aren't clear from the above are that we
still have a checkpatch.pl error message, and document in
doc/develop/spl.rst that they have been migrated since 2023. We also
change the key2dtsi.py tool to use the correct bootph phase rather than
the legacy phase.
projects / thirdparty / u-boot.git / log
