u-boot.git/drivers/soc, branch master

soc: xilinx: zynqmp: Add TCG variant detection for ZU3TCG

2026-07-08T06:55:51Z

The XCZU3TCG device shares IDCODE 0x04718093 with XCZU3TEG but has the GPU disable eFuse bit set (Consumer Grade, no GPU). Previously, the TEG detection branch appended "teg" unconditionally, causing U-Boot to report the device as zu3teg and failing bitstream ID checks for xczu3tcg bitstreams. Check EFUSE_GPU_DIS_MASK in the TEG branch to distinguish the two sub-variants, mirroring the existing EG/CG detection logic: - GPU disabled -> TCG family -> "zu3tcg" - GPU enabled -> TEG family -> "zu3teg" Fixes: fa2f0c97af96 ("soc: zynqmp: Add the IDcode for TEG variant") Signed-off-by: Padmarao Begari Signed-off-by: Michal Simek Link: https://patch.msgid.link/20260623150943.2662500-1-padmarao.begari@amd.com

Kconfig: drivers: restyle remaining

2026-06-25T21:00:58Z

Restyle all Kconfigs for the rest of "drivers": Menu entries : no space left Menu attributes: 1 TAB Help text : 1 TAB + 2 spaces Replace '---help---' by 'help' Signed-off-by: Johan Jonker [trini: Add missing indentation on a few more multi-paragraph help texts] Signed-off-by: Tom Rini

soc: xilinx: zynqmp: Add support for new ZynqMP devices

2026-04-23T09:49:48Z

Add ID codes for the following ZynqMP devices: - XCZU1EG_LR (0x0468A093) - XCZU42DR (0x046D4093) - XCZU55DR (0x046D2093) - XCZU57DR (0x046D3093) - XCZU58DR (0x047F9093) - XCZU59DR (0x047FC093) - XCZU63DR (0x046D5093) - XCZU64DR (0x046D6093) - XCZU65DR (0x046D1093) Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/330098196cc84115899ea7a14665a8df7e279fae.1775557948.git.michal.simek@amd.com

qcom: rpmh: don't error for SLEEP requests

2026-03-24T10:49:17Z

Just stub out non-active votes, if we return an error the caller may propagate it and not send its active vote. Since we don't suspend there's no risk of us entering a broken state due to missing votes. Link: https://patch.msgid.link/20260320-casey-qcom-rpmh-serial-fixes-v1-2-b81d05832eec@linaro.org Signed-off-by: Casey Connolly

soc/qcom: rpmh: add RPMh read

2026-01-14T15:25:09Z

Implement support for RPMh reads, these allow reading out the current votes for RPMh controlled resources such as regulators and interconnects. Link: https://patch.msgid.link/20260108-rpmh-regulator-fixes-v1-4-d1b5b300b665@linaro.org Signed-off-by: Casey Connolly

soc/qcom: rpmh: correctly wait for TCS flush

2026-01-14T15:25:09Z

Several bugs were discovered in the rpmh-rsc driver which collectively meant we were never actually waiting for the TCS to flush, these were likely missed because U-Boot runs single threaded and the RPMh had typically processed the single command we sent by the time we went to send the next one. However a future patch will implement rpmh read support which requires us to properly wait for the RPMh command response so we can return the value. Fix these issues so we correctly ensure the TCS is done before returning. Link: https://patch.msgid.link/20260108-rpmh-regulator-fixes-v1-3-d1b5b300b665@linaro.org Signed-off-by: Casey Connolly

soc/qcom: rpmh: document rsc registers

2026-01-14T15:25:09Z

Add some comments explaining a few of the RSC registers Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20260108-rpmh-regulator-fixes-v1-2-d1b5b300b665@linaro.org Signed-off-by: Casey Connolly

soc: qcom: rpmh-rsc: reclaim the TCS to avoid spurious irq in Linux

2026-01-14T15:25:09Z

If we don't reclaim and clear the IRQ bits, we might get a spurious interrupt from this TCS in Linux: WARNING: CPU: 0 PID: 0 at drivers/soc/qcom/rpmh-rsc.c:451 tcs_tx_done+0x98/0x270 ... Call trace: tcs_tx_done+0x98/0x270 (P) __handle_irq_event_percpu+0x60/0x220 handle_irq_event+0x54/0xc0 handle_fasteoi_irq+0xa8/0x1c0 handle_irq_desc+0x3c/0x68 generic_handle_domain_irq+0x24/0x40 gic_handle_irq+0x5c/0xd0 ... Signed-off-by: Neil Armstrong Link: https://patch.msgid.link/20260108-rpmh-regulator-fixes-v1-1-d1b5b300b665@linaro.org Signed-off-by: Casey Connolly

dm: core: Default to using DEVRES outside of xPL

2026-01-09T15:08:14Z

The devm alloc functions that we have may follow the Linux kernel model where allocations are (almost always) automatically free()'d. However, quite often we don't enable, in full U-Boot, the tracking and free()'ing functionality. This in turn leads to memory leaks because the driver author expects that since the functions have the same name as in the Linux Kernel they have the same behavior. In turn we then get functionally correct commits such as commit 00e1fed93c8c ("firmware: ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually add these calls. Rather than manually tracking allocations and implementing free()s, rework things so that we follow expectations by enabling the DEVRES functionality (outside of xPL phases). This turns DEVRES from a prompted symbol to a symbol that must be select'd, and we now remove our non-managed alloc/free functions from outside of xPL builds. Reviewed-by: Michael Trimarchi Signed-off-by: Tom Rini

Merge tag 'v2026.01-rc4' into next

2025-12-08T19:17:27Z

Prepare v2026.01-rc4