Tom Rini [Mon, 6 Jul 2026 14:12:19 +0000 (08:12 -0600)]
Merge patch series "Remove patman from the U-Boot tree"
Simon Glass <sjg@chromium.org> says:
patman is now maintained as a standalone 'patch-manager' package, so
remove it from the tree. The command becomes a stub that tells people to
run 'pip install patch-manager'.
buildman still imports the shared modules commit and patchstream (along
with their dependencies), so this series leaves those in place. It drops
the tool's code, tests, CI hooks and packaging, and removes the in-tree
documentation, moving the b4 contributor guide alongside the patman note
in the patch-sending docs. It also adds a .patman-defaults file so the external
tool is set up for U-Boot, next to the existing .b4-config. Where the CI
jobs relied on patman's requirements for the setuptools that pylibfdt
needs, they now install scripts/dtc/pylibfdt/requirements.txt instead.
More could be done here: commit and patchstream (and their dependencies
series, get_maintainer and settings) only remain because buildman still
imports them. A follow-up could move those into u_boot_pylib (or
buildman itself) and drop the rest, leaving tools/patman as just the
stub.
Simon Glass [Sun, 5 Jul 2026 19:32:17 +0000 (13:32 -0600)]
patman: Remove the patch-management code
Delete the command-line tool and its supporting modules, now that this
functionality lives in the standalone patch-manager package.
Keep the modules that buildman still imports (commit and patchstream,
plus their dependencies series, get_maintainer and settings), along with
the stub command. Trim __init__.py to match.
Simon Glass [Sun, 5 Jul 2026 19:32:16 +0000 (13:32 -0600)]
patman: Remove the test suite
These tests cover the patch-management functionality, which is being
removed from the tree in favour of the standalone patch-manager package.
Drop the tests and their data files.
Simon Glass [Sun, 5 Jul 2026 19:32:15 +0000 (13:32 -0600)]
patman: Replace the tool with a stub for patch-manager
patman is now maintained as a standalone 'patch-manager' package, rather
than in the U-Boot tree. Replace the command with a small stub which
tells people how to install it.
buildman still uses the shared modules commit and patchstream (and their
dependencies), so leave those in place; the patches that follow remove
the patch-management code itself.
Simon Glass [Sun, 5 Jul 2026 19:32:14 +0000 (13:32 -0600)]
patman: Add a .patman-defaults file for U-Boot
patman is now installed from the separate patch-manager package. It reads
a .patman-defaults file from the tree root as its lowest-priority config,
so a project can ship defaults that developers still override from their
own ~/.patman, a local .patman or the command line. This behaviour is new
in patman version 0.0.20
Add one for U-Boot, alongside .b4-config, pinning the patchwork server and
the get_maintainer.pl invocation so the tool works out of the box without
depending on patman's built-in defaults. A few other settings are listed,
commented out, as a starting point.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Sun, 5 Jul 2026 19:32:22 +0000 (13:32 -0600)]
test: Stop running the patman tests
The patman tests no longer exist in the tree, so drop them from the
test/run script (used by 'make tcheck' and friends) and from the
tools-testing example in the documentation.
Simon Glass [Sun, 5 Jul 2026 19:32:21 +0000 (13:32 -0600)]
tools: Stop packaging patman as a pip module
patman is no longer shipped from the U-Boot tree, so drop it from the
'make pip' target and from make_pip.sh, and remove its packaging files
(setup.py, pyproject.toml, requirements.txt). Nothing else refers to
them by this point in the series, so they can go.
Also fix binman's pyproject.toml, which declares package-data for a
'patman' package (a copy-paste leftover); use 'binman' instead.
Simon Glass [Sun, 5 Jul 2026 19:32:20 +0000 (13:32 -0600)]
tools: docker: Drop patman from the CI image
The CI runner image pre-caches pip packages by downloading each tool's
requirements.txt from master. A later patch removes patman's
requirements.txt from the tree, so stop fetching and installing it.
The same step already installs setuptools explicitly (patman's
requirements list it too), so this needs nothing further.
This takes effect the next time someone rebuilds the image; the existing
image keeps working in the meantime.
Simon Glass [Sun, 5 Jul 2026 19:32:18 +0000 (13:32 -0600)]
CI: Install pylibfdt's requirements in the tool jobs
The GitLab and Azure tool-test and pylint jobs build the pylibfdt
bindings, which need setuptools. That currently comes only from patman's
requirements.txt, which a later patch drops. Install
scripts/dtc/pylibfdt/requirements.txt in those jobs, the proper source
for that dependency, so setuptools survives patman's removal.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Simon Glass [Sun, 5 Jul 2026 19:32:13 +0000 (13:32 -0600)]
doc: Remove the patman documentation
The full patman manual now lives with the standalone patch-manager
package, making the 1000-line copy in the tree redundant.
Remove the in-tree manual, its README and the doc/develop/patman.rst
toctree page.
The sending-patches guide already introduces patman, so point it at the
patch-manager package instead of the now-dead ':doc:' cross-reference
and, with the manual gone, add a couple of lines on how the tool works.
Point the SPI howto at that guide too, rather than repeating the install
details.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Simon Glass [Sun, 5 Jul 2026 19:32:12 +0000 (13:32 -0600)]
doc: Move the b4 guide into sending_patches
The b4 contributor guide sits in the coding-style document, which is an
odd place for it. Move it into sending_patches.rst, next to the patman
note, so both patch-sending tools are described together.
The b4_contrib label moves with it, so the reference from process.rst
still resolves.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Tanmay Kathpalia [Mon, 29 Jun 2026 06:16:15 +0000 (23:16 -0700)]
Revert "mmc: sdhci-cadence: trigger tuning for SD HS mode on SD6HC (v6) PHY"
This reverts commit b42c67188c14 ("mmc: sdhci-cadence: trigger tuning
for SD HS mode on SD6HC (v6) PHY").
The reverted patch introduced several issues:
1. Non-standard tuning trigger: The SD Physical Layer Specification
only mandates execute_tuning for SDR50 and SDR104 UHS-I modes.
Triggering tuning for SD High Speed mode is outside the spec and
is handled via a non-standard set_ios_post callback rather than
through the established SDHCI framework tuning path.
2. Non-standard device tree property: The patch introduced a new
"cdns,sd-hs-tuning" DT property to opt into SD HS tuning. This
is not aligned with existing DT bindings and bypasses the standard
MMC capability negotiation mechanism.
3. Incorrect tunable mode allowlist: The sdhci_cdns6_mode_is_tuned()
function includes SD_HS, UHS_SDR50, and MMC_HS_400_ES as tunable
modes. According to the Cadence SD6HC IP User Guide (section 7.5.2,
Figure 18), tuning is only required for UHS-I SDR104 (SD) and
HS200 (eMMC). SD High Speed, UHS-I SDR50, and DDR50 only require
a PHY settings update from the pre-calculation script, not the
tuning procedure. HS400 transitions through HS200 and reuses its
tuned DLL value with a partial settings update. HS400ES only
requires a plain settings update from the calculation script with
no dependency on HS200 tuning.
4. Tuned state management outside the framework: The patch manually
tracks tuned DLL state (tuned_mode, tuned_dll_slave_ctrl) and
restores it across PHY reconfigurations. This duplicates
responsibility that belongs in the core MMC tuning framework and
adds unnecessary complexity to the driver.
Reverting to realign the driver with the IP documentation and the SD
Physical Layer Specification.
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tanmay Kathpalia [Thu, 14 May 2026 18:54:11 +0000 (11:54 -0700)]
mmc: sd: fix redundant 1.8V voltage switch on cold boot with UHS card
When a UHS card successfully negotiates 1.8V signaling during normal
initialization, the host voltage switch is performed as part of the
ACMD41 handshake. Without this fix, the warm-reboot recovery path
would fire again immediately after, switching the host voltage a
second time unnecessarily.
Add a check so the recovery path is only entered when the voltage
switch was not already performed during the current initialization
session.
Fixes: 906ee6785b1c ("mmc: sd: Handle UHS-I voltage signaling without power cycle") Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Neil Armstrong [Thu, 25 Jun 2026 15:36:15 +0000 (17:36 +0200)]
treewide: change email links from mailman to patch.msgid.link with message-id
In preparation of the migration of the mailman mailing-list currently
hosted on the denx.de infrastructure, migrate the links in the code,
comments and documentation to https://patch.msgid.link to be future proof
and always link to the expected content data and uses the message-id in
the URL which will help find the appropriate e-mail in the future.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
Michal Simek [Mon, 29 Jun 2026 15:44:01 +0000 (17:44 +0200)]
.mailmap: Run mailmapper and sync name locations
The patch is output from
scripts/mailmapper > tmp; mv tmp .mailmap
with moving <swarren@wwwdotorg.org> and <swarren@wwwdotorg.org> to the same
block with "This contributor prefers not to receive mails" description.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Michal Simek [Mon, 29 Jun 2026 15:44:00 +0000 (17:44 +0200)]
.mailmap: update e-mail address for Abbarapu Venkatesh Yadav
Name and email address has changed but format wasn't correct. Keep origin
line which is doing conversion from xilinx.com to amd.com and then have
conversion from AMD to Qualcomm. Also move name to proper location.
Fixes: f21920f7e795 (".mailmap: update e-mail address for Abbarapu Venkatesh Yadav") Signed-off-by: Michal Simek <michal.simek@amd.com>
.mailmap: map old addresses to their up-to-date counterparts
This essentially maps @free-electrons.com to @bootlin.com addresses.
Signed-off-by: João Marcos Costa <joaomarcos.costa@bootlin.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
drivers: sysreset: revert support for args in request
This reverts:
- commit e49c84f7bb7b ("doc: usage: cmd: reset: specify when the -edl
option is available")
- commit 1076feb8a3f9 ("cmd: boot: fix edl being shown when not
supported")
- commit 63c806ba0e12 ("qcom_defconfig: enable psci based sysreset")
- commit ef06c5d76ff4 ("cmd: boot: Add '-edl' option to reset command
documentation")
- commit 32825eaddc37 ("sysreset: Implement PSCI based reset to EDL mode
for QCOM SoCs")
- commit fcb48b89813b ("drivers: sysreset: Add sysreset op that can take
arguments")
There was a conflict reverting commit 63c806ba0e12 ("qcom_defconfig:
enable psci based sysreset") due to commit 02ef1859b44f ("configs:
Resync with savedefconfig"), but the conflict resolution was trivial.
The args support for the sysreset uclass contains a logic bug. The first
sysreset device implementing the request_arg callback will consume the
args, not support the specified arg and thus return -EPROTONOSUPPORT
which will stop the iteration over all sysreset devices.
This is an issue if one has multiple sysreset devices and each with
support for different (valid) args. If a sysreset device implements a
-dummy argument and another -foo and a user calls reset -dummy from the
U-Boot CLI, it'll depend on which sysreset device will be attempted
first. If it is the one implementing -foo, it'll return it doesn't
support the argument with -EPROTONOSUPPORT in which case the device
implementing -dummy will never be attempted and instead we'll do a cold
reset which is very likely not what's expected from the user.
Casey suggested[1] we revert this and start from scratch again with a
different implementation instead.
A last minute fix for the release, the UFS controller on the new Milos
SoC (used in the Fairphone Gen. 6) needs a stub driver for it's ref
clock (similar to SM8650 before) and a handful of other clocks to get
the UFS controller probed.
Ye Li [Fri, 26 Jun 2026 10:44:49 +0000 (18:44 +0800)]
clk: imx: imx8mq: Fix iMX8MQ PLL issue
The fractional PLL used on iMX8MQ is not pll14xx, it is different
PLL and not exist in u-boot. Add this fractional PLL driver and
update iMX8MQ clock driver to adapt this fraction PLL.
Fixes: 11c8ab01f3ed ("clk: imx8mq: Add a clock driver for the imx8mq") Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Ye Li [Thu, 18 Jun 2026 01:17:47 +0000 (09:17 +0800)]
imx9: scmi: Fix SPL trampoline buffer for 1GB DDR
After supporting get DRAM size from SM, the trampoline buffer address
still depends on PHYS_SDRAM_SIZE. If the real DDR size is less than
PHYS_SDRAM_SIZE, the trampoline buffer address is invalid and SPL will
crash. So use board_phys_sdram_size to get real DDR size to calculate
correct address.
Fixes: e1cc7117b630 ("imx9: scmi: Get DDR size through SM SCMI API") Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Tested-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Alexey Charkov [Tue, 12 May 2026 13:55:28 +0000 (17:55 +0400)]
usb: onboard-hub: Add support for Corechips SL6341 USB 2.0/3.0 hub controller
Corechips SL6341 is a 4-port USB 2.0 and 3.0 hub controller. It always
requires external 1V1 power and can optionally use external 3V3 power
(or alternatively it has a 5V->3V3 LDO built in to derive 3V3 power from
VBUS). It also exposes a reset pin.
Device tree bindings are merged for upstream release with Linux 7.1 as
commit bfcb86e58f3a ("dt-bindings: usb: Add Corechips SL6341 USB2.0/3.0
hub controller") [1]
Use board_get_usable_ram_top() instead of get_effective_memsize() to
limit gd->ram_top.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit b9e6281632a8 ("arm: mediatek: mt8512:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation.
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. Overriding gd->bd->bi_dram[0].size was a bit
confusing since it isn't easily apparent which order the functions that
set it are called.
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit d83bd9729d75 ("arm: mediatek: mt8195:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of get_effective_memsize() being overridden in commit af4cba9a05aa ("arm: mediatek: mt8195: fix gd->ram_top limit")
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit b3467e51e92b ("arm: mediatek: mt8188:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of get_effective_memsize() being overridden in commit 7518e10cd235 ("arm: mediatek: mt8188: fix gd->ram_top limit").
We can just use board_get_usable_ram_top() now to set gd->ram_top to the
correct value instead. This is possible now, thanks to
LMB_LIMIT_DMA_BELOW_RAM_TOP being set by default for 64-bit Mediatek
ARM SoCs.
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit bddd6bbef3dc ("arm: mediatek: mt7988:
drop dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of CFG_MAX_MEM_MAPPED.
Rather than continue to use an old-style CFG_ option and the potentially
confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see
which order the functions that set it are called), we can just use
board_get_usable_ram_top() to set gd->ram_top to the correct value
instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP
being set by default for 64-bit Mediatek ARM SoCs.
The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed.
The config header and Kconfig option are also removed since that was
the last CFG_ option.
Reported-by: Rudy Andram <rmandrad@gmail.com> Closes: https://lore.kernel.org/u-boot/20260602162233.2418471-1-rmandrad@gmail.com/ Fixes: bddd6bbef3dc ("arm: mediatek: mt7988: drop dram_init_banksize()") Link: https://patch.msgid.link/20260615-mtk-fix-ram-size-v2-4-f72cfc52ce58@baylibre.com Signed-off-by: David Lechner <dlechner@baylibre.com>
Use board_get_usable_ram_top() instead of get_effective_memsize() to
set gd->ram_top to something <= 4GiB.
Both board_get_usable_ram_top() and get_effective_memsize() are used to
set gd->ram_top in setup_dest_addr(). However, get_effective_memsize()
also sets gd->bd->bi_dram[0].size in dram_init_banksize(), which is
undesirable.
Prior to commit 56183fb025c2 ("arm: mediatek: mt7987: drop
dram_init_banksize()"), gd->bd->bi_dram[0].size was overridden in
a board-specific dram_init_banksize() implementation. When that was
removed get_effective_memsize() set gd->bd->bi_dram[0].size to the wrong
value because of CFG_MAX_MEM_MAPPED.
Rather than continue to use an old-style CFG_ option and the potentially
confusing overriding of gd->bd->bi_dram[0].size (it is difficult to see
which order the functions that set it are called), we can just use
board_get_usable_ram_top() to set gd->ram_top to the correct value
instead. This is possible now, thanks to LMB_LIMIT_DMA_BELOW_RAM_TOP
being set by default for 64-bit Mediatek ARM SoCs.
On mt7987, there is already an implementation of
board_get_usable_ram_top() for other reasons, so it is modified to
also limit ram_top to 4GiB (mt7987 is currently the only thing that
sets CONFIG_MTK_TZ_MOVABLE=y so it is safe to change this here without
unintentional side-effects).
The CFG_MAX_MEM_MAPPED option is removed since it is no longer needed.
The config header and Kconfig option are also removed since that was
the last CFG_ option.
David Lechner [Mon, 15 Jun 2026 19:23:32 +0000 (14:23 -0500)]
net: mtk_eth: select LMB_LIMIT_DMA_BELOW_RAM_TOP
Default to CONFIG_LMB_LIMIT_DMA_BELOW_RAM_TOP=y when MEDIATEK_ETH is
enabled. The MediaTek Ethernet controller can only access the first 4GB
of RAM when DMA is used.
David Lechner [Mon, 15 Jun 2026 19:23:31 +0000 (14:23 -0500)]
mmc: mtk-sd: select LMB_LIMIT_DMA_BELOW_RAM_TOP
Default to CONFIG_LMB_LIMIT_DMA_BELOW_RAM_TOP=y when CONFIG_MTK_SD is
enabled. The MediaTek SD controller can only access the first 4GB of RAM
when DMA is used. "imply" is used rather than "select" in case someone
want's to turn off the option when DMA is not used.
David Lechner [Fri, 12 Jun 2026 00:12:20 +0000 (19:12 -0500)]
arm64: dts: mediatek: mt6359: give regulators unique names
Change the regulator-name properties to be unique for all regulators.
U-Boot cannot handle duplicate names.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
[ upstream commit: d91639d0ab3223b61c00442021dc639c9ddc2b76 ]
For AST2600 SPL with CONFIG_SPL_SEPARATE_BSS=y and
CONFIG_OF_SEPARATE=y, fdt_find_separate() expects the appended control
DTB at _image_binary_end.
The AST2600 SPL linker script aligned _image_binary_end via the
.binman_sym_table section. In builds where that section has no emitted
contents, objcopy -O binary does not include the alignment bytes in
spl/u-boot-spl-nodtb.bin. This causes the nodtb binary to end before
_image_binary_end, so the appended DTB is placed too early.
Piyush Paliwal [Fri, 12 Jun 2026 07:47:30 +0000 (13:17 +0530)]
net: cdp: reject CDP TLVs with a length below the 4-byte header
cdp_receive() reads a 16-bit TLV length (tlen) from the packet and only
checks that it does not exceed the remaining buffer (tlen > len). It then
unconditionally does "tlen -= 4" to skip the TLV header. As tlen is a
u16, a crafted TLV with a length of 0..3 underflows tlen to ~65532-65535.
For a CDP_APPLIANCE_VLAN_TLV the underflowed length then drives the inner
"while (tlen > 0)" loop, which walks ~64KB past the receive buffer reading
*ss each step -> out-of-bounds read (crash / info-influence). A length of
0 additionally fails to advance pkt/len, hanging the parse loop.
Reject any TLV whose declared length is smaller than its own 4-byte
header. This is the same class of bug as the recent bootp/dhcpv6/sntp/nfs
fixes (unchecked length field), in a sibling LAN parser that was missed.
Verified with a standalone AddressSanitizer harness using the verbatim
cdp_receive()/cdp_compute_csum() routines: a 16-byte CDP frame with an
appliance-VLAN TLV of length 3 triggers a heap-buffer-overflow READ that
the check eliminates.
Fixes: f575ae1f7d39 ("net: Move CDP out of net.c") Cc: stable@vger.kernel.org Signed-off-by: Piyush Paliwal <piyushthepal@gmail.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
David Lechner [Thu, 11 Jun 2026 23:36:10 +0000 (18:36 -0500)]
net: lwip: introduce net_lwip_eth_stop() function
Add a introduce net_lwip_eth_stop() function and use that to stop the
network interface after each command that uses the network.
This makes the behavior the same as the legacy net code and avoids
potential issues with the network interface being left in an active
state after a command finishes.
The start/stop is reference-counted since there is at least one command
(dhcp) that calls another command (tftp) to avoid starting and stopping
the network interface multiple times in a single command.
Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>
David Lechner [Thu, 11 Jun 2026 23:36:09 +0000 (18:36 -0500)]
net: lwip: wget: return errno codes from wget_do_request()
Change the return values of the lwip implementation of wget_do_request()
to be errno codes instead of command return codes.
wget_do_request() is not a command, so it does not make sense to return
command return codes from it. Also, the legacy network implementation of
wget_do_request() already returns errno codes so it is logical for the
lwip implementation to do the same.
This fixes a bug in try_load_from_uri_path() in efi_manager.c where it
checks that the return value of wget_do_request() is < 0. Before this
change, CMD_RET_FAILURE would not be considered an error since it has a
value of 1.
The value of ENODEV is used in places where there could actually be a
number of different causes of failure and it isn't possible to
discriminate (i.e. failing function returns NULL for all errors). Since
all callers of wget_do_request() don't propagate the error code, it
doesn't matter so much that this is not ideal, at least at this point in
time.
David Lechner [Thu, 11 Jun 2026 23:36:08 +0000 (18:36 -0500)]
net: lwip: wget: fix error handling in wget_do_request()
Split wget_do_request() into two functions to make error handling less
error-prone.
After a successful call to net_lwip_new_netif(), net_lwip_remove_netif()
must always be called to prevent leaks. This was missed in the CACERT
section of the code where we returned on error without cleaning up.
Instead of adding more calls to net_lwip_remove_netif(), refactor the
code into two functions. The outer function handles managing the netif
lifecycle. The inner function no longer has to worry about cleaning up
before returning on error.
To keep things simple, the `path` local variable is removed during the
refactoring. Instead, ctx.path is used directly everywhere.
Mateusz Furdyna [Wed, 10 Jun 2026 14:25:34 +0000 (16:25 +0200)]
test: net: add IP defragmentation duplicate-fragment regression test
Add a unit test for the IP datagram reassembler (CONFIG_IP_DEFRAG) that
covers the duplicate-last-fragment scenario.
Without the fix the last fragment will re-trigger datagram delivery,
increasing udp_rx_count to 2 and effectively failing the test; with it
applied the test passes with udp_rx_count == 1.
Signed-off-by: Mateusz Furdyna <mateusz.furdyna@nokia.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Mateusz Furdyna [Wed, 10 Jun 2026 14:25:33 +0000 (16:25 +0200)]
net: clear IP defragmentation state after returning a complete packet
During the IP defragmentation process, after the reassembly is finished
with the last packet arriving with MF=0, the reassembly state wrt.
static counters is not cleared. In case this last arriving packet with
MF=0 gets duplicated, payload bytes are mistakenly treated as hole data.
A malicious actor who can deliver fragmented IP traffic to a U-Boot
instance with CONFIG_IP_DEFRAG=y can corrupt memory via out-of-bound
writes and redirect control flow into attacker-supplied payload bytes
that already sit in `pkt_buff[]`.
Publicly available AI models are able to generate a reproducer based
on the provided information.
Fix: once the assembled packet has been handed back to the caller, mark
the reassembly state empty so that any further fragment (duplicate,
replay, or a brand-new datagram that happens to reuse the `ip_id`) goes
through the normal re-init path and rebuilds a clean hole list instead
of dereferencing payload bytes as struct hole.
net: airoha_eth: fix mt7531 mdio related initialization bug
Private data isn't ready during bind time. The call of dev_get_priv()
function will return NULL. Thus we can't save mdio device pointer and
use it later during probe.
To solve an issue, we will move mt7531 mdio device binding to the probing
function of 'airoha-eth' driver.
All GDM ports (except of GDM1) are connected directly to their PHYs, so
corresponding mdio bus will be automatically probed during PHY setup.
GDM1 ports differ from other GDM ports. It connected to the airoha switch
device. The mt7531 mdio bus is used to manage link state of airoha switch
device ports (LAN ports 1-4 corresponds to PHYs 0x09-0x0C). Therefore,
manual probing of mt7531 mdio bus is required to be able set/query states
of corresponding LAN ports.
Fixes: 96d9e7c46425 ("net: airoha: use mt7531 mdio for GDM1") Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
* bootdev: fix typos
* board: renesas: Document Renesas RZ/N1D and RZ/N1S as arm
* board: renesas: Document Renesas Geist board support
* board: renesas: Document Renesas Gray Hawk board support
* board: renesas: Document Renesas Ironhide board support
* android: fastboot: Document halt behaviour
UEFI:
* fix memory leak in efi_var_collect()
* set revision field in block IO protocol
* fix guid comparison in efi_selftest_loaded_image.c
* fix use-after-free in efi_selftest_memory.c
Vincent Stehlé [Thu, 11 Jun 2026 06:59:50 +0000 (08:59 +0200)]
efi_selftest: fix use-after-free
When the `memory' efi selftest verifies the Devicetree memory reservation,
it accesses the memory_map buffer after it has been freed with free_pool().
Move the verification earlier to fix this.
Fixes: 34c96659ed57 ("efi_selftest: check fdt is marked as runtime data") Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Vincent Stehlé [Tue, 9 Jun 2026 08:07:04 +0000 (10:07 +0200)]
lib/efi_loader: fix block io revision
The Revision field of the EFI_BLOCK_IO_PROTOCOL structure must be set to
one of the two valid values [1], but this is not initialized in the
efi_loader; fix it.
Link: https://uefi.org/specs/UEFI/2.11/13_Protocols_Media_Access.html#efi-block-io-protocol Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Vincent Stehlé [Mon, 15 Jun 2026 10:56:15 +0000 (12:56 +0200)]
efi_selftest: fix guid comparison
The `loaded image' efi selftest is comparing protocol GUIDs with the wrong
polarity.
This can be verified on the sandbox, where two protocols GUIDs are
retrieved by the test from the image handle in the following order:
The test matches on the first GUID, while it is in fact looking for the
second one; fix the comparison polarity.
Fixes: efe79a7c0de0 ("efi_selftest: test for loaded image protocol") Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Cc: Alexander Graf <agraf@csgraf.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Peng Fan [Thu, 18 Jun 2026 06:48:48 +0000 (14:48 +0800)]
usb: tcpm: fix inverted poll condition in tcpm_pd_transmit()
The read_poll_timeout() macro breaks out of its loop when the condition
evaluates to true. The current code uses "!tx_complete" as the
condition, which means it exits immediately when tx_complete is false
(i.e., transmission has NOT completed yet), rather than waiting for
completion.
Fix the condition to "tx_complete" so that the poll loop waits until
the TCPC signals transmission success/failure/discard before
proceeding.
Without this fix, tcpm_pd_transmit() returns before the TCPC has
finished transmitting, causing the PD state machine to proceed with
stale tx_status values.
Fixes: 1db4c0ac77e3 ("usb: tcpm: add core framework") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tom Rini [Tue, 16 Jun 2026 23:01:20 +0000 (17:01 -0600)]
Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh
This is a DRAM controller driver for the R-Car X5H and its enablement.
This makes the U-Boot on RSIP usable beyond U-Boot shell running on
Cortex-M33, as the U-Boot on RSIP can now load not only SCP firmware
into the SCP core STCM, but also TFA BL31, OPTEE-OS and U-Boot into DRAM
and start them on the Cortex-A720AE core. This is self-contained and
affects only the R-Car X5H and a bit of R-Car V4H, besides it went
through rounds of testing until now, therefore it is safe to include it
this late in the release cycle. I know this will make rc5 massive, sorry
about that.
Rasmus Villemoes [Thu, 11 Jun 2026 14:08:57 +0000 (16:08 +0200)]
Makefile: let 'make clean' remove files created by DEVICE_TREE_DEBUG
Originally, 'make DEVICE_TREE_DEBUG=1' only generated extra output on
the console. But since 6cdd7597a2f ("kbuild: Produce diff between base
DT and U-Boot augmented DT if DEVICE_TREE_DEBUG=1"), that has also
left behind lots of files that clutter the repo and are hard to get
rid of manually.
Make sure that a 'make clean' will remove those files, and add them to
.gitignore.
Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Wed, 10 Jun 2026 18:20:59 +0000 (20:20 +0200)]
arm: dts: renesas: Enable DBSC5 on R-Car R8A78000 X5H Cortex-M33 RSIP port
Bind the DBSC5 DRAM controller driver on boot in board_early_init_r(),
which brings up the DBSC5 DRAM controller and its PHY and which enables
access to DRAM present on this system.
Add default boot command which loads additional bootloader components
from HF and UFS storage into SRAM and DRAM, and starts those components
on SCP and AP core 0. The system is then capable of reaching U-Boot on
the AP core 0. Specifically, the following components are loaded:
- SCP firmware, 384 kiB from HF offset 0x4c0000 to SCP STCM
- TFA BL31, 256 kiB from UFS0 offset 0x5000 * 4 kiB sectors to DRAM 0x8c200000
- TEE, 2 MiB from UFS0 offset 0x5200 * 4 kiB sectors to DRAM 0x8c400000
- U-Boot, 1 MiB from UFS0 offset 0x7200 * 4 kiB sectors to DRAM 0x8c300000
- IPL parameters table is generated at DRAM address 0x8c100000
Enable pstore command support to allow dumping kernel console from
pstore/ramoops, which is convenient for debugging. Use as follows:
=> pstore set 0x80000000 0x10000 0x400 0x8000 0 0 0
=> pstore display console
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add Renesas R-Car Gen5 DBSC5 DRAM controller driver. This driver is currently
capable of bringing LPDDR5X DRAM on Renesas R-Car X5H Ironhide board. Further
boards can be supported by supplying board specific DRAM configuration data
via dbsc5_get_board_data().
The driver reuses parts of previous DBSC5 driver, but due to hardware changes,
can not be fully integrated into existing DBSC and DRAM driver, therefore the
currentl DBSC and DRAM drivers are moved into R8A779G0 V4H specific files, and
the R8A78000 X5H files are added in parallel.
The Gen5 DBSC driver is meant to be used in RSIP context, while the Gen4 DBSC
driver is meant to be used in SPL, therefore the Kconfig conditionals have been
adjusted to match.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Wed, 10 Jun 2026 18:20:57 +0000 (20:20 +0200)]
ram: renesas: rtvram: Add support for Renesas R-Car Gen5
Add support for Renesas R-Car Gen5 R8A78000 SoC into RT-VRAM
initialization driver. The changes are only a slight adjustment
to the register programming, therefore reuse the existing RT-VRAM
driver and parametrize those changes using driver data.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Heiko Stuebner [Sat, 13 Jun 2026 17:24:44 +0000 (19:24 +0200)]
lmb: Add the Rockchip architecture as requiring DMA below 4G
Loading EFI parts like a Debian-Installer on Rockchip SoCs creates
interesting results, in that on some boards the Grub bootloader can't
find any partitions on a USB-Stick, or loading a kernel from Grub spews
EHCI fail timeout STS_IAA set
messages before failing and on others the loading something like efivars
from an eMMC creates read errors and making the MMC vanish from U-Boot.
This only affected boards with at least 4GB of RAM.
These boards have at least 256MB of memory placed above the actual 4GB
address space (due to the iomem being in between) and while kernel,
initramfs, dt are generally loaded to predefined addresses, additional
EFI parts (efivars, etc) are likely just loaded "somewhere" and it seems
this always landed in that higher up memory part.
Also in the Linux-kernel peripherals like EMMC, USB, etc already run
with a 32bit dma-mask set.
So far, I've seen this on RK3568 and RK3588, but as the same peripherals
are used on most Rockchip SoCs, it makes sense to limit this on all.
So add ARCH_ROCKCHIP to the default-y list of LMB_LIMIT_DMA_BELOW_RAM_TOP.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Tom Rini [Mon, 15 Jun 2026 18:50:04 +0000 (12:50 -0600)]
Merge patch series "Repair boards broken by the 6.1 kbuild bump"
Simon Glass <sjg@chromium.org> says:
Commit bd3f9ee679b4 added FORCE to several if_changed rules whose
recipes expand $^, so FORCE leaks in as a stray argument and the
command fails. Use $< to restore the Edison and i.MX23/28 images.
Simon Glass [Sat, 13 Jun 2026 13:05:13 +0000 (07:05 -0600)]
arm: mxs: Avoid passing FORCE to commands
Commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") adds FORCE
as a prerequisite to the if_changed rules here, but the commands use $^
so FORCE leaks in as a stray operand. The dd in cmd_mkalign_mxs fails
(silently, since its stderr is discarded) and the binary is never
aligned, stat in cmd_mkivt_mxs emits an error and cst receives a bogus
argument.
Use $< and $(real-prereqs) instead, which exclude FORCE.
Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Sat, 13 Jun 2026 13:05:12 +0000 (07:05 -0600)]
x86: edison: Avoid passing FORCE to the align command
Commit bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") adds FORCE
as a prerequisite to the u-boot-align.bin rule, but cmd_mkalign_eds
expands $^, so FORCE leaks in as a stray operand. The dd then fails
(silently, since its stderr is discarded) and the following mv never
runs, so u-boot.bin never gains its 4096-byte zero prefix. The mask ROM
enters U-Boot 0x1000 (4KB) into the image and the board never starts,
sitting in BootROM download mode (DnX).
Use $< instead of $^, which excludes FORCE and restores the prefix.
Fixes: bd3f9ee679b4 ("kbuild: Bump the build system to 6.1") Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The boot selection rules state that a slot is bootable if it is not
corrupted and either has tries remaining or has already booted
successfully. However, slots that have tries_remaining == 0 and
successful_boot == 1 will be disregarded when picking the slot to
attempt.
Updates the selection logic so slots marked successful remain eligible
even when their tries counter is zero. Debug message now also includes
the successful_boot value.
Francois Berder [Sun, 24 May 2026 19:25:47 +0000 (21:25 +0200)]
fastboot: Fix blk_dwrite error checking
blk_dwrite() returns the number of blocks written.
The code was only checking if the return value was different
than 0. Hence, partial writes were considered successful.
Fix blk_dwrite error handling by checking that all blocks
are written.
Marek Vasut [Sun, 14 Jun 2026 01:52:21 +0000 (03:52 +0200)]
arm64: renesas: Initialize GIC600 fully on R-Car S4/V4H/V4M
ARM GIC-600 IP complies with ARM GICv3 architecture, but among others,
implements a power control register in the Redistributor frame. This
register must be programmed to mark the frame as powered on, before
accessing other registers in the frame.
Before the switch to generic lowlevel_init function, this did not pose
a problem as the previous custom lowlevel_init did not access the GICR
registers. The generic function does and that does lead to a hang early
in SPL. Enable the GIC600 initialization variant to mitigate the hang.
Fixes: 37997a214ed1 ("arm: renesas: Use stock lowlevel_init function and remove s_init") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Sun, 14 Jun 2026 01:52:08 +0000 (03:52 +0200)]
arm64: renesas: Fold mach_cpu_init into board_init_f on R-Car S4/V4H/V4M SPL
The mach_cpu_init() function is not invoked in SPL. Instead of
having two functions, fold mach_cpu_init() into board_init_f(),
which is called very early in the boot process and assures that
the CPG and APMU setup will be invoked before DM is brought up.
Fixes: 37997a214ed1 ("arm: renesas: Use stock lowlevel_init function and remove s_init") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Thu, 11 Jun 2026 18:05:58 +0000 (20:05 +0200)]
arm: renesas: Make R-Car Gen5 u-boot-elf.shdr compatible with SDK flash_writer
The SDK 4.32 flash_writer tool, built from the SDK IPL source, requires
SREC S7 "Start address (termination)" record [1] at the end of the SREC
file that is sent to it during installation of content into storage,
otherwise the tool waits for the S7 record indefinitelly and the payload
does not get installed into storage.
Specifically, the tool considers SREC S3 and S7 records as mandatory,
S0, S5, S6 as ignored, and any other records as unsupported.
Configure srec_cat such that it explicitly generates the trailing S7
record, and also that it never generates the ignored S5 Count record.
This fixes installation of u-boot-elf.shdr using the flash_writer tool,
which can not finish successfully without the trailing S7 record.
Marek Vasut [Thu, 11 Jun 2026 18:04:26 +0000 (20:04 +0200)]
arm: renesas: Build u-boot-elf.shdr for R-Car X5H Cortex-M33 RSIP port
Currently, the default build target for all R-Car Gen3/4/5 is the
u-boot-elf.srec, which depends on u-boot.bin and other vital build
artifacts, which get built as prerequisites. The R-Car Gen5 RSIP
port benefits from u-boot-elf.shdr being built as well, because the
u-boot-elf.shdr contains header used by the BootROM to load and
start U-Boot on the RSIP core. Because u-boot-elf.shdr depends on
u-boot-elf.srec, switch the default build target for R-Car Gen5
RSIP port to u-boot-elf.shdr. This way, both u-boot-elf.shdr and
u-boot-elf.srec are built for R-Car Gen5 RSIP port.
Tom Rini [Fri, 12 Jun 2026 14:45:32 +0000 (08:45 -0600)]
Merge patch series "configs: imx95: enable PCI_INIT_R for Toradex modules"
Franz Schnyder <fra.schnyder@gmail.com> says:
Currently, on the Toradex SMARC iMX95 and the Verdin iMX95 the ENETC
device is not enumerated before network initialization because
pci_init() is not called. As a result, no Ethernet device is registered.
Enable CONFIG_PCI_INIT_R so the PCI buses are enumerated early enough
for the Ethernet Controller to be detected and used.
Franz Schnyder [Fri, 12 Jun 2026 08:59:01 +0000 (10:59 +0200)]
configs: verdin-imx95: enable PCI_INIT_R
Currently, the ENETC device on iMX95 is not enumerated before network
initialization because pci_init() is not called. As a result, no
Ethernet device is registered.
Enable CONFIG_PCI_INIT_R so the PCI buses are enumerated early enough
for the Ethernet Controller to be detected and used.
Fixes: 60d8255d8dc0 ("board: toradex: add Toradex Verdin iMX95") Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Franz Schnyder [Fri, 12 Jun 2026 08:59:00 +0000 (10:59 +0200)]
configs: toradex-smarc-imx95: enable PCI_INIT_R
Currently, the ENETC device on iMX95 is not enumerated before network
initialization because pci_init() is not called. As a result, no
Ethernet device is registered.
Enable CONFIG_PCI_INIT_R so the PCI buses are enumerated early enough
for the Ethernet Controller to be detected and used.
Fixes: ff0540fcfe49 ("board: toradex: add Toradex SMARC iMX95") Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Please pull the updates for rockchip platform:
- New Board support: rk3588 FriendlyElec NanoPi R76S
- UFS boot from SPL for rk3576 (NanoPi M5, ROCK 4D)
- Clock support for RK3576 GMAC 25MHz output and RK3528/RK3576 USB3 OTG
- Switch rk3128/rk3229 boards to upstream devicetree
- MAINTAINERS update for upstream devicetree references
- rk3588-rock-5b: Remove USB-C controller from u-boot.dtsi
- Define memory map for lemans-evk (pending SMEM)
- Fix CONFIG_SYS_INIT_SP_BSS_OFFSET in db410c chainloaded fragment
- Fix the "dump bootargs" command in the qcom-phone boot menu
- Fix a bug in the rpmh-regulator driver where the regulator mode may
not be set during enable.
- Enable watchdog autostart for Dragonwing boards
- Fix serial console init on ipq5424-rdp466
arm: dts: ipq5424-rdp466: add chosen node for serial console
Add a /chosen node with stdout-path pointing to serial0 (uart1) to
enable the DT-driven console discovery path in
serial_find_console_or_panic().
Without this node, the live DT path in serial_find_console_or_panic()
is skipped and the fallback path is used. Adding the /chosen node makes
the console selection explicit and deterministic, ensuring the correct
serial device is always selected as the console.
Petr Hodina [Fri, 5 Jun 2026 15:09:07 +0000 (17:09 +0200)]
gpio: qcom_spmi_gpio: move PM8998 GPIO from legacy pmic driver
Move the "qcom,pm8998-gpio" compatible from the legacy driver
qcom_pmic_gpio.c to qcom_spmi_gpio.c. Enables on PM8998-based boards
(sdm845: SHIFT 6mq, Pixel 3, OnePlus 6, Poco F1, Sony Xperia Akatsuki)
the Volume UP gpio-key.
projects / thirdparty / u-boot.git / log
