From 29a7fe55c557e462457f4fb3dcb25681952b0803 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:06 +0100 Subject: [PATCH 01/11] cmd: led: fix help text for blink subcommand The blink subcommand actually requires an additional parameter (blink-freq) but not the others. In order to simplify the help text, split the blink subcommand help text from the off|on|toggle subcommands. Then, fix the help text so that it is clear that the frequency is required. While at it, specify the duty cycle. Fixes: ffe2052d6e8a ("dm: led: Add a new 'led' command") Signed-off-by: Quentin Schulz --- cmd/led.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/cmd/led.c b/cmd/led.c index 91fb856ee59..296c07b3b38 100644 --- a/cmd/led.c +++ b/cmd/led.c @@ -118,16 +118,13 @@ int do_led(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) return 0; } -#if defined(CONFIG_LED_BLINK) || defined(CONFIG_LED_SW_BLINK) -#define BLINK "|blink [blink-freq in ms]" -#else -#define BLINK "" -#endif - U_BOOT_CMD( led, 4, 1, do_led, "manage LEDs", - " on|off|toggle" BLINK "\tChange LED state\n" + " on|off|toggle\tChange LED state\n" +#if defined(CONFIG_LED_BLINK) || defined(CONFIG_LED_SW_BLINK) + "led blink \tBlink LED (duty cycle 50%)\n" +#endif "led \tGet LED state\n" "led list\t\tshow a list of LEDs" ); From e8bc14192386b62fbd80c37baf5b0720cd4d61af Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:07 +0100 Subject: [PATCH 02/11] doc: move legacy API documented in README.LED to doc/api/led.rst This moves the content of the legacy LED API from doc/READ.LED to doc/api/led.rst, applying minimal cosmetic changes to "nicely" integrate it with the current docs and adding a small introduction to the legacy API section. Signed-off-by: Quentin Schulz --- doc/README.LED | 77 ------------------------------------------ doc/api/led.rst | 89 ++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 88 insertions(+), 78 deletions(-) delete mode 100644 doc/README.LED diff --git a/doc/README.LED b/doc/README.LED deleted file mode 100644 index c21c9d53ec3..00000000000 --- a/doc/README.LED +++ /dev/null @@ -1,77 +0,0 @@ -Status LED -======================================== - -This README describes the status LED API. - -The API is defined by the include file include/status_led.h - -The first step is to enable CONFIG_LED_STATUS in menuconfig: -> Device Drivers > LED Support. - -If the LED support is only for specific board, enable -CONFIG_LED_STATUS_BOARD_SPECIFIC in the menuconfig. - -Status LEDS 0 to 5 are enabled by the following configurations at menuconfig: -CONFIG_STATUS_LED0, CONFIG_STATUS_LED1, ... CONFIG_STATUS_LED5 - -The following should be configured for each of the enabled LEDs: -CONFIG_STATUS_LED_BIT -CONFIG_STATUS_LED_STATE -CONFIG_STATUS_LED_FREQ -Where is an integer 1 through 5 (empty for 0). - -CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify which LED -is being acted on. As such, the value choose must be unique with with respect to -the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is the -reponsiblity of the __led_* function. - -CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set to one -of these values: CONFIG_LED_STATUS_OFF or CONFIG_LED_STATUS_ON. - -CONFIG_STATUS_LED_FREQ determines the LED blink frequency. -Values range from 2 to 10. - -Some other LED macros ---------------------- - -CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting. -This must be a valid LED number (0-5). - -CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors. This must be -a valid LED number (0-5). Other similar color LED's macros are -CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and CONFIG_STATUS_LED_BLUE. - -General LED functions ---------------------- -The following functions should be defined: - -__led_init is called once to initialize the LED to CONFIG_STATUS_LED_STATE. -One time start up code should be placed here. - -__led_set is called to change the state of the LED. - -__led_toggle is called to toggle the current state of the LED. - -Colour LED -======================================== - -Colour LED's are at present only used by ARM. - -The functions names explain their purpose. - -coloured_LED_init -red_LED_on -red_LED_off -green_LED_on -green_LED_off -yellow_LED_on -yellow_LED_off -blue_LED_on -blue_LED_off - -These are weakly defined in arch/arm/lib/board.c to noops. Where applicable, define -these functions in the board specific source. - -TBD : Describe older board dependent macros similar to what is done for - -TBD : Describe general support via asm/status_led.h diff --git a/doc/api/led.rst b/doc/api/led.rst index e52e350d1bb..661d1379620 100644 --- a/doc/api/led.rst +++ b/doc/api/led.rst @@ -7,4 +7,91 @@ LED :doc: Overview .. kernel-doc:: include/led.h - :internal: \ No newline at end of file + :internal: + +Legacy LED +========== + +Please use the new LED API as defined above. This section is only for reference +for currently supported devices and to aid for migration to the new API. + +Status LED +---------- + +This README describes the status LED API. + +The API is defined by the include file include/status_led.h + +The first step is to enable CONFIG_LED_STATUS in menuconfig:: + + > Device Drivers > LED Support. + +If the LED support is only for specific board, enable +CONFIG_LED_STATUS_BOARD_SPECIFIC in the menuconfig. + +Status LEDS 0 to 5 are enabled by the following configurations at menuconfig: +CONFIG_STATUS_LED0, CONFIG_STATUS_LED1, ... CONFIG_STATUS_LED5 + +The following should be configured for each of the enabled LEDs: + +- CONFIG_STATUS_LED_BIT +- CONFIG_STATUS_LED_STATE +- CONFIG_STATUS_LED_FREQ + +Where is an integer 1 through 5 (empty for 0). + +CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify which LED +is being acted on. As such, the value choose must be unique with with respect to +the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is the +reponsiblity of the __led_* function. + +CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set to one +of these values: CONFIG_LED_STATUS_OFF or CONFIG_LED_STATUS_ON. + +CONFIG_STATUS_LED_FREQ determines the LED blink frequency. +Values range from 2 to 10. + +Some other LED macros +~~~~~~~~~~~~~~~~~~~~~ + +CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting. +This must be a valid LED number (0-5). + +CONFIG_STATUS_LED_RED is the red LED. It is used to signal errors. This must be +a valid LED number (0-5). Other similar color LED's macros are +CONFIG_STATUS_LED_GREEN, CONFIG_STATUS_LED_YELLOW and CONFIG_STATUS_LED_BLUE. + +General LED functions +~~~~~~~~~~~~~~~~~~~~~ +The following functions should be defined: + +__led_init is called once to initialize the LED to CONFIG_STATUS_LED_STATE. +One time start up code should be placed here. + +__led_set is called to change the state of the LED. + +__led_toggle is called to toggle the current state of the LED. + +Colour LED +---------- + +Colour LED's are at present only used by ARM. + +The functions names explain their purpose. + +- coloured_LED_init +- red_LED_on +- red_LED_off +- green_LED_on +- green_LED_off +- yellow_LED_on +- yellow_LED_off +- blue_LED_on +- blue_LED_off + +These are weakly defined in arch/arm/lib/board.c to noops. Where applicable, define +these functions in the board specific source. + +TBD : Describe older board dependent macros similar to what is done for + +TBD : Describe general support via asm/status_led.h From b8c35fa9c58aeb16bd56433b551203ec70c87517 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:08 +0100 Subject: [PATCH 03/11] doc: cmd: document the led shell command This adds documentation on how to use the led shell command. Signed-off-by: Quentin Schulz --- doc/usage/cmd/led.rst | 95 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 doc/usage/cmd/led.rst diff --git a/doc/usage/cmd/led.rst b/doc/usage/cmd/led.rst new file mode 100644 index 00000000000..b5623895c7e --- /dev/null +++ b/doc/usage/cmd/led.rst @@ -0,0 +1,95 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +.. index:: + single: led (command) + +led command +=========== + +Synopsis +-------- + +:: + + led + led blink + led + led list + +led +--------------- + +Get state of the LED whose label is the one passed as ```` argument. + +Provided ```` is *module_led*, the possible outputs for this command +are:: + + LED 'module_led': off + LED 'module_led': on + LED 'module_led': blink + +led on|off|toggle +----------------------------- + +Turn on, off or toggle state of the LED whose label is the one passed as +```` argument. + +led blink +---------------------------------------- + +Make the LED whose label is the one passed as ```` argument blink at +a frequency specified by the argument ````. + +The frequency is parsed as a decimal number and its unit is milliseconds. The +duty cycle is 50%. Example:: + + led blue blink 1000 + +will make the *blue*-labeled LED blink with a state (on or off) kept for 500ms +before switching to the other state (respectively off or on) for 500ms, +looping endlessly. + +led list +-------- + +List all available LEDs by their label and provide their known state, which can +be either *off*, *on* or *blink*. + +If a LED has not been probed yet, its state will be shown as ** in the +list. + +Examples +-------- + +:: + + => led list + module_led on + sd_card_led + => led module_led + LED 'module_led': on + => led module_led off + => led module_led + LED 'module_led': off + => led module_led toggle + => led module_led + LED 'module_led': on + => led module_led toggle + => led module_led + LED 'module_led': off + => led module_led blink 1000 + => led module_led + LED 'module_led': blink + => led sd_card_led + LED 'sd_card_led': off + => led list + module_led blink + sd_card_led off + +Configuration +------------- + +The *led* commands are only available if ``CONFIG_CMD_LED=y``. + +The *led blink* command is only available if ``CONFIG_CMD_LED=y`` +and either ``CONFIG_LED_BLINK=y`` or ``CONFIG_LED_SW_BLINK=y``. From b0f39c085dc8f99becd7b2a83d43958c5e6fa936 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:09 +0100 Subject: [PATCH 04/11] doc: dt-bindings: remove duplicates with dts/upstream doc/device-tree-bindings/leds/leds-bcm6328.txt can be found at dts/upstream/Bindings/leds/leds-bcm6328.yaml. doc/device-tree-bindings/leds/leds-bcm6358.txt can be found at dts/upstream/Bindings/leds/leds-bcm6358.txt. doc/device-tree-bindings/leds/leds-gpio.txt can be found at dts/upstream/Bindings/leds/leds-gpio.yaml. doc/device-tree-bindings/leds/leds-lp5562.txt can be found at dts/upstream/Bindings/leds/leds-lp55xx.yaml. Only two LED dt-bindings are left in U-Boot: leds-bcm6858.txt and leds-pwm.txt. The former is partially supported by dts/upstream/Bindings/leds/leds-bcm63138.yaml but is lacking all optional properties we have listed in "downstream" dt-binding in U-Boot. However, there doesn't seem to exist any user of that compatible. The latter is partially supported by dts/upstream/Bindings/leds/leds-pwm.yaml but is missing the u-boot,default-brightness property, which is used by arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi at the moment. The default-brightness property is probably not what we want here as it defaults to max-brightness if missing. I'm assuming we want a different value for U-Boot (127) and the kernel (255 via max-brightness as a default), which would prevent us from upstreaming this property, which doesn't change the status quo, so let it be for now. Signed-off-by: Quentin Schulz --- .../leds/leds-bcm6328.txt | 106 ------------- .../leds/leds-bcm6358.txt | 141 ------------------ doc/device-tree-bindings/leds/leds-gpio.txt | 52 ------- doc/device-tree-bindings/leds/leds-lp5562.txt | 63 -------- 4 files changed, 362 deletions(-) delete mode 100644 doc/device-tree-bindings/leds/leds-bcm6328.txt delete mode 100644 doc/device-tree-bindings/leds/leds-bcm6358.txt delete mode 100644 doc/device-tree-bindings/leds/leds-gpio.txt delete mode 100644 doc/device-tree-bindings/leds/leds-lp5562.txt diff --git a/doc/device-tree-bindings/leds/leds-bcm6328.txt b/doc/device-tree-bindings/leds/leds-bcm6328.txt deleted file mode 100644 index 7f5597b7373..00000000000 --- a/doc/device-tree-bindings/leds/leds-bcm6328.txt +++ /dev/null @@ -1,106 +0,0 @@ -LEDs connected to Broadcom BCM6328 controller - -This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268. -In these SoCs it's possible to control LEDs both as GPIOs or by hardware. -However, on some devices there are Serial LEDs (LEDs connected to a 74x164 -controller), which can either be controlled by software (exporting the 74x164 -as spi-gpio. See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or -by hardware using this driver. -Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and -exporting the 74x164 as spi-gpio prevents those LEDs to be hardware -controlled, so the only chance to keep them working is by using this driver. - -Required properties: - - compatible : should be "brcm,bcm6328-leds". - - #address-cells : must be 1. - - #size-cells : must be 0. - - reg : BCM6328 LED controller address and size. - -Optional properties: - - brcm,serial-leds : Boolean, enables Serial LEDs. - Default : false - - brcm,serial-mux : Boolean, enables Serial LEDs multiplexing. - Default : false - - brcm,serial-clk-low : Boolean, makes clock signal active low. - Default : false - - brcm,serial-dat-low : Boolean, makes data signal active low. - Default : false - - brcm,serial-shift-inv : Boolean, inverts Serial LEDs shift direction. - Default : false - -Each LED is represented as a sub-node of the brcm,bcm6328-leds device. - -LED sub-node required properties: - - reg : LED pin number (only LEDs 0 to 23 are valid). - -LED sub-node optional properties: - - label : see Documentation/devicetree/bindings/leds/common.txt - - active-low : Boolean, makes LED active low. - Default : false - -Examples: -Scenario 1 : BCM6328 with 4 GPIO LEDs - leds0: led-controller@10000800 { - compatible = "brcm,bcm6328-leds"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x10000800 0x24>; - - alarm_red@2 { - reg = <2>; - active-low; - label = "red:alarm"; - }; - inet_green@3 { - reg = <3>; - active-low; - label = "green:inet"; - }; - power_green@4 { - reg = <4>; - active-low; - label = "green:power"; - }; - }; - -Scenario 2 : BCM63268 with Serial LEDs - leds0: led-controller@10001900 { - compatible = "brcm,bcm6328-leds"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x10001900 0x24>; - brcm,serial-leds; - brcm,serial-dat-low; - brcm,serial-shift-inv; - - inet_red@2 { - reg = <2>; - active-low; - label = "red:inet"; - }; - dsl_green@3 { - reg = <3>; - active-low; - label = "green:dsl"; - }; - usb_green@4 { - reg = <4>; - active-low; - label = "green:usb"; - }; - wps_green@7 { - reg = <7>; - active-low; - label = "green:wps"; - }; - inet_green@8 { - reg = <8>; - active-low; - label = "green:inet"; - }; - power_green@20 { - reg = <20>; - active-low; - label = "green:power"; - }; - }; diff --git a/doc/device-tree-bindings/leds/leds-bcm6358.txt b/doc/device-tree-bindings/leds/leds-bcm6358.txt deleted file mode 100644 index e394d9ebb40..00000000000 --- a/doc/device-tree-bindings/leds/leds-bcm6358.txt +++ /dev/null @@ -1,141 +0,0 @@ -LEDs connected to Broadcom BCM6358 controller - -This controller is present on BCM6358 and BCM6368. -In these SoCs there are Serial LEDs (LEDs connected to a 74x164 controller), -which can either be controlled by software (exporting the 74x164 as spi-gpio. -See Documentation/devicetree/bindings/gpio/gpio-74x164.txt), or -by hardware using this driver. - -Required properties: - - compatible : should be "brcm,bcm6358-leds". - - #address-cells : must be 1. - - #size-cells : must be 0. - - reg : BCM6358 LED controller address and size. - -Optional properties: - - brcm,clk-div : SCK signal divider. Possible values are 1, 2, 4 and 8. - Default : 1 - - brcm,clk-dat-low : Boolean, makes clock and data signals active low. - Default : false - -Each LED is represented as a sub-node of the brcm,bcm6358-leds device. - -LED sub-node required properties: - - reg : LED pin number (only LEDs 0 to 31 are valid). - -LED sub-node optional properties: - - label : see Documentation/devicetree/bindings/leds/common.txt - - active-low : Boolean, makes LED active low. - Default : false - -Examples: -Scenario 1 : BCM6358 - leds0: led-controller@fffe00d0 { - compatible = "brcm,bcm6358-leds"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0xfffe00d0 0x8>; - - alarm_white { - reg = <0>; - active-low; - label = "white:alarm"; - }; - tv_white { - reg = <2>; - active-low; - label = "white:tv"; - }; - tel_white { - reg = <3>; - active-low; - label = "white:tel"; - }; - adsl_white { - reg = <4>; - active-low; - label = "white:adsl"; - }; - }; - -Scenario 2 : BCM6368 - leds0: led-controller@100000d0 { - compatible = "brcm,bcm6358-leds"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x100000d0 0x8>; - brcm,pol-low; - brcm,clk-div = <4>; - - power_red { - reg = <0>; - active-low; - label = "red:power"; - }; - power_green { - reg = <1>; - active-low; - label = "green:power"; - default-state = "on"; - }; - power_blue { - reg = <2>; - label = "blue:power"; - }; - broadband_red { - reg = <3>; - active-low; - label = "red:broadband"; - }; - broadband_green { - reg = <4>; - label = "green:broadband"; - }; - broadband_blue { - reg = <5>; - active-low; - label = "blue:broadband"; - }; - wireless_red { - reg = <6>; - active-low; - label = "red:wireless"; - }; - wireless_green { - reg = <7>; - active-low; - label = "green:wireless"; - }; - wireless_blue { - reg = <8>; - label = "blue:wireless"; - }; - phone_red { - reg = <9>; - active-low; - label = "red:phone"; - }; - phone_green { - reg = <10>; - active-low; - label = "green:phone"; - }; - phone_blue { - reg = <11>; - label = "blue:phone"; - }; - upgrading_red { - reg = <12>; - active-low; - label = "red:upgrading"; - }; - upgrading_green { - reg = <13>; - active-low; - label = "green:upgrading"; - }; - upgrading_blue { - reg = <14>; - label = "blue:upgrading"; - }; - }; diff --git a/doc/device-tree-bindings/leds/leds-gpio.txt b/doc/device-tree-bindings/leds/leds-gpio.txt deleted file mode 100644 index df1b3080f6b..00000000000 --- a/doc/device-tree-bindings/leds/leds-gpio.txt +++ /dev/null @@ -1,52 +0,0 @@ -LEDs connected to GPIO lines - -Required properties: -- compatible : should be "gpio-leds". - -Each LED is represented as a sub-node of the gpio-leds device. Each -node's name represents the name of the corresponding LED. - -LED sub-node properties: -- gpios : Should specify the LED's GPIO, see "gpios property" in - Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be - indicated using flags in the GPIO specifier. -- label : (optional) - see Documentation/devicetree/bindings/leds/common.txt -- linux,default-trigger : (optional) - see Documentation/devicetree/bindings/leds/common.txt -- default-state: (optional) The initial state of the LED. Valid - values are "on", "off", and "keep". If the LED is already on or off - and the default-state property is set the to same value, then no - glitch should be produced where the LED momentarily turns off (or - on). The "keep" setting will keep the LED at whatever its current - state is, without producing a glitch. The default is off if this - property is not present. - -Examples: - -leds { - compatible = "gpio-leds"; - hdd { - label = "IDE Activity"; - gpios = <&mcu_pio 0 1>; /* Active low */ - linux,default-trigger = "ide-disk"; - }; - - fault { - gpios = <&mcu_pio 1 0>; - /* Keep LED on if BIOS detected hardware fault */ - default-state = "keep"; - }; -}; - -run-control { - compatible = "gpio-leds"; - red { - gpios = <&mpc8572 6 0>; - default-state = "off"; - }; - green { - gpios = <&mpc8572 7 0>; - default-state = "on"; - }; -}; diff --git a/doc/device-tree-bindings/leds/leds-lp5562.txt b/doc/device-tree-bindings/leds/leds-lp5562.txt deleted file mode 100644 index 4e0c742959a..00000000000 --- a/doc/device-tree-bindings/leds/leds-lp5562.txt +++ /dev/null @@ -1,63 +0,0 @@ -LEDs connected to TI LP5562 controller - -This driver works with a TI LP5562 4-channel LED controller. -CONFIG_LED_BLINK is supported using the controller engines. However -there are only 3 engines available for the 4 channels. This means -that the blue and white channels share the same engine. When both -blue and white LEDs are set to blink, they will share the same blink -rate. Changing the blink rate of the blue LED will affect the white -LED and vice-versa. Manual on/off is handled independently for all 4 -channels. - -Required properties: - - compatible : should be "ti,lp5562". - - #address-cells : must be 1. - - #size-cells : must be 0. - - reg : LP5562 LED controller I2C address. - -Optional properties: - - enable-gpios : Enable GPIO - - clock-mode : u8, configures the clock mode: - - 0 # automode - - 1 # internal - - 2 # external - -Each LED is represented as a sub-node of the ti,lp5562 device. - -LED sub-node required properties: - - reg : Zero-based channel identifier: - - 0 red - - 1 green - - 2 blue - - 3 white - -LED sub-node optional properties: - - chan-name : name of LED - - max-cur : LED current at max brightness in 100uA steps (0x00 - 0xFF) - Default : 100 (10 mA) - -Example: - leds0: lp5562@30 { - compatible = "ti,lp5562"; - #address-cells = <1>; - #size-cells = <0>; - enable-gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>; - reg = <0x30>; - clock-mode = /bits/8 <1>; - - led@0 { - reg = <0>; - chan-name = "red"; - max-cur = /bits/ 8 <200>; /* 20mA */ - }; - led@1 { - reg = <1>; - chan-name = "green"; - max-cur = /bits/ 8 <200>; /* 20mA */ - }; - led@2 { - reg = <2>; - chan-name = "blue"; - max-cur = /bits/ 8 <200>; /* 20mA */ - }; - }; From f8c3a6ddc62b0b8139dbe66dd8a1c610c41d76a4 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:10 +0100 Subject: [PATCH 05/11] arm: dts: rockchip: rk3188-radxarock: remove unused u-boot,boot-led This property is only read in arch/arm/mach-rockchip/rk3188/rk3188.c when CONFIG_SPL_LED is enabled, which isn't the case for this board, so let's remove dead code. Additionally, if we ever want to enable this LED as Boot LED, we should instead be using boot-led phandle property in /options/u-boot[1] Device Tree node with the "new" LED UCLASS devices. [1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116 Signed-off-by: Quentin Schulz --- arch/arm/dts/rk3188-radxarock-u-boot.dtsi | 5 ----- 1 file changed, 5 deletions(-) diff --git a/arch/arm/dts/rk3188-radxarock-u-boot.dtsi b/arch/arm/dts/rk3188-radxarock-u-boot.dtsi index 7bcbc2967a9..c65fbab75bf 100644 --- a/arch/arm/dts/rk3188-radxarock-u-boot.dtsi +++ b/arch/arm/dts/rk3188-radxarock-u-boot.dtsi @@ -10,11 +10,6 @@ /* stdout-path = &uart2; */ stdout-path = "serial2:115200n8"; }; - - config { - u-boot,boot-led = "rock:red:power"; - bootph-all; - }; }; &cru { From 7759839fb299c9dea4beb1232dadb3141c7fa8bc Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:11 +0100 Subject: [PATCH 06/11] rockchip: rk3188: remove setup_led from xPL There's not a single device making use of that code and it anyway shouldn't be using the old deprecated u-boot,boot-led /config property anymore but rather boot-led from /options/u-boot[1] Device Tree node. Because spl_board_init() is only present to call this now removed function, we can remove it as well as SPL_BOARD_INIT which is the symbol guarding calls to spl_board_init() (which is now also removed). [1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116 Signed-off-by: Quentin Schulz --- arch/arm/mach-rockchip/Kconfig | 1 - arch/arm/mach-rockchip/rk3188/rk3188.c | 36 -------------------------- 2 files changed, 37 deletions(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 342933ca509..f78eaf52c2a 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -76,7 +76,6 @@ config ROCKCHIP_RK3128 config ROCKCHIP_RK3188 bool "Support Rockchip RK3188" select CPU_V7A - select SPL_BOARD_INIT if SPL select SUPPORT_SPL select SPL select SPL_CLK diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c b/arch/arm/mach-rockchip/rk3188/rk3188.c index 7cce1112fbd..8aed46f0b3b 100644 --- a/arch/arm/mach-rockchip/rk3188/rk3188.c +++ b/arch/arm/mach-rockchip/rk3188/rk3188.c @@ -105,39 +105,3 @@ int rk_board_late_init(void) return rk3188_board_late_init(); } - -#ifdef CONFIG_XPL_BUILD -static int setup_led(void) -{ -#ifdef CONFIG_SPL_LED - struct udevice *dev; - char *led_name; - int ret; - - led_name = ofnode_conf_read_str("u-boot,boot-led"); - if (!led_name) - return 0; - ret = led_get_by_label(led_name, &dev); - if (ret) { - debug("%s: get=%d\n", __func__, ret); - return ret; - } - ret = led_set_state(dev, LEDST_ON); - if (ret) - return ret; -#endif - - return 0; -} - -void spl_board_init(void) -{ - int ret; - - ret = setup_led(); - if (ret) { - debug("LED ret=%d\n", ret); - hang(); - } -} -#endif From cf8e0d58cedc38375705ad2cf5c52b0f9bd760f2 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:12 +0100 Subject: [PATCH 07/11] arm: dts: rockchip: rk3399-puma: remove u-boot,boot-led There's no code to make use of it. Further more, the HW default state of that LED is on and migrating this to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot reaches its main-loop. Blinking the LED_BOOT also doesn't help because it doesn't blink for long enough to be noticeable before it's kept on. This is by design, c.f. https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34 If we want this LED to be doing something different, it'll need to be handled by a board file anyway. Considering it hasn't worked in many years, let's just remove it. Signed-off-by: Quentin Schulz --- arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi index 55895d0dd19..76e091be232 100644 --- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi +++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi @@ -17,7 +17,6 @@ u-boot,spl-payload-offset = <0x80000>; /* @ 512KB */ u-boot,mmc-env-offset = <0x5000>; /* @ 20KB */ u-boot,efi-partition-entries-offset = <0x200000>; /* 2MB */ - u-boot,boot-led = "module_led"; sysreset-gpio = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>; }; From 0636153fb199c110d0888c63072b248939f85594 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:13 +0100 Subject: [PATCH 08/11] arm: dts: rockchip: px30-ringneck: remove u-boot,boot-led There's no code to make use of it. Further more, the HW default state of that LED is on and migrating this to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot reaches its main-loop. Blinking the LED_BOOT also doesn't help because it doesn't blink for long enough to be noticeable before it's kept on. This is by design, c.f. https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34 If we want this LED to be doing something different, it'll need to be handled by a board file anyway. Considering it hasn't worked in many years (if ever), let's just remove it. Signed-off-by: Quentin Schulz --- arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi b/arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi index 29ea2763636..8f4c9ad1f4a 100644 --- a/arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi +++ b/arch/arm/dts/px30-ringneck-haikou-u-boot.dtsi @@ -6,7 +6,6 @@ config { u-boot,mmc-env-offset = <0x5000>; /* @ 20KB */ u-boot,efi-partition-entries-offset = <0x200000>; /* 2MB */ - u-boot,boot-led = "module_led"; }; chosen { From d1ad89ad56ad27a5cb2dd5b4f82a74b7ccf966bd Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:14 +0100 Subject: [PATCH 09/11] arm: dts: rockchip: rk3066a-mk808: remove unused u-boot,boot-led There's no code to make use of it. Additionally, if we ever want to enable this LED as Boot LED, we should instead be using boot-led phandle property in /options/u-boot[1] Device Tree node with the "new" LED UCLASS devices. So let's simply remove this unused property to not mislead users. [1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116 Signed-off-by: Quentin Schulz --- arch/arm/dts/rk3066a-mk808-u-boot.dtsi | 6 ------ 1 file changed, 6 deletions(-) diff --git a/arch/arm/dts/rk3066a-mk808-u-boot.dtsi b/arch/arm/dts/rk3066a-mk808-u-boot.dtsi index 4474be962df..dd2eff529e9 100644 --- a/arch/arm/dts/rk3066a-mk808-u-boot.dtsi +++ b/arch/arm/dts/rk3066a-mk808-u-boot.dtsi @@ -2,12 +2,6 @@ #include "rk3066a-u-boot.dtsi" -/ { - config { - u-boot,boot-led = "mk808:blue:power"; - }; -}; - &cru { bootph-all; }; From 98be3062088a81cf7124cf16f05c7ae735587bf7 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:15 +0100 Subject: [PATCH 10/11] sam9x60-curiosity: migrate Boot LED setup to use /options/u-boot/boot-led This board is one of the last users of /config/u-boot,boot-led property which is a U-Boot property out of the DT spec. Let's migrate it to use the in-spec /options/u-boot/boot-led property. When enabling LED_BOOT, U-Boot proper will lit the LED right before entering the main loop, so nothing needs to be done in board files. As explained in the commit adding support for this u-boot,boot-led property, let's keep backward compatibility in case LED_BOOT isn't selected. Note that this is not tested as I do not own this device. Cc: Alexander Dahl Signed-off-by: Quentin Schulz Tested-by: Alexander Dahl --- arch/arm/dts/at91-sam9x60_curiosity-u-boot.dtsi | 9 ++++++--- .../atmel/sam9x60_curiosity/sam9x60_curiosity.c | 16 +--------------- 2 files changed, 7 insertions(+), 18 deletions(-) diff --git a/arch/arm/dts/at91-sam9x60_curiosity-u-boot.dtsi b/arch/arm/dts/at91-sam9x60_curiosity-u-boot.dtsi index 9144387861e..b8f16c0b0c0 100644 --- a/arch/arm/dts/at91-sam9x60_curiosity-u-boot.dtsi +++ b/arch/arm/dts/at91-sam9x60_curiosity-u-boot.dtsi @@ -21,8 +21,11 @@ bootph-all; }; - config { - u-boot,boot-led = "blue"; + options { + u-boot { + compatible = "u-boot,config"; + boot-led = <&led_blue>; + }; }; leds { @@ -34,7 +37,7 @@ default-state = "off"; }; - led-blue { + led_blue: led-blue { default-state = "off"; }; }; diff --git a/board/atmel/sam9x60_curiosity/sam9x60_curiosity.c b/board/atmel/sam9x60_curiosity/sam9x60_curiosity.c index e75043ec00f..3393478e4c8 100644 --- a/board/atmel/sam9x60_curiosity/sam9x60_curiosity.c +++ b/board/atmel/sam9x60_curiosity/sam9x60_curiosity.c @@ -28,21 +28,7 @@ void at91_prepare_cpu_var(void); static void board_leds_init(void) { -#if CONFIG_IS_ENABLED(LED) - const char *led_name; - struct udevice *dev; - int ret; - - led_name = ofnode_conf_read_str("u-boot,boot-led"); - if (!led_name) - return; - - ret = led_get_by_label(led_name, &dev); - if (ret) - return; - - led_set_state(dev, LEDST_ON); -#else +#if !CONFIG_IS_ENABLED(LED_BOOT) at91_set_pio_output(AT91_PIO_PORTD, 17, 0); /* LED RED */ at91_set_pio_output(AT91_PIO_PORTD, 19, 0); /* LED GREEN */ at91_set_pio_output(AT91_PIO_PORTD, 21, 1); /* LED BLUE */ From eb02d87c7579f83f6fe153c80d420e5f53bde4c1 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Wed, 12 Nov 2025 18:48:16 +0100 Subject: [PATCH 11/11] doc: remove u-boot,boot-led and u-boot,error-led from "binding" We're aiming to reduce the amount of U-Boot-specific and out-of-spec Device Tree additions. Those two properties haven't been doing anything for a long time already, except when read by board files manually. This is still the case for STM32 boards but those will be migrated in the near future according to their maintainer. In any case, let's not encourage people to add either of these properties to new or existing Device Trees and remove it from the bindings. Signed-off-by: Quentin Schulz --- doc/device-tree-bindings/config.txt | 5 ----- 1 file changed, 5 deletions(-) diff --git a/doc/device-tree-bindings/config.txt b/doc/device-tree-bindings/config.txt index fffb69e75de..3756f57bf44 100644 --- a/doc/device-tree-bindings/config.txt +++ b/doc/device-tree-bindings/config.txt @@ -26,11 +26,6 @@ bootdelay (int) images is being packed for testing or a user holds down a button, it may allow a delay, but disable it for production. -u-boot,boot-led (string) -u-boot,error-led (string) - This is used to specify the label for an LED to indicate an error and - a successful boot, on supported hardware. - bootsecure (int) Indicates that U-Boot should use secure_boot_cmd() to run commands, rather than the normal CLI. This can be used in production images, to