u-boot.git/cmd/Kconfig, branch main

pmbus: add PMBus 1.x framework, CLI, and binding

2026-07-13T01:16:57Z

Add U-Boot's PMBus 1.x layer: the decoder/transport library, the pmbus CLI command and a generic DT binding. The subsequent commits provide the UCLASS_REGULATOR adapter and per-chip drivers. U-Boot's PMBus support is not a hwmon clone of Linux's drivers/hwmon/pmbus/. Linux owns the runtime side (polling, sysfs, alert IRQs, fan loops). U-Boot owns the boot-time side in order to, - identify the PMBus regulators a board carries: MFR_ID/ MFR_MODEL/MFR_REVISION + sanity checks. - print telemetry (VIN/VOUT/IIN/IOUT/POUT/TEMP) so an operator can confirm rail voltages and faults before the kernel - decode any chip alerts (STATUS_VOUT/STATUS_IOUT/STATUS_INPUT/ STATUS_TEMPERATURE/STATUS_CML) so a boot log shows why the previous boot failed or the board had been power cycled because of an outage (typically over temperature or under current). Out of scope by design: no periodic polling, no sysfs, no fan-speed control loop, no PMBUS_VIRT_* sensor virtualisation, no caching. If a use case needs any of those, the answer should be "wait until Linux comes up". It shall remain a thin layer. The constants and structural shape (command codes, status bit names, sensor-class enum, format enum, struct pmbus_driver_info) are mirrored from Linux drivers/hwmon/pmbus/pmbus.h verbatim. The decoders/encoders are reimplemented from the PMBus 1.3 specification because the surrounding hwmon context (struct pmbus_data, sysfs caching, hwmon publication) does not apply. The main benefits: - One framework + CLI for any board carrying PMBus regulators: no per-board PMBus implementation required anymore. - Boards call pmbus_print_telemetry() / pmbus_print_status_word() directly from boot init for a snapshot, sharing all decode + format-dispatch with the CLI. - Linux-compatible constants and DT binding so porting an existing drivers/hwmon/pmbus/ chip is mechanical. - Boot-time AVS/VID rail trim reuses the same decoders and encoders as the CLI and the regulator path: no duplicate math. Signed-off-by: Vincent Jardin Signed-off-by: Peng Fan

treewide: Kconfig: use bool instead of tristate

2026-07-10T21:45:57Z

U-Boot does not support modules, so having tristate options is useless. Therefore this patch does a blind replace of all tristate options to bool tree-wide. Signed-off-by: Anshul Dalal Reviewed-by: Heiko Schocher Reviewed-by: Quentin Schulz Reviewed-by: Siddharth Vadapalli Reviewed-by: Neha Malcom Francis Reviewed-by: Romain Gantois Reviewed-by: Simon Glass

cmd: kconfig: i2c: add missing I2C API dependency

2026-07-09T05:18:18Z

CMD_I2C relies on either the Driver Model I2C API or the legacy I2C API, but its Kconfig currently does not enforce either dependency. As a result, enabling CMD_I2C without DM_I2C or SYS_I2C_LEGACY can lead to link errors due to unresolved i2c_* symbols. Require either DM_I2C or SYS_I2C_LEGACY to prevent unsupported configurations while preserving support for legacy platforms. Signed-off-by: Julien Stephan Reviewed-by: Tom Rini Reviewed-by: Heiko Schocher

cmd: fastboot: Add keyed abort option

2026-06-26T09:12:22Z

Works the same as CONFIG_CMD_UMS_ABORT_KEYED does: any keypress will abort fastboot mode (rather than only ctrl-c). Reviewed-by: Mattijs Korpershoek Tested-by: Mattijs Korpershoek Reviewed-by: Casey Connolly Signed-off-by: Sam Day Reviewed-by: Simon Glass Link: https://patch.msgid.link/20260619-fastboot-abort-keyed-v2-1-684e53949a42@samcday.com Signed-off-by: Mattijs Korpershoek

Kconfig: cmd: restyle

2026-06-25T20:13:34Z

