michael/u-boot
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge patch series "led: remove u-boot,boot-led and u-boot,error-led + add cmd doc"

Browse Source 
Quentin Schulz <foss+uboot@0leil.net> says:

u-boot,boot-led and u-boot,error-led aren't actually handled by some
generic code but rather by board or architecture specific code. They
also aren't properties that are part of the official dt-binding so they
cannot be upstreamed. For u-boot,boot-led, there's actually a proper
replacement which is /options/u-boot/boot-led[1] (+ CONFIG_LED_BOOT=y).

For Rockchip boards, either nothing (for RK3066, PX30 and RK3399) was
using that property or (for RK3188) the code handling it was guarded by
symbols that were not enabled in the defconfig. For those, the property
and guarded code are removed.

For the Sam9x60 Curiosity, it seems that even though the LED is
controlled whenever CONFIG_LED is enabled, it isn't enabled by default
in the defconfig (but the code was added without modifying the
defconfig, explicitly leaving a choice to the user). I decided to keep
that feature by simply migrating it to the new API, though I cannot test
it as I do not own the device.

The STM32 boards will be migrated in the near future once their upstream
(kernel) Device Trees gain the new way to specify this (via
/options/u-boot/boot-led). I'll let Patrice handle this, see
https://lore.kernel.org/u-boot/94ed1988-13e8-4fe3-bdff-ba2c9973c556@foss.st.com/
and
https://lore.kernel.org/u-boot/2a3aa43a-ce19-41e1-ab56-556629ce5cf9@foss.st.com/

After this, only one user of u-boot,boot-led will be left, based on
STM32: board/dhelectronics/dh_stm32mp1/board.c. @Patrice, maybe that's
something you want to have a look at as well, this seems to be some
evaluation kit?

The only users of u-boot,error-led are STM32 boards, so I'll leave this
to Patrice as well, I do not know what's the way to go for that one.

In any case, I would like to not encourage people to use out-of-spec DT
properties when there is another option (u-boot,boot-led), so I remove
the properties from the dt-binding document from U-Boot.

The help text for the blink subcommand of the led command was misleading
so this is now fixed.

This also moves the content of doc/README.LED into the doc/api/led.rst,
while clearly stating one shouldn't be using this anymore.

This also gets rid of dt-binding that we already have in dts/upstream.

Finally, this adds documentation for the led shell command.

[1] https://github.com/devicetree-org/dt-schema/blob/v2025.08/dtschema/schemas/options/u-boot.yaml#L113-L116

Link: https://lore.kernel.org/r/20251112-led-old-dt-v1-0-2892d49517db@cherry.de
This commit is contained in:
Tom Rini
2025-12-03 11:04:32 -06:00
parent dca19206ac eb02d87c75
commit d300702c5b
17 changed files with 194 additions and 520 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
doc/README.LED
View File

@@ -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<n>
CONFIG_STATUS_LED_STATE<n>
CONFIG_STATUS_LED_FREQ<n>
Where <n> 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

89
doc/api/led.rst
View File

@@ -7,4 +7,91 @@ LED
:doc: Overview
.. kernel-doc:: include/led.h
:internal:
: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<n>
- CONFIG_STATUS_LED_STATE<n>
- CONFIG_STATUS_LED_FREQ<n>
Where <n> 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 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

5
doc/device-tree-bindings/config.txt
View File

@@ -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

106
doc/device-tree-bindings/leds/leds-bcm6328.txt
View File

@@ -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";
};
};

141
doc/device-tree-bindings/leds/leds-bcm6358.txt
View File

@@ -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";
};
};

52
doc/device-tree-bindings/leds/leds-gpio.txt
View File

@@ -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";
};
};

63
doc/device-tree-bindings/leds/leds-lp5562.txt
View File

@@ -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 */
};
};

95
doc/usage/cmd/led.rst Normal file
View File

@@ -0,0 +1,95 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
.. index::
single: led (command)
led command
===========
Synopsis
--------
::
led <led_label> <on|off|toggle>
led <led_label> blink <blink-freq in ms>
led <led_label>
led list
led <led_label>
---------------
Get state of the LED whose label is the one passed as ``<led_label>`` argument.
Provided ``<led_label>`` is *module_led*, the possible outputs for this command
are::
LED 'module_led': off
LED 'module_led': on
LED 'module_led': blink
led <led_label> on|off|toggle
-----------------------------
Turn on, off or toggle state of the LED whose label is the one passed as
``<led_label>`` argument.
led <led_label> blink <blink-freq in ms>
----------------------------------------
Make the LED whose label is the one passed as ``<led_label>`` argument blink at
a frequency specified by the argument ``<blink-freq in ms>``.
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 *<inactive>* in the
list.
Examples
--------
::
=> led list
module_led on
sd_card_led <inactive>
=> 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 <led_label> blink* command is only available if ``CONFIG_CMD_LED=y``
and either ``CONFIG_LED_BLINK=y`` or ``CONFIG_LED_SW_BLINK=y``.