From: Tom Rini Date: Wed, 3 Dec 2025 17:04:32 +0000 (-0600) Subject: Merge patch series "led: remove u-boot,boot-led and u-boot,error-led + add cmd doc" X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=d300702c5be5a846032834abe4f01dcd3f50b3a8;p=thirdparty%2Fu-boot.git Merge patch series "led: remove u-boot,boot-led and u-boot,error-led + add cmd doc" Quentin Schulz 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 --- d300702c5be5a846032834abe4f01dcd3f50b3a8 diff --cc doc/api/led.rst index e52e350d1bb,661d1379620..2faf6693604 --- a/doc/api/led.rst +++ b/doc/api/led.rst @@@ -7,4 -7,91 +7,91 @@@ LE :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 + - 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 ++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