Restyle all Kconfigs for "cmd": Menu entries : no space left Menu attributes: 1 TAB Help text : 1 TAB + 2 spaces Replace '---help---' by 'help' Signed-off-by: Johan Jonker

virtio: cmd: Depend on VIRTIO_BLK

2026-05-22T22:47:54Z

The virtio command is calling virtio blk functions but currently depends on CONFIG_VIRTIO only. This means disabling CONFIG_VIRTIO_BLK causes the final link to fail. Since CONFIG_VIRTIO_BLK depends on CONFIG_VIRTIO switch to depending on just CONFIG_VIRTIO_BLK Reviewed-by: Kuan-Wei Chiu Reviewed-by: Angelo Dureghello Reviewed-by: Tom Rini Reviewed-by: Simon Glass Signed-off-by: Daniel Palmer

Merge patch series "net: migrate NO_NET out of the networking stack choice"

2026-04-27T17:28:25Z

Quentin Schulz says: This migrates the net options away from the main Kconfig to net/Kconfig, rename the current NET option to NET_LEGACY to really highlight what it is and hopefully encourage more people to use lwIP, add a new NET menuconfig (but keep NO_NET as an alias to NET=n for now) which then allows us to replace all the "if legacy_stack || lwip_stack" checks with "if net_support" which is easier to read and maintain. The only doubt I have is wrt SYS_RX_ETH_BUFFER which seems to be needed for now even when no network is configured? Likely due to include/net-common.h with PKTBUFSRX? No change in behavior is intended. Only change in defconfig including other defconfigs where NO_NET=y or NET is not set, in which case NO_NET is not set or NET=y should be set in the top defconfig. Similar change required for config fragments. See commit log in patch adding NET menuconfig for details. This was tested based on 70fd0c3bb7c2 ("x86: there is no CONFIG_UBOOT_ROMSIZE_KB_12288"), from within the GitLab CI container trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026 and set up similarly as in "build all platforms in a single job" GitLab CI job. #!/usr/bin/env bash set -o pipefail set -eux ARGS="-BvelPEWM --reproducible-builds --step 0" ./tools/buildman/buildman -o ${O} --force-build $ARGS -CE $* ./tools/buildman/buildman -o ${O} $ARGS -Ssd $* O=../build/u-boot/ ../u-boot.sh -b master^..b4/net-kconfig |& tee ../log.txt I can't really decipher the log.txt, but there's no line starting with + which would be an error according to tools/buildman/builder.py help text. Additionally, because I started the script with set -e set and because buildman has an exit code != 0 when it fails to build a board, and I have the summary printed (which is the second buildman call), I believe it means all builds passed. The summary is the following: aarch64: (for 537/537 boards) all +0.0 rodata +0.0 uniphier_v8 : all +1 rodata +1 u-boot: add: 0/0, grow: 1/0 bytes: 1/0 (1) function old new delta data_gz 10640 10641 +1 arm: (for 733/733 boards) all -0.0 rodata -0.0 uniphier_v7 : all -1 rodata -1 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-1 (-1) function old new delta data_gz 11919 11918 -1 opos6uldev : all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 18778 18775 -3 uniphier_ld4_sld8: all -3 rodata -3 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-3 (-3) function old new delta data_gz 11276 11273 -3 stemmy : all -20 rodata -20 u-boot: add: 0/0, grow: 0/-1 bytes: 0/-20 (-20) function old new delta data_gz 15783 15763 -20 As far as I could tell this data_gz is an automatically generated array when CONFIG_CMD_CONFIG is enabled. It is the compressed .config stored in binary form. Because I'm changing the name of symbols, replacing a menu with a menuconfig, additional text makes it to .config and the "# Networking" section in .config disappears. Here is the diff for the 5 defconfigs listed above, generated with: for f in build/*-m; do diff --unified=0 $f/.config $(dirname $f)/$(basename -a -s '-m' $f)/.config done (-m is the build directory for master, and without the suffix, it's the top commit of this series) """ --- build/opos6uldev-m/.config 2026-04-20 10:53:49.804528526 +0200 +++ build/opos6uldev/.config 2026-04-20 11:03:37.430242767 +0200 @@ -970,4 +969,0 @@ - -# -# Networking -# @@ -975,0 +972 @@ +CONFIG_NET_LEGACY=y --- build/stemmy-m/.config 2026-04-20 11:01:33.653698123 +0200 +++ build/stemmy/.config 2026-04-20 11:04:53.452577311 +0200 @@ -733,4 +732,0 @@ - -# -# Networking -# @@ -738,2 +733,0 @@ -# CONFIG_NET is not set -# CONFIG_NET_LWIP is not set --- build/uniphier_ld4_sld8-m/.config 2026-04-20 11:00:41.605469071 +0200 +++ build/uniphier_ld4_sld8/.config 2026-04-20 11:04:22.226439899 +0200 @@ -997,4 +996,0 @@ - -# -# Networking -# @@ -1002,0 +999 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v7-m/.config 2026-04-20 10:53:04.019307319 +0200 +++ build/uniphier_v7/.config 2026-04-20 11:03:01.688085486 +0200 @@ -1004,4 +1003,0 @@ - -# -# Networking -# @@ -1009,0 +1006 @@ +CONFIG_NET_LEGACY=y --- build/uniphier_v8-m/.config 2026-04-20 10:43:05.614441175 +0200 +++ build/uniphier_v8/.config 2026-04-20 10:41:03.214852130 +0200 @@ -875,4 +874,0 @@ - -# -# Networking -# @@ -880,0 +877 @@ +CONFIG_NET_LEGACY=y """ This is fine: - Networking menu doesn't exist anymore so "#\n# Networking\n#\n" won't be in .config anymore. - opos6uldev, uniphier_ld4_sld8, uniphier_v7 and uniphier_v8 all have (old) CONFIG_NET enabled, (new) CONFIG_NET will still be set but CONFIG_NET_LEGACY also needs to be defined now to reflect the stack choice (even if default), - stemmy has CONFIG_NO_NET set, which means CONFIG_NET and CONFIG_NET_LWIP are not reachable anymore hence why they don't need to be part of .config, GitLab CI was run on this series (well, not exactly, but it's only changes to the git logs that were made): https://source.denx.de/u-boot/contributors/qschulz/u-boot/-/pipelines/29849 It passes. Link: https://lore.kernel.org/r/20260420-net-kconfig-v1-0-9900002d8e72@cherry.de

simplify NET_LEGACY || NET_LWIP condition with NET condition

2026-04-27T17:26:40Z

Since the move to make NET a menuconfig and NO_NET a synonym of NET=n, when NET is enabled, NET_LEGACY || NET_LWIP is necessarily true, so let's simplify the various checks across the codebase. SPL_NET_LWIP doesn't exist but SPL_NET_LEGACY is an alias for SPL_NET so the proper symbol is still defined in SPL whenever needed. Signed-off-by: Quentin Schulz Reviewed-by: Simon Glass Reviewed-by: Peter Robinson Reviewed-by: Tom Rini

rename NET to NET_LEGACY

2026-04-27T17:26:40Z

Highlight that NET really is the legacy networking stack by renaming the option to NET_LEGACY. This requires us to add an SPL_NET_LEGACY alias to SPL_NET as otherwise CONFIG_IS_ENABLED(NET_LEGACY) will not work for SPL. The "depends on !NET_LWIP" for SPL_NET clearly highlights that it is using the legacy networking app so this seems fine to do. This also has the benefit of removing potential confusion on NET being a specific networking stack instead of "any" network stack. Signed-off-by: Quentin Schulz Acked-by: Ilias Apalodimas Reviewed-by: Peter Robinson Reviewed-by: Tom Rini

cli: flush stdin before enabling cli

2026-04-22T20:23:49Z

Currently there is no possibility to flush stdin after autocommands are executed. If in the bootcmd the stdin is changed, e.g. from nulldev to serial, it could happen that junk characters sit in the fifo and appear on the cli. Add a option to clear stdin before starting the CLI. Signed-off-by: Gregor Herburger Reviewed-by: Simon Glass