[PATCH v3 00/25] led: Remove old status-LED code
There has been an LED framework in U-Boot which uses driver model for about 9 years now. Recent work is underway to improve it and provide more features. It is probably a good time to drop the old code, which is only used by 5 boards:
./tools/qconfig.py -f LED_STATUS 5 matches eb_cpu5282 eb_cpu5282_internal mx23_olinuxino pinephone socfpga_vining_fpga
This series attempts that.
The new /options node provides a way to provide U-Boot settings, and LEDs are implemented there. For now I have brought into the options schema from upstream. We can update it once the LED additions land there.
Changes in v3: - Update commit message - Combine removal and enable patches - Combine removal and enable patches - Combine removal and enable patches
Changes in v2: - Combine code-removal and defconfig changes - Add a patch to enable LED and LED_BOOT for these boards - Enable LED on the 5 affected platforms - Reorder patches for bisectability - Add dt-schema bindings for LED
Simon Glass (25): eb_cpu5282: Drop status-LED code and enable LED vining_fpga: Drop status-LED code and use LED mx23_olinuxino: Drop status-LED code and use LED pinephone: Drop status-LED code and use LED led: Drop LED_STATUS_BOARD_SPECIFIC arm: Drop old LED support common: doc: Drop old LED support st: stm32f429: Drop old LED code led: Make the LED config common led: Drop LED_STATUS from Kconfig led: Drop the legacy LED command misc: Drop gpio_led driver pca9551_led: Delete driver misc: status_led: Delete driver m68k: Drop unused status_led.h header file powerpc: Drop status-LED code igep00x0: Drop unused status_led.h header file sunxi: Drop status-LED code common: Drop status-LED code in board_r image: Drop unused status_led.h header file ide: Drop unused status_led.h header file mpc83xx: Drop status-LED code net: Drop status-LED code led: Drop status_led header file doc: Add devicetree bindings for options
arch/arm/lib/crt0.S | 4 - arch/m68k/lib/bootm.c | 3 - arch/powerpc/lib/interrupts.c | 6 - board/BuS/eb_cpu5282/eb_cpu5282.c | 20 -- board/isee/igep00x0/igep00x0.c | 1 - board/olimex/mx23_olinuxino/mx23_olinuxino.c | 7 - board/softing/vining_fpga/socfpga.c | 4 - board/st/stm32f429-discovery/Makefile | 1 - board/st/stm32f429-discovery/led.c | 39 --- board/sunxi/board.c | 6 - boot/image.c | 4 - cmd/Makefile | 1 - cmd/ide.c | 4 - cmd/legacy_led.c | 185 ---------- common/board_f.c | 22 -- common/board_r.c | 27 -- configs/eb_cpu5282_defconfig | 8 +- configs/eb_cpu5282_internal_defconfig | 8 +- configs/mx23_olinuxino_defconfig | 10 +- configs/pinephone_defconfig | 7 +- configs/socfpga_vining_fpga_defconfig | 13 +- doc/README.LED | 77 ----- doc/device-tree-bindings/options.yaml | 79 +++++ doc/device-tree-bindings/options/u-boot.yaml | 136 ++++++++ drivers/led/Kconfig | 342 +------------------ drivers/misc/Kconfig | 13 - drivers/misc/Makefile | 3 - drivers/misc/gpio_led.c | 106 ------ drivers/misc/pca9551_led.c | 170 --------- drivers/misc/status_led.c | 124 ------- drivers/timer/mpc83xx_timer.c | 5 - include/configs/eb_cpu5282.h | 6 - include/status_led.h | 115 ------- net/bootp.c | 7 - net/net.c | 33 -- 35 files changed, 236 insertions(+), 1360 deletions(-) delete mode 100644 board/st/stm32f429-discovery/led.c delete mode 100644 cmd/legacy_led.c delete mode 100644 doc/README.LED create mode 100644 doc/device-tree-bindings/options.yaml create mode 100644 doc/device-tree-bindings/options/u-boot.yaml delete mode 100644 drivers/misc/gpio_led.c delete mode 100644 drivers/misc/pca9551_led.c delete mode 100644 drivers/misc/status_led.c delete mode 100644 include/status_led.h
Drop this old code. Swtich the LED options to use the new approach, in the same commit, to maintain build-bisectability.
Both eb_cpu5282 and eb_cpu5282_internal are done together, since they share code.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Update commit message
Changes in v2: - Combine code-removal and defconfig changes
board/BuS/eb_cpu5282/eb_cpu5282.c | 20 -------------------- configs/eb_cpu5282_defconfig | 8 ++------ configs/eb_cpu5282_internal_defconfig | 8 ++------ include/configs/eb_cpu5282.h | 6 ------ 4 files changed, 4 insertions(+), 38 deletions(-)
diff --git a/board/BuS/eb_cpu5282/eb_cpu5282.c b/board/BuS/eb_cpu5282/eb_cpu5282.c index c254da62bf4..cdd862c57d2 100644 --- a/board/BuS/eb_cpu5282/eb_cpu5282.c +++ b/board/BuS/eb_cpu5282/eb_cpu5282.c @@ -14,7 +14,6 @@ #include <bmp_layout.h> #include <env.h> #include <init.h> -#include <status_led.h> #include <bus_vcxk.h>
/*---------------------------------------------------------------------------*/ @@ -160,25 +159,6 @@ int misc_init_r(void) return 1; }
-void __led_toggle(led_id_t mask) -{ - MCFGPTA_GPTPORT ^= (1 << 3); -} - -void __led_init(led_id_t mask, int state) -{ - __led_set(mask, state); - MCFGPTA_GPTDDR |= (1 << 3); -} - -void __led_set(led_id_t mask, int state) -{ - if (state == CONFIG_LED_STATUS_ON) - MCFGPTA_GPTPORT |= (1 << 3); - else - MCFGPTA_GPTPORT &= ~(1 << 3); -} - /*---------------------------------------------------------------------------*/
/* EOF EB+MCF-EV123.c */ diff --git a/configs/eb_cpu5282_defconfig b/configs/eb_cpu5282_defconfig index 271dbdf4dbb..c51a5db262e 100644 --- a/configs/eb_cpu5282_defconfig +++ b/configs/eb_cpu5282_defconfig @@ -35,12 +35,8 @@ CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y CONFIG_SYS_RX_ETH_BUFFER=8 CONFIG_DM_I2C=y CONFIG_SYS_I2C_FSL=y -CONFIG_LED_STATUS=y -CONFIG_LED_STATUS0=y -CONFIG_LED_STATUS_BIT=8 -CONFIG_LED_STATUS_BOOT_ENABLE=y -CONFIG_LED_STATUS_BOOT=0 -CONFIG_LED_STATUS_CMD=y +CONFIG_LED=y +CONFIG_LED_BOOT=y CONFIG_MTD=y CONFIG_MTD_NOR_FLASH=y CONFIG_FLASH_CFI_DRIVER=y diff --git a/configs/eb_cpu5282_internal_defconfig b/configs/eb_cpu5282_internal_defconfig index 89a7925dffa..3627d25b990 100644 --- a/configs/eb_cpu5282_internal_defconfig +++ b/configs/eb_cpu5282_internal_defconfig @@ -33,12 +33,8 @@ CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y CONFIG_SYS_RX_ETH_BUFFER=8 CONFIG_DM_I2C=y CONFIG_SYS_I2C_FSL=y -CONFIG_LED_STATUS=y -CONFIG_LED_STATUS0=y -CONFIG_LED_STATUS_BIT=8 -CONFIG_LED_STATUS_BOOT_ENABLE=y -CONFIG_LED_STATUS_BOOT=0 -CONFIG_LED_STATUS_CMD=y +CONFIG_LED=y +CONFIG_LED_BOOT=y CONFIG_MTD=y CONFIG_MTD_NOR_FLASH=y CONFIG_FLASH_CFI_DRIVER=y diff --git a/include/configs/eb_cpu5282.h b/include/configs/eb_cpu5282.h index 26e4ade34ee..a4d1338c8fa 100644 --- a/include/configs/eb_cpu5282.h +++ b/include/configs/eb_cpu5282.h @@ -14,12 +14,6 @@
#define CFG_SYS_UART_PORT (0)
-/*----------------------------------------------------------------------* - * Options * - *----------------------------------------------------------------------*/ - -#define STATUS_LED_ACTIVE 0 - /*----------------------------------------------------------------------* * Configuration for environment * * Environment is in the second sector of the first 256k of flash *
On Sat, 2 Nov 2024 at 18:34, Simon Glass sjg@chromium.org wrote:
Drop this old code. Swtich the LED options to use the new approach, in the same commit, to maintain build-bisectability.
Both eb_cpu5282 and eb_cpu5282_internal are done together, since they share code.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Update commit message
Changes in v2:
- Combine code-removal and defconfig changes
board/BuS/eb_cpu5282/eb_cpu5282.c | 20 -------------------- configs/eb_cpu5282_defconfig | 8 ++------ configs/eb_cpu5282_internal_defconfig | 8 ++------ include/configs/eb_cpu5282.h | 6 ------ 4 files changed, 4 insertions(+), 38 deletions(-)
Applied to ci/master, thanks!
This is not used anymore, so drop it.
Enable LED and LED_BOOT instead, since this is the new way to access the LED functionality.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Combine removal and enable patches
board/softing/vining_fpga/socfpga.c | 4 ---- configs/socfpga_vining_fpga_defconfig | 13 ++----------- 2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/board/softing/vining_fpga/socfpga.c b/board/softing/vining_fpga/socfpga.c index ec2c7ea3631..700184cc575 100644 --- a/board/softing/vining_fpga/socfpga.c +++ b/board/softing/vining_fpga/socfpga.c @@ -8,7 +8,6 @@ #include <env.h> #include <init.h> #include <net.h> -#include <status_led.h> #include <asm/arch/reset_manager.h> #include <asm/global_data.h> #include <asm/io.h> @@ -26,9 +25,6 @@ int board_late_init(void) const unsigned int usb_nrst_gpio = 35; int ret;
- status_led_set(1, CONFIG_LED_STATUS_ON); - status_led_set(2, CONFIG_LED_STATUS_ON); - /* Address of boot parameters for ATAG (if ATAG is used) */ gd->bd->bi_boot_params = CFG_SYS_SDRAM_BASE + 0x100;
diff --git a/configs/socfpga_vining_fpga_defconfig b/configs/socfpga_vining_fpga_defconfig index 094e9186fca..94018752b40 100644 --- a/configs/socfpga_vining_fpga_defconfig +++ b/configs/socfpga_vining_fpga_defconfig @@ -77,17 +77,8 @@ CONFIG_SYS_DFU_DATA_BUF_SIZE=0x1000000 CONFIG_DWAPB_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_DW=y -CONFIG_LED_STATUS=y -CONFIG_LED_STATUS_GPIO=y -CONFIG_LED_STATUS0=y -CONFIG_LED_STATUS_BIT=48 -CONFIG_LED_STATUS1=y -CONFIG_LED_STATUS_BIT1=53 -CONFIG_LED_STATUS2=y -CONFIG_LED_STATUS_BIT2=54 -CONFIG_LED_STATUS3=y -CONFIG_LED_STATUS_BIT3=65 -CONFIG_LED_STATUS_CMD=y +CONFIG_LED=y +CONFIG_LED_BOOT=y CONFIG_MISC=y CONFIG_I2C_EEPROM=y CONFIG_SYS_I2C_EEPROM_ADDR=0x50
On Sat, 2 Nov 2024 at 18:34, Simon Glass sjg@chromium.org wrote:
This is not used anymore, so drop it.
Enable LED and LED_BOOT instead, since this is the new way to access the LED functionality.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Combine removal and enable patches
board/softing/vining_fpga/socfpga.c | 4 ---- configs/socfpga_vining_fpga_defconfig | 13 ++----------- 2 files changed, 2 insertions(+), 15 deletions(-)
Applied to ci/master, thanks!
Enable LED and LED_BOOT instead, since this is the new way to access the LED functionality.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Combine removal and enable patches
board/olimex/mx23_olinuxino/mx23_olinuxino.c | 7 ------- configs/mx23_olinuxino_defconfig | 10 ++-------- 2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/board/olimex/mx23_olinuxino/mx23_olinuxino.c b/board/olimex/mx23_olinuxino/mx23_olinuxino.c index b2bb6678c23..78136c1620a 100644 --- a/board/olimex/mx23_olinuxino/mx23_olinuxino.c +++ b/board/olimex/mx23_olinuxino/mx23_olinuxino.c @@ -13,9 +13,6 @@ #include <asm/arch/imx-regs.h> #include <asm/arch/clock.h> #include <asm/arch/sys_proto.h> -#ifdef CONFIG_LED_STATUS -#include <status_led.h> -#endif #include <linux/delay.h>
DECLARE_GLOBAL_DATA_PTR; @@ -61,9 +58,5 @@ int board_init(void) /* Adress of boot parameters */ gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
-#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOOT_ENABLE) - status_led_set(CONFIG_LED_STATUS_BOOT, CONFIG_LED_STATUS_STATE); -#endif - return 0; } diff --git a/configs/mx23_olinuxino_defconfig b/configs/mx23_olinuxino_defconfig index 3016f750e64..c1319077891 100644 --- a/configs/mx23_olinuxino_defconfig +++ b/configs/mx23_olinuxino_defconfig @@ -39,14 +39,8 @@ CONFIG_USE_BOOTFILE=y CONFIG_BOOTFILE="uImage" CONFIG_VERSION_VARIABLE=y CONFIG_MXS_GPIO=y -CONFIG_LED_STATUS=y -CONFIG_LED_STATUS_GPIO=y -CONFIG_LED_STATUS0=y -CONFIG_LED_STATUS_BIT=778 -CONFIG_LED_STATUS_STATE=2 -CONFIG_LED_STATUS_BOOT_ENABLE=y -CONFIG_LED_STATUS_BOOT=0 -CONFIG_LED_STATUS_CMD=y +CONFIG_LED=y +CONFIG_LED_BOOT=y CONFIG_MMC_MXS=y CONFIG_CONS_INDEX=0 CONFIG_DM_SERIAL=y
Drop the STATUS_LED options and enable LED and LED_BOOT instead, since this is the new way to access the LED functionality.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Combine removal and enable patches
Changes in v2: - Add a patch to enable LED and LED_BOOT for these boards
configs/pinephone_defconfig | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig index 9d39204a439..272fce1c1a4 100644 --- a/configs/pinephone_defconfig +++ b/configs/pinephone_defconfig @@ -11,8 +11,5 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=2 CONFIG_PINEPHONE_DT_SELECTION=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2" -CONFIG_LED_STATUS=y -CONFIG_LED_STATUS_GPIO=y -CONFIG_LED_STATUS0=y -CONFIG_LED_STATUS_BIT=114 -CONFIG_LED_STATUS_STATE=2 +CONFIG_LED=y +CONFIG_LED_BOOT=y
On Sat, Nov 02, 2024 at 06:32:56PM -0600, Simon Glass wrote:
Drop the STATUS_LED options and enable LED and LED_BOOT instead, since this is the new way to access the LED functionality.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Combine removal and enable patches
Changes in v2:
- Add a patch to enable LED and LED_BOOT for these boards
configs/pinephone_defconfig | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig index 9d39204a439..272fce1c1a4 100644 --- a/configs/pinephone_defconfig +++ b/configs/pinephone_defconfig @@ -11,8 +11,5 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=2 CONFIG_PINEPHONE_DT_SELECTION=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2" -CONFIG_LED_STATUS=y -CONFIG_LED_STATUS_GPIO=y -CONFIG_LED_STATUS0=y -CONFIG_LED_STATUS_BIT=114 -CONFIG_LED_STATUS_STATE=2 +CONFIG_LED=y +CONFIG_LED_BOOT=y
Adding more people to the email. Where this really got stuck last posting was that Peter couldn't convert the board functionally and there wasn't enough documentation about the new way to be clear on how to implement it. I'm hoping Christian can chime in on the latter part.
On Sun, 3 Nov 2024 at 00:42, Simon Glass sjg@chromium.org wrote:
Drop the STATUS_LED options and enable LED and LED_BOOT instead, since this is the new way to access the LED functionality.
This still doesn't work!
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Combine removal and enable patches
Changes in v2:
- Add a patch to enable LED and LED_BOOT for these boards
configs/pinephone_defconfig | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig index 9d39204a439..272fce1c1a4 100644 --- a/configs/pinephone_defconfig +++ b/configs/pinephone_defconfig @@ -11,8 +11,5 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=2 CONFIG_PINEPHONE_DT_SELECTION=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2" -CONFIG_LED_STATUS=y -CONFIG_LED_STATUS_GPIO=y -CONFIG_LED_STATUS0=y -CONFIG_LED_STATUS_BIT=114 -CONFIG_LED_STATUS_STATE=2 +CONFIG_LED=y
+CONFIG_LED_BOOT=y
2.43.0
On Tue, 5 Nov 2024 at 07:13, Peter Robinson pbrobinson@gmail.com wrote:
On Sun, 3 Nov 2024 at 00:42, Simon Glass sjg@chromium.org wrote:
Drop the STATUS_LED options and enable LED and LED_BOOT instead, since this is the new way to access the LED functionality.
This still doesn't work!
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Combine removal and enable patches
Changes in v2:
- Add a patch to enable LED and LED_BOOT for these boards
configs/pinephone_defconfig | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig index 9d39204a439..272fce1c1a4 100644 --- a/configs/pinephone_defconfig +++ b/configs/pinephone_defconfig @@ -11,8 +11,5 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=2 CONFIG_PINEPHONE_DT_SELECTION=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2" -CONFIG_LED_STATUS=y -CONFIG_LED_STATUS_GPIO=y -CONFIG_LED_STATUS0=y -CONFIG_LED_STATUS_BIT=114 -CONFIG_LED_STATUS_STATE=2 +CONFIG_LED=y
+CONFIG_LED_BOOT=y
2.43.0
Applied to ci/master, thanks!
Hi Peter,
On Tue, 5 Nov 2024 at 07:13, Peter Robinson pbrobinson@gmail.com wrote:
On Sun, 3 Nov 2024 at 00:42, Simon Glass sjg@chromium.org wrote:
Drop the STATUS_LED options and enable LED and LED_BOOT instead, since this is the new way to access the LED functionality.
This still doesn't work!
Could you try this series please?
https://patchwork.ozlabs.org/project/uboot/list/?series=432093
Regards, Simon
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Combine removal and enable patches
Changes in v2:
- Add a patch to enable LED and LED_BOOT for these boards
configs/pinephone_defconfig | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig index 9d39204a439..272fce1c1a4 100644 --- a/configs/pinephone_defconfig +++ b/configs/pinephone_defconfig @@ -11,8 +11,5 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=2 CONFIG_PINEPHONE_DT_SELECTION=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2" -CONFIG_LED_STATUS=y -CONFIG_LED_STATUS_GPIO=y -CONFIG_LED_STATUS0=y -CONFIG_LED_STATUS_BIT=114 -CONFIG_LED_STATUS_STATE=2 +CONFIG_LED=y
+CONFIG_LED_BOOT=y
2.43.0
This is not used by any board and there is a driver model version of LEDs. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
cmd/legacy_led.c | 40 ---------------------------------------- drivers/led/Kconfig | 6 ------ include/status_led.h | 13 +------------ 3 files changed, 1 insertion(+), 58 deletions(-)
diff --git a/cmd/legacy_led.c b/cmd/legacy_led.c index 50de7e89d8f..ef2135e0dba 100644 --- a/cmd/legacy_led.c +++ b/cmd/legacy_led.c @@ -24,26 +24,6 @@ struct led_tbl_s { typedef struct led_tbl_s led_tbl_t;
static const led_tbl_t led_commands[] = { -#ifdef CONFIG_LED_STATUS_BOARD_SPECIFIC -#ifdef CONFIG_LED_STATUS0 - { "0", CONFIG_LED_STATUS_BIT, NULL, NULL, NULL }, -#endif -#ifdef CONFIG_LED_STATUS1 - { "1", CONFIG_LED_STATUS_BIT1, NULL, NULL, NULL }, -#endif -#ifdef CONFIG_LED_STATUS2 - { "2", CONFIG_LED_STATUS_BIT2, NULL, NULL, NULL }, -#endif -#ifdef CONFIG_LED_STATUS3 - { "3", CONFIG_LED_STATUS_BIT3, NULL, NULL, NULL }, -#endif -#ifdef CONFIG_LED_STATUS4 - { "4", CONFIG_LED_STATUS_BIT4, NULL, NULL, NULL }, -#endif -#ifdef CONFIG_LED_STATUS5 - { "5", CONFIG_LED_STATUS_BIT5, NULL, NULL, NULL }, -#endif -#endif #ifdef CONFIG_LED_STATUS_GREEN { "green", CONFIG_LED_STATUS_GREEN, green_led_off, green_led_on, NULL }, #endif @@ -148,26 +128,6 @@ int do_legacy_led(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) U_BOOT_CMD( led, 4, 1, do_legacy_led, "[" -#ifdef CONFIG_LED_STATUS_BOARD_SPECIFIC -#ifdef CONFIG_LED_STATUS0 - "0|" -#endif -#ifdef CONFIG_LED_STATUS1 - "1|" -#endif -#ifdef CONFIG_LED_STATUS2 - "2|" -#endif -#ifdef CONFIG_LED_STATUS3 - "3|" -#endif -#ifdef CONFIG_LED_STATUS4 - "4|" -#endif -#ifdef CONFIG_LED_STATUS5 - "5|" -#endif -#endif #ifdef CONFIG_LED_STATUS_GREEN "green|" #endif diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig index c98cbf92fab..268118a6c3a 100644 --- a/drivers/led/Kconfig +++ b/drivers/led/Kconfig @@ -166,12 +166,6 @@ config LED_STATUS_GPIO The status LED can be connected to a GPIO pin. In such cases, the gpio_led driver can be used as a status LED backend implementation.
-config LED_STATUS_BOARD_SPECIFIC - bool "Specific board" - default y - help - LED support is only for a specific board. - comment "LEDs parameters"
config LED_STATUS0 diff --git a/include/status_led.h b/include/status_led.h index 1282022253e..59cf9f89956 100644 --- a/include/status_led.h +++ b/include/status_led.h @@ -61,23 +61,12 @@ static inline void status_led_boot_blink(void) * ADVICE: Define in your board configuration file rather than * filling this file up with lots of custom board stuff. */ - -#elif defined(CONFIG_LED_STATUS_BOARD_SPECIFIC) -/* led_id_t is unsigned long mask */ -typedef unsigned long led_id_t; - -extern void __led_toggle (led_id_t mask); -extern void __led_init (led_id_t mask, int state); -extern void __led_set (led_id_t mask, int state); -void __led_blink(led_id_t mask, int freq); #else # error Status LED configuration missing #endif /************************************************************************/
-#ifndef CONFIG_LED_STATUS_BOARD_SPECIFIC -# include <asm/status_led.h> -#endif +#include <asm/status_led.h>
#else
On Sat, 2 Nov 2024 at 18:35, Simon Glass sjg@chromium.org wrote:
This is not used by any board and there is a driver model version of LEDs. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
cmd/legacy_led.c | 40 ---------------------------------------- drivers/led/Kconfig | 6 ------ include/status_led.h | 13 +------------ 3 files changed, 1 insertion(+), 58 deletions(-)
Applied to ci/master, thanks!
On Tue, 3 Dec 2024 at 19:48, Simon Glass sjg@chromium.org wrote:
On Sat, 2 Nov 2024 at 18:35, Simon Glass sjg@chromium.org wrote:
This is not used by any board and there is a driver model version of LEDs. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
cmd/legacy_led.c | 40 ---------------------------------------- drivers/led/Kconfig | 6 ------ include/status_led.h | 13 +------------ 3 files changed, 1 insertion(+), 58 deletions(-)
Applied to ci/master, thanks!
Why is this being applied via a ci branch? I don't think that is appropriate!!!
This has been replaced with a new LED framework, so drop this old code.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/arm/lib/crt0.S | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 3e4906e273d..a691d844847 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -185,10 +185,6 @@ here: movne r9, r0 # endif
-#if ! defined(CONFIG_XPL_BUILD) - bl coloured_LED_init - bl red_led_on -#endif /* call board_init_r(gd_t *id, ulong dest_addr) */ mov r0, r9 /* gd_t */ ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */
On Sat, 2 Nov 2024 at 18:35, Simon Glass sjg@chromium.org wrote:
This has been replaced with a new LED framework, so drop this old code.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
arch/arm/lib/crt0.S | 4 ---- 1 file changed, 4 deletions(-)
Applied to ci/master, thanks!
This has been replaced with a new LED framework, so drop this old code and documentation.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
common/board_f.c | 22 -------------- doc/README.LED | 77 ------------------------------------------------ 2 files changed, 99 deletions(-) delete mode 100644 doc/README.LED
diff --git a/common/board_f.c b/common/board_f.c index 98dc2591e1d..b110a15278b 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -36,7 +36,6 @@ #include <relocate.h> #include <serial.h> #include <spl.h> -#include <status_led.h> #include <sysreset.h> #include <timer.h> #include <trace.h> @@ -53,27 +52,6 @@
DECLARE_GLOBAL_DATA_PTR;
-/* - * TODO(sjg@chromium.org): IMO this code should be - * refactored to a single function, something like: - * - * void led_set_state(enum led_colour_t colour, int on); - */ -/************************************************************************ - * Coloured LED functionality - ************************************************************************ - * May be supplied by boards if desired - */ -__weak void coloured_LED_init(void) {} -__weak void red_led_on(void) {} -__weak void red_led_off(void) {} -__weak void green_led_on(void) {} -__weak void green_led_off(void) {} -__weak void yellow_led_on(void) {} -__weak void yellow_led_off(void) {} -__weak void blue_led_on(void) {} -__weak void blue_led_off(void) {} - /* * Why is gd allocated a register? Prior to reloc it might be better to * just pass it around to each function in this file? 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<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
This predates the LED framework, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
board/st/stm32f429-discovery/Makefile | 1 - board/st/stm32f429-discovery/led.c | 39 --------------------------- 2 files changed, 40 deletions(-) delete mode 100644 board/st/stm32f429-discovery/led.c
diff --git a/board/st/stm32f429-discovery/Makefile b/board/st/stm32f429-discovery/Makefile index 6b02c0fddec..233eafdad3d 100644 --- a/board/st/stm32f429-discovery/Makefile +++ b/board/st/stm32f429-discovery/Makefile @@ -7,4 +7,3 @@ # Kamil Lulko, kamil.lulko@gmail.com
obj-y := stm32f429-discovery.o -obj-y += led.o diff --git a/board/st/stm32f429-discovery/led.c b/board/st/stm32f429-discovery/led.c deleted file mode 100644 index 4b8038341b9..00000000000 --- a/board/st/stm32f429-discovery/led.c +++ /dev/null @@ -1,39 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0+ -/* - * (C) Copyright 2015 - * Kamil Lulko, kamil.lulko@gmail.com - */ - -#include <status_led.h> -#include <asm-generic/gpio.h> - -#define RED_LED 110 -#define GREEN_LED 109 - -void coloured_LED_init(void) -{ - gpio_request(RED_LED, "red led"); - gpio_direction_output(RED_LED, 0); - gpio_request(GREEN_LED, "green led"); - gpio_direction_output(GREEN_LED, 0); -} - -void red_led_off(void) -{ - gpio_set_value(RED_LED, 0); -} - -void green_led_off(void) -{ - gpio_set_value(GREEN_LED, 0); -} - -void red_led_on(void) -{ - gpio_set_value(RED_LED, 1); -} - -void green_led_on(void) -{ - gpio_set_value(GREEN_LED, 1); -}
On 11/3/24 01:33, Simon Glass wrote:
This predates the LED framework, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
board/st/stm32f429-discovery/Makefile | 1 - board/st/stm32f429-discovery/led.c | 39 --------------------------- 2 files changed, 40 deletions(-) delete mode 100644 board/st/stm32f429-discovery/led.c
diff --git a/board/st/stm32f429-discovery/Makefile b/board/st/stm32f429-discovery/Makefile index 6b02c0fddec..233eafdad3d 100644 --- a/board/st/stm32f429-discovery/Makefile +++ b/board/st/stm32f429-discovery/Makefile @@ -7,4 +7,3 @@ # Kamil Lulko, kamil.lulko@gmail.com
obj-y := stm32f429-discovery.o -obj-y += led.o diff --git a/board/st/stm32f429-discovery/led.c b/board/st/stm32f429-discovery/led.c deleted file mode 100644 index 4b8038341b9..00000000000 --- a/board/st/stm32f429-discovery/led.c +++ /dev/null @@ -1,39 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0+ -/*
- (C) Copyright 2015
- Kamil Lulko, kamil.lulko@gmail.com
- */
-#include <status_led.h> -#include <asm-generic/gpio.h>
-#define RED_LED 110 -#define GREEN_LED 109
-void coloured_LED_init(void) -{
- gpio_request(RED_LED, "red led");
- gpio_direction_output(RED_LED, 0);
- gpio_request(GREEN_LED, "green led");
- gpio_direction_output(GREEN_LED, 0);
-}
-void red_led_off(void) -{
- gpio_set_value(RED_LED, 0);
-}
-void green_led_off(void) -{
- gpio_set_value(GREEN_LED, 0);
-}
-void red_led_on(void) -{
- gpio_set_value(RED_LED, 1);
-}
-void green_led_on(void) -{
- gpio_set_value(GREEN_LED, 1);
-}
Reviewed-by: Patrice Chotard patrice.chotard@foss.st.com
Thanks
Use an if...endif construct to avoid needing to make everything depend on LED. Make SPL_LED depend on LED since that seems reasonable.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/led/Kconfig | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig index 268118a6c3a..789113a92b5 100644 --- a/drivers/led/Kconfig +++ b/drivers/led/Kconfig @@ -9,6 +9,8 @@ config LED can provide access to board-specific LEDs. Use of the device tree for configuration is encouraged.
+if LED + config LED_BOOT bool "Enable LED boot support" help @@ -35,7 +37,7 @@ config LED_ACTIVITY
config LED_BCM6328 bool "LED Support for BCM6328" - depends on LED && ARCH_BMIPS + depends on ARCH_BMIPS help This option enables support for LEDs connected to the BCM6328 LED HW controller accessed via MMIO registers. @@ -46,7 +48,7 @@ config LED_BCM6328
config LED_BCM6358 bool "LED Support for BCM6358" - depends on LED && ARCH_BMIPS + depends on ARCH_BMIPS help This option enables support for LEDs connected to the BCM6358 LED HW controller accessed via MMIO registers. @@ -54,28 +56,28 @@ config LED_BCM6358
config LED_BCM6753 bool "LED Support for BCM6753" - depends on LED && BCM6855 + depends on BCM6855 help This option enables support for LEDs connected to the BCM6753 HW has blinking and fading capabilities and up to 32 LEDs can be controlled.
config LED_BCM6858 bool "LED Support for BCM6858" - depends on LED && (BCM6856 || BCM6858 || BCM63158) + depends on BCM6856 || BCM6858 || BCM63158 help This option enables support for LEDs connected to the BCM6858 HW has blinking capabilities and up to 32 LEDs can be controlled.
config LED_CORTINA bool "LED Support for Cortina Access CAxxxx SoCs" - depends on LED && (CORTINA_PLATFORM) + depends on CORTINA_PLATFORM help This option enables support for LEDs connected to the Cortina Access CAxxxx SOCs.
config LED_LP5562 bool "LED Support for LP5562" - depends on LED && DM_I2C + depends on DM_I2C help This option enables support for LEDs connected to the TI LP5562 4 channel I2C LED controller. Driver fully supports blink on the @@ -83,14 +85,13 @@ config LED_LP5562
config LED_PWM bool "LED PWM" - depends on LED && DM_PWM + depends on DM_PWM help Enable support for LEDs connected to PWM. Linux compatible ofdata.
config LED_BLINK bool "Support hardware LED blinking" - depends on LED help Some drivers can support automatic blinking of LEDs with a given period, without needing timers or extra code to handle the timing. @@ -99,7 +100,6 @@ config LED_BLINK
config LED_SW_BLINK bool "Support software LED blinking" - depends on LED select CYCLIC help Turns on led blinking implemented in the software, useful when @@ -122,7 +122,7 @@ config SPL_LED
config LED_GPIO bool "LED support for GPIO-connected LEDs" - depends on LED && DM_GPIO + depends on DM_GPIO help Enable support for LEDs which are connected to GPIO lines. These GPIOs may be on the SoC or some other device which provides GPIOs. @@ -136,6 +136,8 @@ config SPL_LED_GPIO This option is an SPL-variant of the LED_GPIO option. See the help of LED_GPIO for details.
+endif # LED + config LED_STATUS bool "Enable status LED API" help
Drop all of these configs, which are now unused.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/led/Kconfig | 316 -------------------------------------------- 1 file changed, 316 deletions(-)
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig index 789113a92b5..379b3ce49a5 100644 --- a/drivers/led/Kconfig +++ b/drivers/led/Kconfig @@ -138,320 +138,4 @@ config SPL_LED_GPIO
endif # LED
-config LED_STATUS - bool "Enable status LED API" - help - Allows common u-boot commands to use a board's leds to - provide status for activities like booting and downloading files. - -if LED_STATUS - -# Hidden constants - -config LED_STATUS_OFF - int - default 0 - -config LED_STATUS_BLINKING - int - default 1 - -config LED_STATUS_ON - int - default 2 - -# Hidden constants end - -config LED_STATUS_GPIO - bool "GPIO status LED implementation" - help - The status LED can be connected to a GPIO pin. In such cases, the - gpio_led driver can be used as a status LED backend implementation. - -comment "LEDs parameters" - -config LED_STATUS0 - bool "Enable status LED 0" - -if LED_STATUS0 - -config LED_STATUS_BIT - int "identification" - help - CONFIG_LED_STATUS_BIT is passed into the __led_* functions to identify - which LED is being acted on. As such, the chosen value must be unique - with respect to the other CONFIG_LED_STATUS_BIT's. Mapping the value - to a physical LED is the responsibility of the __led_* function. - -config LED_STATUS_STATE - int "initial state" - range LED_STATUS_OFF LED_STATUS_ON - default LED_STATUS_OFF - help - Should be set one of the following: - 0 - off - 1 - blinking - 2 - on - -config LED_STATUS_FREQ - int "blink frequency" - range 2 10 - default 2 - help - The LED blink period calculated from LED_STATUS_FREQ: - LED_STATUS_PERIOD = CONFIG_SYS_HZ/LED_STATUS_FREQ - Values range: 2 - 10 - -endif # LED_STATUS0 - -config LED_STATUS1 - bool "Enable status LED 1" - -if LED_STATUS1 - -config LED_STATUS_BIT1 - int "identification" - help - CONFIG_LED_STATUS_BIT1 is passed into the __led_* functions to - identify which LED is being acted on. As such, the chosen value must - be unique with respect to the other CONFIG_LED_STATUS_BIT's. Mapping - the value to a physical LED is the responsibility of the __led_* - function. - -config LED_STATUS_STATE1 - int "initial state" - range LED_STATUS_OFF LED_STATUS_ON - default LED_STATUS_OFF - help - Should be set one of the following: - 0 - off - 1 - blinking - 2 - on - -config LED_STATUS_FREQ1 - int "blink frequency" - range 2 10 - default 2 - help - The LED blink period calculated from LED_STATUS_FREQ1: - LED_STATUS_PERIOD1 = CONFIG_SYS_HZ/LED_STATUS_FREQ1 - Values range: 2 - 10 - -endif # LED_STATUS1 - -config LED_STATUS2 - bool "Enable status LED 2" - -if LED_STATUS2 - -config LED_STATUS_BIT2 - int "identification" - help - CONFIG_LED_STATUS_BIT2 is passed into the __led_* functions to - identify which LED is being acted on. As such, the chosen value must - be unique with respect to the other CONFIG_LED_STATUS_BIT's. Mapping - the value to a physical LED is the responsibility of the __led_* - function. - -config LED_STATUS_STATE2 - int "initial state" - range LED_STATUS_OFF LED_STATUS_ON - default LED_STATUS_OFF - help - Should be set one of the following: - 0 - off - 1 - blinking - 2 - on - -config LED_STATUS_FREQ2 - int "blink frequency" - range 2 10 - default 2 - help - The LED blink period calculated from LED_STATUS_FREQ2: - LED_STATUS_PERIOD2 = CONFIG_SYS_HZ/LED_STATUS_FREQ2 - Values range: 2 - 10 - -endif # LED_STATUS2 - -config LED_STATUS3 - bool "Enable status LED 3" - -if LED_STATUS3 - -config LED_STATUS_BIT3 - int "identification" - help - CONFIG_LED_STATUS_BIT3 is passed into the __led_* functions to - identify which LED is being acted on. As such, the chosen value must - be unique with respect to the other CONFIG_LED_STATUS_BIT's. Mapping - the value to a physical LED is the responsibility of the __led_* - function. - -config LED_STATUS_STATE3 - int "initial state" - range LED_STATUS_OFF LED_STATUS_ON - default LED_STATUS_OFF - help - Should be set one of the following: - 0 - off - 1 - blinking - 2 - on - -config LED_STATUS_FREQ3 - int "blink frequency" - range 2 10 - default 2 - help - The LED blink period calculated from LED_STATUS_FREQ3: - LED_STATUS_PERIOD3 = CONFIG_SYS_HZ/LED_STATUS_FREQ3 - Values range: 2 - 10 - -endif # LED_STATUS3 - -config LED_STATUS4 - bool "Enable status LED 4" - -if LED_STATUS4 - -config LED_STATUS_BIT4 - int "identification" - help - CONFIG_LED_STATUS_BIT4 is passed into the __led_* functions to - identify which LED is being acted on. As such, the chosen value must - be unique with respect to the other CONFIG_LED_STATUS_BIT's. Mapping - the value to a physical LED is the responsibility of the __led_* - function. - -config LED_STATUS_STATE4 - int "initial state" - range LED_STATUS_OFF LED_STATUS_ON - default LED_STATUS_OFF - help - Should be set one of the following: - 0 - off - 1 - blinking - 2 - on - -config LED_STATUS_FREQ4 - int "blink frequency" - range 2 10 - default 2 - help - The LED blink period calculated from LED_STATUS_FREQ4: - LED_STATUS_PERIOD4 = CONFIG_SYS_HZ/LED_STATUS_FREQ4 - Values range: 2 - 10 - -endif # LED_STATUS4 - -config LED_STATUS5 - bool "Enable status LED 5" - -if LED_STATUS5 - -config LED_STATUS_BIT5 - int "identification" - help - CONFIG_LED_STATUS_BIT5 is passed into the __led_* functions to - identify which LED is being acted on. As such, the chosen value must - be unique with respect to the other CONFIG_LED_STATUS_BIT's. Mapping - the value to a physical LED is the responsibility of the __led_* - function. - -config LED_STATUS_STATE5 - int "initial state" - range LED_STATUS_OFF LED_STATUS_ON - default LED_STATUS_OFF - help - Should be set one of the following: - 0 - off - 1 - blinking - 2 - on - -config LED_STATUS_FREQ5 - int "blink frequency" - range 2 10 - default 2 - help - The LED blink period calculated from LED_STATUS_FREQ5: - LED_STATUS_PERIOD5 = CONFIG_SYS_HZ/LED_STATUS_FREQ5 - Values range: 2 - 10 - -endif # LED_STATUS5 - -config LED_STATUS_BOOT_ENABLE - bool "Enable BOOT LED" - help - Enable to turn an LED on when the board is booting. - -if LED_STATUS_BOOT_ENABLE - -config LED_STATUS_BOOT - int "LED to light when the board is booting" - help - Valid enabled LED device number. - -endif # LED_STATUS_BOOT_ENABLE - -config LED_STATUS_RED_ENABLE - bool "Enable red LED" - help - Enable red status LED. - -if LED_STATUS_RED_ENABLE - -config LED_STATUS_RED - int "Red LED identification" - help - Valid enabled LED device number. - -endif # LED_STATUS_RED_ENABLE - -config LED_STATUS_YELLOW_ENABLE - bool "Enable yellow LED" - help - Enable yellow status LED. - -if LED_STATUS_YELLOW_ENABLE - -config LED_STATUS_YELLOW - int "Yellow LED identification" - help - Valid enabled LED device number. - -endif # LED_STATUS_YELLOW_ENABLE - -config LED_STATUS_BLUE_ENABLE - bool "Enable blue LED" - help - Enable blue status LED. - -if LED_STATUS_BLUE_ENABLE - -config LED_STATUS_BLUE - int "Blue LED identification" - help - Valid enabled LED device number. - -endif # LED_STATUS_BLUE_ENABLE - -config LED_STATUS_GREEN_ENABLE - bool "Enable green LED" - help - Enable green status LED. - -if LED_STATUS_GREEN_ENABLE - -config LED_STATUS_GREEN - int "Green LED identification" - help - Valid enabled LED device number (0-5). - -endif # LED_STATUS_GREEN_ENABLE - -config LED_STATUS_CMD - bool "Enable status LED commands" - -endif # LED_STATUS - endmenu
This is not used by any board. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
cmd/Makefile | 1 - cmd/legacy_led.c | 145 ----------------------------------------------- 2 files changed, 146 deletions(-) delete mode 100644 cmd/legacy_led.c
diff --git a/cmd/Makefile b/cmd/Makefile index d1f369deec0..6052c1dd096 100644 --- a/cmd/Makefile +++ b/cmd/Makefile @@ -101,7 +101,6 @@ obj-$(CONFIG_CMD_IRQ) += irq.o obj-$(CONFIG_CMD_ITEST) += itest.o obj-$(CONFIG_CMD_JFFS2) += jffs2.o obj-$(CONFIG_CMD_CRAMFS) += cramfs.o -obj-$(CONFIG_LED_STATUS_CMD) += legacy_led.o obj-$(CONFIG_CMD_LED) += led.o obj-$(CONFIG_CMD_LICENSE) += license.o obj-y += load.o diff --git a/cmd/legacy_led.c b/cmd/legacy_led.c deleted file mode 100644 index ef2135e0dba..00000000000 --- a/cmd/legacy_led.c +++ /dev/null @@ -1,145 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0+ -/* - * (C) Copyright 2010 - * Jason Kridner jkridner@beagleboard.org - * - * Based on cmd_led.c patch from: - * http://www.mail-archive.com/u-boot@lists.denx.de/msg06873.html - * (C) Copyright 2008 - * Ulf Samuelsson ulf.samuelsson@atmel.com - */ - -#include <command.h> -#include <status_led.h> -#include <vsprintf.h> - -struct led_tbl_s { - char *string; /* String for use in the command */ - led_id_t mask; /* Mask used for calling __led_set() */ - void (*off)(void); /* Optional function for turning LED off */ - void (*on)(void); /* Optional function for turning LED on */ - void (*toggle)(void);/* Optional function for toggling LED */ -}; - -typedef struct led_tbl_s led_tbl_t; - -static const led_tbl_t led_commands[] = { -#ifdef CONFIG_LED_STATUS_GREEN - { "green", CONFIG_LED_STATUS_GREEN, green_led_off, green_led_on, NULL }, -#endif -#ifdef CONFIG_LED_STATUS_YELLOW - { "yellow", CONFIG_LED_STATUS_YELLOW, yellow_led_off, yellow_led_on, - NULL }, -#endif -#ifdef CONFIG_LED_STATUS_RED - { "red", CONFIG_LED_STATUS_RED, red_led_off, red_led_on, NULL }, -#endif -#ifdef CONFIG_LED_STATUS_BLUE - { "blue", CONFIG_LED_STATUS_BLUE, blue_led_off, blue_led_on, NULL }, -#endif - { NULL, 0, NULL, NULL, NULL } -}; - -enum led_cmd { LED_ON, LED_OFF, LED_TOGGLE, LED_BLINK }; - -enum led_cmd get_led_cmd(char *var) -{ - if (strcmp(var, "off") == 0) - return LED_OFF; - if (strcmp(var, "on") == 0) - return LED_ON; - if (strcmp(var, "toggle") == 0) - return LED_TOGGLE; - if (strcmp(var, "blink") == 0) - return LED_BLINK; - - return -1; -} - -/* - * LED drivers providing a blinking LED functionality, like the - * PCA9551, can override this empty weak function - */ -void __weak __led_blink(led_id_t mask, int freq) -{ -} - -int do_legacy_led(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) -{ - int i, match = 0; - enum led_cmd cmd; - int freq; - - /* Validate arguments */ - if ((argc < 3) || (argc > 4)) - return CMD_RET_USAGE; - - cmd = get_led_cmd(argv[2]); - if (cmd < 0) { - return CMD_RET_USAGE; - } - - for (i = 0; led_commands[i].string; i++) { - if ((strcmp("all", argv[1]) == 0) || - (strcmp(led_commands[i].string, argv[1]) == 0)) { - match = 1; - switch (cmd) { - case LED_ON: - if (led_commands[i].on) - led_commands[i].on(); - else - __led_set(led_commands[i].mask, - CONFIG_LED_STATUS_ON); - break; - case LED_OFF: - if (led_commands[i].off) - led_commands[i].off(); - else - __led_set(led_commands[i].mask, - CONFIG_LED_STATUS_OFF); - break; - case LED_TOGGLE: - if (led_commands[i].toggle) - led_commands[i].toggle(); - else - __led_toggle(led_commands[i].mask); - break; - case LED_BLINK: - if (argc != 4) - return CMD_RET_USAGE; - - freq = dectoul(argv[3], NULL); - __led_blink(led_commands[i].mask, freq); - } - /* Need to set only 1 led if led_name wasn't 'all' */ - if (strcmp("all", argv[1]) != 0) - break; - } - } - - /* If we ran out of matches, print Usage */ - if (!match) { - return CMD_RET_USAGE; - } - - return 0; -} - -U_BOOT_CMD( - led, 4, 1, do_legacy_led, - "[" -#ifdef CONFIG_LED_STATUS_GREEN - "green|" -#endif -#ifdef CONFIG_LED_STATUS_YELLOW - "yellow|" -#endif -#ifdef CONFIG_LED_STATUS_RED - "red|" -#endif -#ifdef CONFIG_LED_STATUS_BLUE - "blue|" -#endif - "all] [on|off|toggle|blink] [blink-freq in ms]", - "[led_name] [on|off|toggle|blink] sets or clears led(s)" -);
This is not used by any board. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
cmd/Makefile | 1 - cmd/legacy_led.c | 145 ----------------------------------------------- 2 files changed, 146 deletions(-) delete mode 100644 cmd/legacy_led.c
Applied to ci/master, thanks!
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/misc/Makefile | 1 - drivers/misc/gpio_led.c | 106 ---------------------------------------- 2 files changed, 107 deletions(-) delete mode 100644 drivers/misc/gpio_led.c
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index dac805e4cdd..b7332587faa 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -49,7 +49,6 @@ obj-$(CONFIG_IHS_FPGA) += ihs_fpga.o obj-$(CONFIG_IMX8) += imx8/ obj-$(CONFIG_IMX_ELE) += imx_ele/ obj-$(CONFIG_LED_STATUS) += status_led.o -obj-$(CONFIG_LED_STATUS_GPIO) += gpio_led.o obj-$(CONFIG_MPC83XX_SERDES) += mpc83xx_serdes.o obj-$(CONFIG_$(PHASE_)LS2_SFP) += ls2_sfp.o obj-$(CONFIG_$(XPL_)MXC_OCOTP) += mxc_ocotp.o diff --git a/drivers/misc/gpio_led.c b/drivers/misc/gpio_led.c deleted file mode 100644 index e63689967a7..00000000000 --- a/drivers/misc/gpio_led.c +++ /dev/null @@ -1,106 +0,0 @@ -/* - * Status LED driver based on GPIO access conventions of Linux - * - * Copyright (C) 2010 Thomas Chou thomas@wytron.com.tw - * Licensed under the GPL-2 or later. - */ - -#include <status_led.h> -#include <asm/gpio.h> - -#ifndef CFG_GPIO_LED_INVERTED_TABLE -#define CFG_GPIO_LED_INVERTED_TABLE {} -#endif - -static led_id_t gpio_led_inv[] = CFG_GPIO_LED_INVERTED_TABLE; - -static int gpio_led_gpio_value(led_id_t mask, int state) -{ - int i, gpio_value = (state == CONFIG_LED_STATUS_ON); - - for (i = 0; i < ARRAY_SIZE(gpio_led_inv); i++) { - if (gpio_led_inv[i] == mask) - gpio_value = !gpio_value; - } - - return gpio_value; -} - -void __led_init(led_id_t mask, int state) -{ - int gpio_value; - - if (gpio_request(mask, "gpio_led") != 0) { - printf("%s: failed requesting GPIO%lu!\n", __func__, mask); - return; - } - - gpio_value = gpio_led_gpio_value(mask, state); - gpio_direction_output(mask, gpio_value); -} - -void __led_set(led_id_t mask, int state) -{ - int gpio_value = gpio_led_gpio_value(mask, state); - - gpio_set_value(mask, gpio_value); -} - -void __led_toggle(led_id_t mask) -{ - gpio_set_value(mask, !gpio_get_value(mask)); -} - -#ifdef CONFIG_GPIO_LED_STUBS - -/* 'generic' override of colored LED stubs, to use GPIO functions instead */ - -#ifdef CONFIG_LED_STATUS_RED -void red_led_on(void) -{ - __led_set(CONFIG_LED_STATUS_RED, CONFIG_LED_STATUS_ON); -} - -void red_led_off(void) -{ - __led_set(CONFIG_LED_STATUS_RED, CONFIG_LED_STATUS_OFF); -} -#endif - -#ifdef CONFIG_LED_STATUS_GREEN -void green_led_on(void) -{ - __led_set(CONFIG_LED_STATUS_GREEN, CONFIG_LED_STATUS_ON); -} - -void green_led_off(void) -{ - __led_set(CONFIG_LED_STATUS_GREEN, CONFIG_LED_STATUS_OFF); -} -#endif - -#ifdef CONFIG_LED_STATUS_YELLOW -void yellow_led_on(void) -{ - __led_set(CONFIG_LED_STATUS_YELLOW, CONFIG_LED_STATUS_ON); -} - -void yellow_led_off(void) -{ - __led_set(CONFIG_LED_STATUS_YELLOW, CONFIG_LED_STATUS_OFF); -} -#endif - -#ifdef CONFIG_LED_STATUS_BLUE -void blue_led_on(void) -{ - __led_set(CONFIG_LED_STATUS_BLUE, CONFIG_LED_STATUS_ON); -} - -void blue_led_off(void) -{ - __led_set(CONFIG_LED_STATUS_BLUE, CONFIG_LED_STATUS_OFF); -} -#endif - -#endif /* CONFIG_GPIO_LED_STUBS */
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/misc/Makefile | 1 - drivers/misc/gpio_led.c | 106 ---------------------------------------- 2 files changed, 107 deletions(-) delete mode 100644 drivers/misc/gpio_led.c
Applied to ci/master, thanks!
This driver is not used anymore. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/misc/Kconfig | 13 --- drivers/misc/Makefile | 1 - drivers/misc/pca9551_led.c | 170 ------------------------------------- 3 files changed, 184 deletions(-) delete mode 100644 drivers/misc/pca9551_led.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 6009d55f400..23eb509d974 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -446,19 +446,6 @@ config SPL_PWRSEQ device. When the device is started up, its power sequence can be initiated.
-config PCA9551_LED - bool "Enable PCA9551 LED driver" - help - Enable driver for PCA9551 LED controller. This controller - is connected via I2C. So I2C needs to be enabled. - -config PCA9551_I2C_ADDR - hex "I2C address of PCA9551 LED controller" - depends on PCA9551_LED - default 0x60 - help - The I2C address of the PCA9551 LED controller. - config STM32MP_FUSE bool "Enable STM32MP fuse wrapper providing the fuse API" depends on ARCH_STM32MP && MISC diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index b7332587faa..e8f48228084 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -57,7 +57,6 @@ obj-$(CONFIG_NPCM_OTP) += npcm_otp.o obj-$(CONFIG_NPCM_HOST) += npcm_host_intf.o obj-$(CONFIG_NUVOTON_NCT6102D) += nuvoton_nct6102d.o obj-$(CONFIG_P2SB) += p2sb-uclass.o -obj-$(CONFIG_PCA9551_LED) += pca9551_led.o obj-$(CONFIG_$(XPL_)PWRSEQ) += pwrseq-uclass.o ifdef CONFIG_QFW obj-y += qfw.o diff --git a/drivers/misc/pca9551_led.c b/drivers/misc/pca9551_led.c deleted file mode 100644 index 040d0d5cf48..00000000000 --- a/drivers/misc/pca9551_led.c +++ /dev/null @@ -1,170 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0+ -/* - * Copyright (C) 2015 Stefan Roese sr@denx.de - */ - -#include <errno.h> -#include <i2c.h> -#include <status_led.h> - -#ifndef CONFIG_PCA9551_I2C_ADDR -#error "CONFIG_PCA9551_I2C_ADDR not defined!" -#endif - -#define PCA9551_REG_INPUT 0x00 /* Input register (read only) */ -#define PCA9551_REG_PSC0 0x01 /* Frequency prescaler 0 */ -#define PCA9551_REG_PWM0 0x02 /* PWM0 */ -#define PCA9551_REG_PSC1 0x03 /* Frequency prescaler 1 */ -#define PCA9551_REG_PWM1 0x04 /* PWM1 */ -#define PCA9551_REG_LS0 0x05 /* LED0 to LED3 selector */ -#define PCA9551_REG_LS1 0x06 /* LED4 to LED7 selector */ - -#define PCA9551_CTRL_AI (1 << 4) /* Auto-increment flag */ - -#define PCA9551_LED_STATE_ON 0x00 -#define PCA9551_LED_STATE_OFF 0x01 -#define PCA9551_LED_STATE_BLINK0 0x02 -#define PCA9551_LED_STATE_BLINK1 0x03 - -struct pca9551_blink_rate { - u8 psc; /* Frequency preescaler, see PCA9551_7.pdf p. 6 */ - u8 pwm; /* Pulse width modulation, see PCA9551_7.pdf p. 6 */ -}; - -static int freq_last = -1; -static int mask_last = -1; -static int idx_last = -1; -static int mode_last; - -static int pca9551_led_get_state(int led, int *state) -{ - unsigned int reg; - u8 shift, buf; - int ret; - - if (led < 0 || led > 7) { - return -EINVAL; - } else if (led < 4) { - reg = PCA9551_REG_LS0; - shift = led << 1; - } else { - reg = PCA9551_REG_LS1; - shift = (led - 4) << 1; - } - - ret = i2c_read(CONFIG_PCA9551_I2C_ADDR, reg, 1, &buf, 1); - if (ret) - return ret; - - *state = (buf >> shift) & 0x03; - return 0; -} - -static int pca9551_led_set_state(int led, int state) -{ - unsigned int reg; - u8 shift, buf, mask; - int ret; - - if (led < 0 || led > 7) { - return -EINVAL; - } else if (led < 4) { - reg = PCA9551_REG_LS0; - shift = led << 1; - } else { - reg = PCA9551_REG_LS1; - shift = (led - 4) << 1; - } - mask = 0x03 << shift; - - ret = i2c_read(CONFIG_PCA9551_I2C_ADDR, reg, 1, &buf, 1); - if (ret) - return ret; - - buf = (buf & ~mask) | ((state & 0x03) << shift); - - ret = i2c_write(CONFIG_PCA9551_I2C_ADDR, reg, 1, &buf, 1); - if (ret) - return ret; - - return 0; -} - -static int pca9551_led_set_blink_rate(int idx, struct pca9551_blink_rate rate) -{ - unsigned int reg; - int ret; - - switch (idx) { - case 0: - reg = PCA9551_REG_PSC0; - break; - case 1: - reg = PCA9551_REG_PSC1; - break; - default: - return -EINVAL; - } - reg |= PCA9551_CTRL_AI; - - ret = i2c_write(CONFIG_PCA9551_I2C_ADDR, reg, 1, (u8 *)&rate, 2); - if (ret) - return ret; - - return 0; -} - -/* - * Functions referenced by cmd_led.c or status_led.c - */ -void __led_init(led_id_t id, int state) -{ -} - -void __led_set(led_id_t mask, int state) -{ - if (state == CONFIG_LED_STATUS_OFF) - pca9551_led_set_state(mask, PCA9551_LED_STATE_OFF); - else - pca9551_led_set_state(mask, PCA9551_LED_STATE_ON); -} - -void __led_toggle(led_id_t mask) -{ - int state = 0; - - pca9551_led_get_state(mask, &state); - pca9551_led_set_state(mask, !state); -} - -void __led_blink(led_id_t mask, int freq) -{ - struct pca9551_blink_rate rate; - int mode; - int idx; - - if ((freq == freq_last) || (mask == mask_last)) { - idx = idx_last; - mode = mode_last; - } else { - /* Toggle blink index */ - if (idx_last == 0) { - idx = 1; - mode = PCA9551_LED_STATE_BLINK1; - } else { - idx = 0; - mode = PCA9551_LED_STATE_BLINK0; - } - - idx_last = idx; - mode_last = mode; - } - freq_last = freq; - mask_last = mask; - - rate.psc = ((freq * 38) / 1000) - 1; - rate.pwm = 128; /* 50% duty cycle */ - - pca9551_led_set_blink_rate(idx, rate); - pca9551_led_set_state(mask, mode); -}
This driver is not used anymore. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/misc/Kconfig | 13 --- drivers/misc/Makefile | 1 - drivers/misc/pca9551_led.c | 170 ------------------------------------- 3 files changed, 184 deletions(-) delete mode 100644 drivers/misc/pca9551_led.c
Applied to ci/master, thanks!
This driver is not used anymore. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/misc/Makefile | 1 - drivers/misc/status_led.c | 124 -------------------------------------- 2 files changed, 125 deletions(-) delete mode 100644 drivers/misc/status_led.c
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index e8f48228084..e975559fd75 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -48,7 +48,6 @@ obj-$(CONFIG_$(XPL_)I2C_EEPROM) += i2c_eeprom.o obj-$(CONFIG_IHS_FPGA) += ihs_fpga.o obj-$(CONFIG_IMX8) += imx8/ obj-$(CONFIG_IMX_ELE) += imx_ele/ -obj-$(CONFIG_LED_STATUS) += status_led.o obj-$(CONFIG_MPC83XX_SERDES) += mpc83xx_serdes.o obj-$(CONFIG_$(PHASE_)LS2_SFP) += ls2_sfp.o obj-$(CONFIG_$(XPL_)MXC_OCOTP) += mxc_ocotp.o diff --git a/drivers/misc/status_led.c b/drivers/misc/status_led.c deleted file mode 100644 index 3b1baa4f840..00000000000 --- a/drivers/misc/status_led.c +++ /dev/null @@ -1,124 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0+ -/* - * (C) Copyright 2000-2003 - * Wolfgang Denk, DENX Software Engineering, wd@denx.de. - */ - -#include <status_led.h> -#include <linux/types.h> - -/* - * The purpose of this code is to signal the operational status of a - * target which usually boots over the network; while running in - * U-Boot, a status LED is blinking. As soon as a valid BOOTP reply - * message has been received, the LED is turned off. The Linux - * kernel, once it is running, will start blinking the LED again, - * with another frequency. - */ - -/* ------------------------------------------------------------------------- */ - -typedef struct { - led_id_t mask; - int state; - int period; - int cnt; -} led_dev_t; - -led_dev_t led_dev[] = { - { CONFIG_LED_STATUS_BIT, - CONFIG_LED_STATUS_STATE, - LED_STATUS_PERIOD, - 0, - }, -#if defined(CONFIG_LED_STATUS1) - { CONFIG_LED_STATUS_BIT1, - CONFIG_LED_STATUS_STATE1, - LED_STATUS_PERIOD1, - 0, - }, -#endif -#if defined(CONFIG_LED_STATUS2) - { CONFIG_LED_STATUS_BIT2, - CONFIG_LED_STATUS_STATE2, - LED_STATUS_PERIOD2, - 0, - }, -#endif -#if defined(CONFIG_LED_STATUS3) - { CONFIG_LED_STATUS_BIT3, - CONFIG_LED_STATUS_STATE3, - LED_STATUS_PERIOD3, - 0, - }, -#endif -#if defined(CONFIG_LED_STATUS4) - { CONFIG_LED_STATUS_BIT4, - CONFIG_LED_STATUS_STATE4, - LED_STATUS_PERIOD4, - 0, - }, -#endif -#if defined(CONFIG_LED_STATUS5) - { CONFIG_LED_STATUS_BIT5, - CONFIG_LED_STATUS_STATE5, - LED_STATUS_PERIOD5, - 0, - }, -#endif -}; - -#define MAX_LED_DEV (sizeof(led_dev)/sizeof(led_dev_t)) - -static int status_led_init_done = 0; - -void status_led_init(void) -{ - led_dev_t *ld; - int i; - - for (i = 0, ld = led_dev; i < MAX_LED_DEV; i++, ld++) - __led_init (ld->mask, ld->state); - status_led_init_done = 1; -} - -void status_led_tick(ulong timestamp) -{ - led_dev_t *ld; - int i; - - if (!status_led_init_done) - status_led_init(); - - for (i = 0, ld = led_dev; i < MAX_LED_DEV; i++, ld++) { - - if (ld->state != CONFIG_LED_STATUS_BLINKING) - continue; - - if (++ld->cnt >= ld->period) { - __led_toggle (ld->mask); - ld->cnt -= ld->period; - } - - } -} - -void status_led_set(int led, int state) -{ - led_dev_t *ld; - - if (led < 0 || led >= MAX_LED_DEV) - return; - - if (!status_led_init_done) - status_led_init(); - - ld = &led_dev[led]; - - ld->state = state; - if (state == CONFIG_LED_STATUS_BLINKING) { - ld->cnt = 0; /* always start with full period */ - state = CONFIG_LED_STATUS_ON; /* always start with LED _ON_ */ - } - __led_set (ld->mask, state); -}
This driver is not used anymore. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/misc/Makefile | 1 - drivers/misc/status_led.c | 124 -------------------------------------- 2 files changed, 125 deletions(-) delete mode 100644 drivers/misc/status_led.c
Applied to ci/master, thanks!
This header file is not used, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/m68k/lib/bootm.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/arch/m68k/lib/bootm.c b/arch/m68k/lib/bootm.c index 3dcff8076e3..1fa112f8dbf 100644 --- a/arch/m68k/lib/bootm.c +++ b/arch/m68k/lib/bootm.c @@ -15,9 +15,6 @@ #include <bzlib.h> #include <watchdog.h> #include <asm/byteorder.h> -#ifdef CONFIG_SHOW_BOOT_PROGRESS -# include <status_led.h> -#endif
DECLARE_GLOBAL_DATA_PTR;
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/powerpc/lib/interrupts.c | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/arch/powerpc/lib/interrupts.c b/arch/powerpc/lib/interrupts.c index 46208ae4c71..a2e7101a9d1 100644 --- a/arch/powerpc/lib/interrupts.c +++ b/arch/powerpc/lib/interrupts.c @@ -11,9 +11,6 @@ #include <irq_func.h> #include <asm/processor.h> #include <watchdog.h> -#ifdef CONFIG_LED_STATUS -#include <status_led.h> -#endif #include <asm/ptrace.h>
#ifndef CONFIG_MPC83XX_TIMER @@ -83,9 +80,6 @@ void timer_interrupt(struct pt_regs *regs) schedule(); #endif /* CONFIG_WATCHDOG || CONFIG_HW_WATCHDOG */
-#ifdef CONFIG_LED_STATUS - status_led_tick(timestamp); -#endif /* CONFIG_LED_STATUS */ }
ulong get_timer (ulong base)
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
arch/powerpc/lib/interrupts.c | 6 ------ 1 file changed, 6 deletions(-)
Applied to ci/master, thanks!
This header file is not used, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Javier Martinez Canillas javierm@redhat.com ---
(no changes since v1)
board/isee/igep00x0/igep00x0.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c index a35a7cd3b1f..35bb8c55806 100644 --- a/board/isee/igep00x0/igep00x0.c +++ b/board/isee/igep00x0/igep00x0.c @@ -8,7 +8,6 @@ #include <init.h> #include <malloc.h> #include <net.h> -#include <status_led.h> #include <dm.h> #include <ns16550.h> #include <twl4030.h>
This header file is not used, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Javier Martinez Canillas javierm@redhat.com ---
(no changes since v1)
board/isee/igep00x0/igep00x0.c | 1 - 1 file changed, 1 deletion(-)
Applied to ci/master, thanks!
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
board/sunxi/board.c | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c index 824c322a0dc..cff7b8eb247 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -49,7 +49,6 @@ #include <spl.h> #include <sy8106a.h> #include <asm/setup.h> -#include <status_led.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -550,11 +549,6 @@ void sunxi_board_init(void) { int power_failed = 0;
-#ifdef CONFIG_LED_STATUS - if (IS_ENABLED(CONFIG_SPL_DRIVERS_MISC)) - status_led_init(); -#endif - #ifdef CONFIG_SY8106A_POWER power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT); #endif
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
board/sunxi/board.c | 6 ------ 1 file changed, 6 deletions(-)
Applied to ci/master, thanks!
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
common/board_r.c | 27 --------------------------- 1 file changed, 27 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c index 62228a723e1..caac092c8e7 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -53,7 +53,6 @@ #include <pvblock.h> #include <scsi.h> #include <serial.h> -#include <status_led.h> #include <stdio_dev.h> #include <timer.h> #include <trace.h> @@ -459,29 +458,6 @@ static int initr_malloc_bootparams(void) } #endif
-static int initr_status_led(void) -{ - status_led_init(); - - return 0; -} - -static int initr_boot_led_blink(void) -{ - status_led_boot_blink(); - - led_boot_blink(); - - return 0; -} - -static int initr_boot_led_on(void) -{ - led_boot_on(); - - return 0; -} - #if defined(CONFIG_CMD_NET) static int initr_net(void) { @@ -735,8 +711,6 @@ static init_fnc_t init_sequence_r[] = { #if defined(CONFIG_MICROBLAZE) || defined(CONFIG_M68K) timer_init, /* initialize timer */ #endif - initr_status_led, - initr_boot_led_blink, /* PPC has a udelay(20) here dating from 2002. Why? */ #ifdef CONFIG_BOARD_LATE_INIT board_late_init, @@ -759,7 +733,6 @@ static init_fnc_t init_sequence_r[] = { #if defined(CFG_PRAM) initr_mem, #endif - initr_boot_led_on, run_main_loop, };
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
common/board_r.c | 27 --------------------------- 1 file changed, 27 deletions(-)
Applied to ci/master, thanks!
This header file is not used, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
boot/image.c | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/boot/image.c b/boot/image.c index abac254e026..7bed8ba4b1f 100644 --- a/boot/image.c +++ b/boot/image.c @@ -15,10 +15,6 @@ #include <malloc.h> #include <u-boot/crc.h>
-#ifdef CONFIG_SHOW_BOOT_PROGRESS -#include <status_led.h> -#endif - #if CONFIG_IS_ENABLED(FIT) || CONFIG_IS_ENABLED(OF_LIBFDT) #include <linux/libfdt.h> #include <fdt_support.h>
On Sat, 2 Nov 2024 at 18:38, Simon Glass sjg@chromium.org wrote:
This header file is not used, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
boot/image.c | 4 ---- 1 file changed, 4 deletions(-)
Applied to ci/master, thanks!
This header file is not used, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
cmd/ide.c | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/cmd/ide.c b/cmd/ide.c index 036489fda97..be3078ae88b 100644 --- a/cmd/ide.c +++ b/cmd/ide.c @@ -22,10 +22,6 @@ #include <ide.h> #include <ata.h>
-#ifdef CONFIG_LED_STATUS -# include <status_led.h> -#endif - /* Current I/O Device */ static int curr_device;
This header file is not used, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
cmd/ide.c | 4 ---- 1 file changed, 4 deletions(-)
Applied to ci/master, thanks!
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/timer/mpc83xx_timer.c | 5 ----- 1 file changed, 5 deletions(-)
diff --git a/drivers/timer/mpc83xx_timer.c b/drivers/timer/mpc83xx_timer.c index 9da74479aaa..aefc18898e9 100644 --- a/drivers/timer/mpc83xx_timer.c +++ b/drivers/timer/mpc83xx_timer.c @@ -9,7 +9,6 @@ #include <dm.h> #include <irq_func.h> #include <log.h> -#include <status_led.h> #include <sysinfo.h> #include <time.h> #include <timer.h> @@ -178,10 +177,6 @@ void timer_interrupt(struct pt_regs *regs) if (CFG_SYS_WATCHDOG_FREQ && (priv->timestamp % (CFG_SYS_WATCHDOG_FREQ)) == 0) schedule(); #endif /* CONFIG_WATCHDOG || CONFIG_HW_WATCHDOG */ - -#ifdef CONFIG_LED_STATUS - status_led_tick(priv->timestamp); -#endif /* CONFIG_LED_STATUS */ }
void wait_ticks(ulong ticks)
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/timer/mpc83xx_timer.c | 5 ----- 1 file changed, 5 deletions(-)
Applied to ci/master, thanks!
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
net/bootp.c | 7 ------- net/net.c | 33 --------------------------------- 2 files changed, 40 deletions(-)
diff --git a/net/bootp.c b/net/bootp.c index afd5b48094a..42462afda3e 100644 --- a/net/bootp.c +++ b/net/bootp.c @@ -19,9 +19,6 @@ #include <linux/delay.h> #include <net/tftp.h> #include "bootp.h" -#ifdef CONFIG_LED_STATUS -#include <status_led.h> -#endif #ifdef CONFIG_BOOTP_RANDOM_DELAY #include "net_rand.h" #endif @@ -370,10 +367,6 @@ static void bootp_handler(uchar *pkt, unsigned dest, struct in_addr sip, /* * Got a good BOOTP reply. Copy the data into our variables. */ -#if defined(CONFIG_LED_STATUS) && defined(CONFIG_LED_STATUS_BOOT_ENABLE) - status_led_set(CONFIG_LED_STATUS_BOOT, CONFIG_LED_STATUS_OFF); -#endif - store_net_params(bp); /* Store net parameters from reply */
/* Retrieve extended information (we must parse the vendor area) */ diff --git a/net/net.c b/net/net.c index f47e9fbe33a..fc869d8bd48 100644 --- a/net/net.c +++ b/net/net.c @@ -100,10 +100,6 @@ #include <net/pcap.h> #endif #include <net/udp.h> -#if defined(CONFIG_LED_STATUS) -#include <miiphy.h> -#include <status_led.h> -#endif #include <watchdog.h> #include <linux/compiler.h> #include <test/test.h> @@ -614,19 +610,6 @@ restart: break; }
-#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) -#if defined(CONFIG_SYS_FAULT_ECHO_LINK_DOWN) && \ - defined(CONFIG_LED_STATUS) && \ - defined(CONFIG_LED_STATUS_RED) - /* - * Echo the inverted link state to the fault LED. - */ - if (miiphy_link(eth_get_dev()->name, CONFIG_SYS_FAULT_MII_ADDR)) - status_led_set(CONFIG_LED_STATUS_RED, CONFIG_LED_STATUS_OFF); - else - status_led_set(CONFIG_LED_STATUS_RED, CONFIG_LED_STATUS_ON); -#endif /* CONFIG_SYS_FAULT_ECHO_LINK_DOWN, ... */ -#endif /* CONFIG_MII, ... */ #ifdef CONFIG_USB_KEYBOARD net_busy_flag = 1; #endif @@ -684,22 +667,6 @@ restart: ((get_timer(0) - time_start) > time_delta)) { thand_f *x;
-#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) -#if defined(CONFIG_SYS_FAULT_ECHO_LINK_DOWN) && \ - defined(CONFIG_LED_STATUS) && \ - defined(CONFIG_LED_STATUS_RED) - /* - * Echo the inverted link state to the fault LED. - */ - if (miiphy_link(eth_get_dev()->name, - CONFIG_SYS_FAULT_MII_ADDR)) - status_led_set(CONFIG_LED_STATUS_RED, - CONFIG_LED_STATUS_OFF); - else - status_led_set(CONFIG_LED_STATUS_RED, - CONFIG_LED_STATUS_ON); -#endif /* CONFIG_SYS_FAULT_ECHO_LINK_DOWN, ... */ -#endif /* CONFIG_MII, ... */ debug_cond(DEBUG_INT_STATE, "--- net_loop timeout\n"); x = time_handler; time_handler = (thand_f *)0;
This is not used anymore, so drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
net/bootp.c | 7 ------- net/net.c | 33 --------------------------------- 2 files changed, 40 deletions(-)
Applied to ci/master, thanks!
This is not needed anymore. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
include/status_led.h | 104 ------------------------------------------- 1 file changed, 104 deletions(-) delete mode 100644 include/status_led.h
diff --git a/include/status_led.h b/include/status_led.h deleted file mode 100644 index 59cf9f89956..00000000000 --- a/include/status_led.h +++ /dev/null @@ -1,104 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0+ */ -/* - * (C) Copyright 2000-2004 - * Wolfgang Denk, DENX Software Engineering, wd@denx.de. - */ - -/* - * The purpose of this code is to signal the operational status of a - * target which usually boots over the network; while running in - * PCBoot, a status LED is blinking. As soon as a valid BOOTP reply - * message has been received, the LED is turned off. The Linux - * kernel, once it is running, will start blinking the LED again, - * with another frequency. - */ - -#ifndef _STATUS_LED_H_ -#define _STATUS_LED_H_ - -#ifdef CONFIG_LED_STATUS - -#define LED_STATUS_PERIOD (CONFIG_SYS_HZ / CONFIG_LED_STATUS_FREQ) -#ifdef CONFIG_LED_STATUS1 -#define LED_STATUS_PERIOD1 (CONFIG_SYS_HZ / CONFIG_LED_STATUS_FREQ1) -#endif /* CONFIG_LED_STATUS1 */ -#ifdef CONFIG_LED_STATUS2 -#define LED_STATUS_PERIOD2 (CONFIG_SYS_HZ / CONFIG_LED_STATUS_FREQ2) -#endif /* CONFIG_LED_STATUS2 */ -#ifdef CONFIG_LED_STATUS3 -#define LED_STATUS_PERIOD3 (CONFIG_SYS_HZ / CONFIG_LED_STATUS_FREQ3) -#endif /* CONFIG_LED_STATUS3 */ -#ifdef CONFIG_LED_STATUS4 -#define LED_STATUS_PERIOD4 (CONFIG_SYS_HZ / CONFIG_LED_STATUS_FREQ4) -#endif /* CONFIG_LED_STATUS4 */ -#ifdef CONFIG_LED_STATUS5 -#define LED_STATUS_PERIOD5 (CONFIG_SYS_HZ / CONFIG_LED_STATUS_FREQ5) -#endif /* CONFIG_LED_STATUS5 */ - -void status_led_init(void); -void status_led_tick(unsigned long timestamp); -void status_led_set(int led, int state); - -static inline void status_led_boot_blink(void) -{ -#ifdef CONFIG_LED_STATUS_BOOT_ENABLE - status_led_set(CONFIG_LED_STATUS_BOOT, CONFIG_LED_STATUS_BLINKING); -#endif -} - -/***** MVS v1 **********************************************************/ -#if (defined(CONFIG_MVS) && CONFIG_MVS < 2) -# define STATUS_LED_PAR im_ioport.iop_pdpar -# define STATUS_LED_DIR im_ioport.iop_pddir -# undef STATUS_LED_ODR -# define STATUS_LED_DAT im_ioport.iop_pddat - -# define STATUS_LED_ACTIVE 1 /* LED on for bit == 1 */ - -/***** Someone else defines these *************************************/ -#elif defined(STATUS_LED_PAR) - /* - * ADVICE: Define in your board configuration file rather than - * filling this file up with lots of custom board stuff. - */ -#else -# error Status LED configuration missing -#endif -/************************************************************************/ - -#include <asm/status_led.h> - -#else - -static inline void status_led_init(void) { } -static inline void status_led_set(int led, int state) { } -static inline void status_led_boot_blink(void) { } - -#endif /* CONFIG_LED_STATUS */ - -/* - * Coloured LEDs API - */ -#ifndef __ASSEMBLY__ -void coloured_LED_init(void); -void red_led_on(void); -void red_led_off(void); -void green_led_on(void); -void green_led_off(void); -void yellow_led_on(void); -void yellow_led_off(void); -void blue_led_on(void); -void blue_led_off(void); -#else - .extern LED_init - .extern red_led_on - .extern red_led_off - .extern yellow_led_on - .extern yellow_led_off - .extern green_led_on - .extern green_led_off - .extern blue_led_on - .extern blue_led_off -#endif - -#endif /* _STATUS_LED_H_ */
This is not needed anymore. Drop it.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
include/status_led.h | 104 ------------------------------------------- 1 file changed, 104 deletions(-) delete mode 100644 include/status_led.h
Applied to ci/master, thanks!
Some of U-Boot's options have made it upstream, so bring in the binding file.
This is taken from dt-schema commit c9b4797
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v2)
Changes in v2: - Enable LED on the 5 affected platforms - Reorder patches for bisectability - Add dt-schema bindings for LED
doc/device-tree-bindings/options.yaml | 79 +++++++++++ doc/device-tree-bindings/options/u-boot.yaml | 136 +++++++++++++++++++ 2 files changed, 215 insertions(+) create mode 100644 doc/device-tree-bindings/options.yaml create mode 100644 doc/device-tree-bindings/options/u-boot.yaml
diff --git a/doc/device-tree-bindings/options.yaml b/doc/device-tree-bindings/options.yaml new file mode 100644 index 00000000000..d6f5bbb00db --- /dev/null +++ b/doc/device-tree-bindings/options.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-clause +# Copyright 2021 Google LLC +# + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/options.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: /options Node + +maintainers: + - Simon Glass sjg@chromium.org + +description: | + The '/options' node does not represent a real device, but serves as a place + for passing data into and between firmware components, such as memory + mappings. Data in the '/options' node does not represent the hardware. It is + ignored by operating systems. + + Properties in this node should be common to (and used by) at least two + firmware projects, such as U-Boot and TF-A. Project-specific subnodes can be + used for properties which are specific to a single project. + + This is based on the precedent set by IEEE 1275-1994 IEEE Standard for Boot + (Initialization Configuration) Firmware: Core Requirements and Practices + at https://www.openfirmware.info/data/docs/of1275.pdf + + Purpose of '/options' node + -------------------------- + + A common problem with firmware is that many builds are needed to deal with the + slight variations between different, related models of the same hardware. For + example, one model may have a TPM and another may not. Devicetree provides an + excellent solution to this problem, in that the devicetree to actually use on + a platform can be injected in the factory based on which model is being + manufactured at the time. + + A related problem causing build proliferation is dealing with the differences + between development firmware, developer-friendly firmware (e.g. with all + security features present but with the ability to access the command line), + test firmware (which runs tests used in the factory), final production + firmware (before signing), signed firmware (where the signatures have been + inserted) and the like. Ideally all or most of these should use the same + firmware build, with just some options to determine the features available. + For example, being able to control whether the UART console or JTAG are + available, on any image, is a great debugging aid. + + When the firmware consists of multiple parts (various U-Boot phases, TF-A, + OP-TEE), it is helpful that all operate the same way at runtime, regardless of + how they were built. This can be achieved by passing the runtime configuration + (e.g. 'enable UART console', 'here are your public keys') along the chain + through each firmware stage. It is frustrating to have to replicate a bug on + production firmware which does not happen on developer firmware, because they + are completely different builds. + + The '/options' node provides useful functionality for this. It allows the + different controls to be 'factored out' of the firmware binaries, so they can + be controlled separately from the initial source-code build. The node can be + easily updated by a build or factory tool and can control various features in + the firmware binaries. It is similar in concept to a Kconfig option, except + that it can be changed after firmware binaries are built. + + The '/options' node is similar in concept to /chosen (see chosen.yaml) except + that it is for passing information *into* and *between*) firmware components, + instead of from firmware to the operating system. Also, while operating + systems typically have a (sometimes extremely long) command line, firmware + binaries typically do not support this. The devicetree provides a more + structured approach in any case. + +properties: + $nodename: + const: options + + "#address-cells": true + "#size-cells": true + +additionalProperties: + type: object diff --git a/doc/device-tree-bindings/options/u-boot.yaml b/doc/device-tree-bindings/options/u-boot.yaml new file mode 100644 index 00000000000..c9894ff5c48 --- /dev/null +++ b/doc/device-tree-bindings/options/u-boot.yaml @@ -0,0 +1,136 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2021 Google LLC + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/options/u-boot.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-Boot configuration node + +maintainers: + - Simon Glass sjg@chromium.org + +description: | + The u-boot,config node provides basic configuration information to U-Boot, + for use during its execution. It can be used to control U-Boot's behaviour + in various ways. + +properties: + $nodename: + const: u-boot + + compatible: + const: u-boot,config + + bootcmd: + $ref: /schemas/types.yaml#/definitions/string + description: | + Allows overwriting of the boot command used by U-Boot on startup. If + present, U-Boot uses this command instead. Note that this feature can + work even if loading the environment is disabled, e.g. for security + reasons. See also bootsecure. + + bootdelay-sec: + description: | + Allows selecting of the U-Boot bootdelay, to control whether U-Boot + waits on boot or for how long. This allows this option to be configured + by the build system or by a previous-stage binary. For example, if the + images is being packed for testing or a user holds down a button, it may + allow a delay, but disable it for production. + + If this property is not present, a default value is used instead. + + Note that this uses the 'sec' property unit, even though it allows a + negative value. + + Values: + + -1: no bootdelay and the user cannot interrupt boot + 0: no bootdelay but use user can still interrupt boot by holding down a + key, if enabled + >= 1: delay for this many seconds + + + bootsecure: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + maximum: 2 + description: | + Controls the execution of the boot command in U-Boot, e.g. selecting + between using a special function to run commands, or the normal CLI. This + can be used in production images, to restrict the amount of parsing done + or the options available, to cut back on the available surface for + security attacks. + + Values: + + 0: normal boot using CLI (default if not present) + 1: use secure boot mechanism instead to parse and run commands + other values are reserved for future use + 2: use simplified command line (e.g. avoid hush) + 3... reserved + + bootscr-address: + $ref: /schemas/types.yaml#/definitions/uint64 + default: 0x0 + description: + Holds the full address of the boot script file. It helps in making + automated flow easier by fetching the 64bit address directly from DT. + Value should be automatically copied to the U-Boot 'scriptaddr' variable. + When it is defined, bootscr-ram-offset property should be ignored. + Actually only one of them should be present in the DT. + + bootscr-ram-offset: + $ref: /schemas/types.yaml#/definitions/uint64 + default: 0x0 + description: + Holds the boot script file offset from the start of the ram base address. + Platforms with run-time RAM-detection algorithms should use this property + because it is not clear exactly where the script address should be placed. + Using it will provide the option to specify boot script offset from + detected RAM start. The U-Boot 'scriptaddr' variable should be composed as + detected RAM start plus value of bootscr-ram-offset property. + It should be used only when bootscr-address is not defined. + + silent-console: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + maximum: 2 + description: | + This allows the console to be silenced by default on boot. This can allow + easy disabling of console output on a production build, for example. When + suppressed, the console is still active. This feature only suppresses the + console output itself, on all output devices. + + Values: + + 0: console output appears as normal (default) + 1: console output is suppressed but console recording still operates (if + enabled) + 2: console output is suppressed and not recorded + +required: + - compatible + +if: + required: + - bootscr-address +then: + properties: + bootscr-ram-offset: false + +additionalProperties: false + +examples: + - | + options { + u-boot { + compatible = "u-boot,config"; + bootcmd = "vboot go auto"; + bootdelay-sec = <(-1)>; + bootsecure = <1>; + bootscr-address = /bits/ 64 <0x1000>; + silent-console = <1>; + }; + };
Some of U-Boot's options have made it upstream, so bring in the binding file.
This is taken from dt-schema commit c9b4797
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v2)
Changes in v2: - Enable LED on the 5 affected platforms - Reorder patches for bisectability - Add dt-schema bindings for LED
doc/device-tree-bindings/options.yaml | 79 +++++++++++ doc/device-tree-bindings/options/u-boot.yaml | 136 +++++++++++++++++++ 2 files changed, 215 insertions(+) create mode 100644 doc/device-tree-bindings/options.yaml create mode 100644 doc/device-tree-bindings/options/u-boot.yaml
Applied to ci/master, thanks!
On Sun, 3 Nov 2024 at 00:34, Simon Glass sjg@chromium.org wrote:
There has been an LED framework in U-Boot which uses driver model for about 9 years now. Recent work is underway to improve it and provide more features. It is probably a good time to drop the old code, which is only used by 5 boards:
I don't believe, from what I can tell, they are feature comparable, at the very least I have not been able to get the Pinephone working with this so as it stands I still don't think this patch set is ready yet.
./tools/qconfig.py -f LED_STATUS 5 matches eb_cpu5282 eb_cpu5282_internal mx23_olinuxino pinephone socfpga_vining_fpga
This series attempts that.
The new /options node provides a way to provide U-Boot settings, and LEDs are implemented there. For now I have brought into the options schema from upstream. We can update it once the LED additions land there.
Changes in v3:
- Update commit message
- Combine removal and enable patches
- Combine removal and enable patches
- Combine removal and enable patches
Changes in v2:
- Combine code-removal and defconfig changes
- Add a patch to enable LED and LED_BOOT for these boards
- Enable LED on the 5 affected platforms
- Reorder patches for bisectability
- Add dt-schema bindings for LED
Simon Glass (25): eb_cpu5282: Drop status-LED code and enable LED vining_fpga: Drop status-LED code and use LED mx23_olinuxino: Drop status-LED code and use LED pinephone: Drop status-LED code and use LED led: Drop LED_STATUS_BOARD_SPECIFIC arm: Drop old LED support common: doc: Drop old LED support st: stm32f429: Drop old LED code led: Make the LED config common led: Drop LED_STATUS from Kconfig led: Drop the legacy LED command misc: Drop gpio_led driver pca9551_led: Delete driver misc: status_led: Delete driver m68k: Drop unused status_led.h header file powerpc: Drop status-LED code igep00x0: Drop unused status_led.h header file sunxi: Drop status-LED code common: Drop status-LED code in board_r image: Drop unused status_led.h header file ide: Drop unused status_led.h header file mpc83xx: Drop status-LED code net: Drop status-LED code led: Drop status_led header file doc: Add devicetree bindings for options
arch/arm/lib/crt0.S | 4 - arch/m68k/lib/bootm.c | 3 - arch/powerpc/lib/interrupts.c | 6 - board/BuS/eb_cpu5282/eb_cpu5282.c | 20 -- board/isee/igep00x0/igep00x0.c | 1 - board/olimex/mx23_olinuxino/mx23_olinuxino.c | 7 - board/softing/vining_fpga/socfpga.c | 4 - board/st/stm32f429-discovery/Makefile | 1 - board/st/stm32f429-discovery/led.c | 39 --- board/sunxi/board.c | 6 - boot/image.c | 4 - cmd/Makefile | 1 - cmd/ide.c | 4 - cmd/legacy_led.c | 185 ---------- common/board_f.c | 22 -- common/board_r.c | 27 -- configs/eb_cpu5282_defconfig | 8 +- configs/eb_cpu5282_internal_defconfig | 8 +- configs/mx23_olinuxino_defconfig | 10 +- configs/pinephone_defconfig | 7 +- configs/socfpga_vining_fpga_defconfig | 13 +- doc/README.LED | 77 ----- doc/device-tree-bindings/options.yaml | 79 +++++ doc/device-tree-bindings/options/u-boot.yaml | 136 ++++++++ drivers/led/Kconfig | 342 +------------------ drivers/misc/Kconfig | 13 - drivers/misc/Makefile | 3 - drivers/misc/gpio_led.c | 106 ------ drivers/misc/pca9551_led.c | 170 --------- drivers/misc/status_led.c | 124 ------- drivers/timer/mpc83xx_timer.c | 5 - include/configs/eb_cpu5282.h | 6 - include/status_led.h | 115 ------- net/bootp.c | 7 - net/net.c | 33 -- 35 files changed, 236 insertions(+), 1360 deletions(-) delete mode 100644 board/st/stm32f429-discovery/led.c delete mode 100644 cmd/legacy_led.c delete mode 100644 doc/README.LED create mode 100644 doc/device-tree-bindings/options.yaml create mode 100644 doc/device-tree-bindings/options/u-boot.yaml delete mode 100644 drivers/misc/gpio_led.c delete mode 100644 drivers/misc/pca9551_led.c delete mode 100644 drivers/misc/status_led.c delete mode 100644 include/status_led.h
-- 2.43.0
Hi Peter,
On Tue, 5 Nov 2024 at 07:18, Peter Robinson pbrobinson@gmail.com wrote:
On Sun, 3 Nov 2024 at 00:34, Simon Glass sjg@chromium.org wrote:
There has been an LED framework in U-Boot which uses driver model for about 9 years now. Recent work is underway to improve it and provide more features. It is probably a good time to drop the old code, which is only used by 5 boards:
I don't believe, from what I can tell, they are feature comparable, at the very least I have not been able to get the Pinephone working with this so as it stands I still don't think this patch set is ready yet.
I don't have that hardware, nor the other 4, so cannot do anything with this feedback.
Can you please be clear what you are asking me to do?
Regards, Simon
Hi Simon,
On Tue, 5 Nov 2024 at 07:18, Peter Robinson pbrobinson@gmail.com wrote:
On Sun, 3 Nov 2024 at 00:34, Simon Glass sjg@chromium.org wrote:
There has been an LED framework in U-Boot which uses driver model for about 9 years now. Recent work is underway to improve it and provide more features. It is probably a good time to drop the old code, which is only used by 5 boards:
I don't believe, from what I can tell, they are feature comparable, at the very least I have not been able to get the Pinephone working with this so as it stands I still don't think this patch set is ready yet.
I don't have that hardware, nor the other 4, so cannot do anything with this feedback.
Don't you have any HW that has a LED on it that you can substitute to see what it does?
Can you please be clear what you are asking me to do?
Either produce patches that work on the the pinephone, or docs I, or other developers, can use to implement the functionality.
Currently on the Pinephone the green LED lights up in the TPL/SPL (very early before ATF) stage and is lit up right through the the various FW stages, with your patch set I get no LED what so ever.
Peter
On Thu, Nov 07, 2024 at 07:33:51PM +0000, Peter Robinson wrote:
Hi Simon,
On Tue, 5 Nov 2024 at 07:18, Peter Robinson pbrobinson@gmail.com wrote:
On Sun, 3 Nov 2024 at 00:34, Simon Glass sjg@chromium.org wrote:
There has been an LED framework in U-Boot which uses driver model for about 9 years now. Recent work is underway to improve it and provide more features. It is probably a good time to drop the old code, which is only used by 5 boards:
I don't believe, from what I can tell, they are feature comparable, at the very least I have not been able to get the Pinephone working with this so as it stands I still don't think this patch set is ready yet.
I don't have that hardware, nor the other 4, so cannot do anything with this feedback.
Don't you have any HW that has a LED on it that you can substitute to see what it does?
Can you please be clear what you are asking me to do?
Either produce patches that work on the the pinephone, or docs I, or other developers, can use to implement the functionality.
Currently on the Pinephone the green LED lights up in the TPL/SPL (very early before ATF) stage and is lit up right through the the various FW stages, with your patch set I get no LED what so ever.
Please note that needing to confirm that we have equivalent functionality between old and new frameworks (and https://lore.kernel.org/all/20241110115054.2555-1-ansuelsmth@gmail.com/ might cover that) is why this series isn't ready for -next at this time.
Hi Tom,
On Tue, 3 Dec 2024 at 12:48, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 07, 2024 at 07:33:51PM +0000, Peter Robinson wrote:
Hi Simon,
On Tue, 5 Nov 2024 at 07:18, Peter Robinson pbrobinson@gmail.com wrote:
On Sun, 3 Nov 2024 at 00:34, Simon Glass sjg@chromium.org wrote:
There has been an LED framework in U-Boot which uses driver model for about 9 years now. Recent work is underway to improve it and provide more features. It is probably a good time to drop the old code, which is only used by 5 boards:
I don't believe, from what I can tell, they are feature comparable, at the very least I have not been able to get the Pinephone working with this so as it stands I still don't think this patch set is ready yet.
I don't have that hardware, nor the other 4, so cannot do anything with this feedback.
Don't you have any HW that has a LED on it that you can substitute to see what it does?
Can you please be clear what you are asking me to do?
Either produce patches that work on the the pinephone, or docs I, or other developers, can use to implement the functionality.
Currently on the Pinephone the green LED lights up in the TPL/SPL (very early before ATF) stage and is lit up right through the the various FW stages, with your patch set I get no LED what so ever.
Please note that needing to confirm that we have equivalent functionality between old and new frameworks (and https://lore.kernel.org/all/20241110115054.2555-1-ansuelsmth@gmail.com/ might cover that) is why this series isn't ready for -next at this time.
Yes, I'm not sure if Peter saw that, so I sent him the link.
Regards, Simon
On Tue, 3 Dec 2024 at 19:51, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Tue, 3 Dec 2024 at 12:48, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 07, 2024 at 07:33:51PM +0000, Peter Robinson wrote:
Hi Simon,
On Tue, 5 Nov 2024 at 07:18, Peter Robinson pbrobinson@gmail.com
wrote:
On Sun, 3 Nov 2024 at 00:34, Simon Glass sjg@chromium.org wrote:
There has been an LED framework in U-Boot which uses driver
model for
about 9 years now. Recent work is underway to improve it and
provide
more features. It is probably a good time to drop the old code,
which
is only used by 5 boards:
I don't believe, from what I can tell, they are feature
comparable, at
the very least I have not been able to get the Pinephone working
with
this so as it stands I still don't think this patch set is ready
yet.
I don't have that hardware, nor the other 4, so cannot do anything with this feedback.
Don't you have any HW that has a LED on it that you can substitute to see what it does?
Can you please be clear what you are asking me to do?
Either produce patches that work on the the pinephone, or docs I, or other developers, can use to implement the functionality.
Currently on the Pinephone the green LED lights up in the TPL/SPL (very early before ATF) stage and is lit up right through the the various FW stages, with your patch set I get no LED what so ever.
Please note that needing to confirm that we have equivalent functionality between old and new frameworks (and https://lore.kernel.org/all/20241110115054.2555-1-ansuelsmth@gmail.com/ might cover that) is why this series isn't ready for -next at this time.
Yes, I'm not sure if Peter saw that, so I sent him the link.
I have seen it, I have not had the chance to dig out my pinephone to test it again because I was traveling and had competing priorities on my time (and I do this as a hobby).
But also I think we have a little time on this, the new functionality only landed recently and we've had a LOT of deprecated functionality hang around for a lot longer than that. I think we should get this right rather than jam it through.
Peter
Hi Peter,
On Thu, 5 Dec 2024 at 13:36, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, 3 Dec 2024 at 19:51, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Tue, 3 Dec 2024 at 12:48, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 07, 2024 at 07:33:51PM +0000, Peter Robinson wrote:
Hi Simon,
On Tue, 5 Nov 2024 at 07:18, Peter Robinson pbrobinson@gmail.com wrote:
On Sun, 3 Nov 2024 at 00:34, Simon Glass sjg@chromium.org wrote: > > There has been an LED framework in U-Boot which uses driver model for > about 9 years now. Recent work is underway to improve it and provide > more features. It is probably a good time to drop the old code, which > is only used by 5 boards:
I don't believe, from what I can tell, they are feature comparable, at the very least I have not been able to get the Pinephone working with this so as it stands I still don't think this patch set is ready yet.
I don't have that hardware, nor the other 4, so cannot do anything with this feedback.
Don't you have any HW that has a LED on it that you can substitute to see what it does?
Can you please be clear what you are asking me to do?
Either produce patches that work on the the pinephone, or docs I, or other developers, can use to implement the functionality.
Currently on the Pinephone the green LED lights up in the TPL/SPL (very early before ATF) stage and is lit up right through the the various FW stages, with your patch set I get no LED what so ever.
Please note that needing to confirm that we have equivalent functionality between old and new frameworks (and https://lore.kernel.org/all/20241110115054.2555-1-ansuelsmth@gmail.com/ might cover that) is why this series isn't ready for -next at this time.
Yes, I'm not sure if Peter saw that, so I sent him the link.
I have seen it, I have not had the chance to dig out my pinephone to test it again because I was traveling and had competing priorities on my time (and I do this as a hobby).
But also I think we have a little time on this, the new functionality only landed recently and we've had a LOT of deprecated functionality hang around for a lot longer than that. I think we should get this right rather than jam it through.
There's plenty of time for you to test. But we're really not losing anything by applying these patches (and also [1]). It is more likely to work for your board, but if it doesn't, we can focus efforts on what is wrong rather than trying to keep the old code around.
One of the challenges I have, as someone who also does this as a hobby, is that few people are willing to take on deprecation efforts. This work is not very interesting, most of the time, and it is extremely hard to get things to actually land, since anyone can raise their hand and say that it doesn't solve a particular use case. I suppose most people do U-Boot things in their spare time and few have a lot of time to test or try things out. So there needs to be a balance struck, to encourage more people to help.
Regards, Simon
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=432093&state=*
On Fri, 6 Dec 2024 at 00:01, Simon Glass sjg@chromium.org wrote:
Hi Peter,
On Thu, 5 Dec 2024 at 13:36, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, 3 Dec 2024 at 19:51, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Tue, 3 Dec 2024 at 12:48, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 07, 2024 at 07:33:51PM +0000, Peter Robinson wrote:
Hi Simon,
On Tue, 5 Nov 2024 at 07:18, Peter Robinson pbrobinson@gmail.com
wrote:
> > On Sun, 3 Nov 2024 at 00:34, Simon Glass sjg@chromium.org
wrote:
> > > > There has been an LED framework in U-Boot which uses driver
model for
> > about 9 years now. Recent work is underway to improve it and
provide
> > more features. It is probably a good time to drop the old
code, which
> > is only used by 5 boards: > > I don't believe, from what I can tell, they are feature
comparable, at
> the very least I have not been able to get the Pinephone
working with
> this so as it stands I still don't think this patch set is
ready yet.
I don't have that hardware, nor the other 4, so cannot do anything with this feedback.
Don't you have any HW that has a LED on it that you can substitute
to
see what it does?
Can you please be clear what you are asking me to do?
Either produce patches that work on the the pinephone, or docs I, or other developers, can use to implement the functionality.
Currently on the Pinephone the green LED lights up in the TPL/SPL (very early before ATF) stage and is lit up right through the the various FW stages, with your patch set I get no LED what so ever.
Please note that needing to confirm that we have equivalent functionality between old and new frameworks (and
https://lore.kernel.org/all/20241110115054.2555-1-ansuelsmth@gmail.com/
might cover that) is why this series isn't ready for -next at this
time.
Yes, I'm not sure if Peter saw that, so I sent him the link.
I have seen it, I have not had the chance to dig out my pinephone to
test it again because I was traveling and had competing priorities on my time (and I do this as a hobby).
But also I think we have a little time on this, the new functionality
only landed recently and we've had a LOT of deprecated functionality hang around for a lot longer than that. I think we should get this right rather than jam it through.
There's plenty of time for you to test. But we're really not losing anything by applying these patches (and also [1]). It is more likely to work for your board, but if it doesn't, we can focus efforts on what is wrong rather than trying to keep the old code around.
I'm sorry but I disagree, bulldozing patches in just because it's suitable for you but breaks actual usecases is not the right way to do thing, at the moment this works and it useful features for users. Actively breaking valid UX Is hostile and not the right way to do things!
One of the challenges I have, as someone who also does this as a hobby, is that few people are willing to take on deprecation efforts.
I do this as a hobby too, you are not unique here.
This work is not very interesting, most of the time, and it is extremely hard to get things to actually land, since anyone can raise their hand and say that it doesn't solve a particular use case. I suppose most people do U-Boot things in their spare time and few have a lot of time to test or try things out. So there needs to be a balance struck, to encourage more people to help.
I'm sorry, I do feel for you, I have the same problem and I end up spending most of my spare of late reading emails due to the deluge.
But actively breaking valid usecases by bulldozing things through, it NOT the way to handle things, I'm sorry here what role you perceive you play whether it be a full time employee, paid contractor or hobbyist isn't a valid reason for forcing through patches, please do not use that as a reason.
Hi Tom,
On Tue, 3 Dec 2024 at 12:48, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 07, 2024 at 07:33:51PM +0000, Peter Robinson wrote:
Hi Simon,
On Tue, 5 Nov 2024 at 07:18, Peter Robinson pbrobinson@gmail.com wrote:
On Sun, 3 Nov 2024 at 00:34, Simon Glass sjg@chromium.org wrote:
There has been an LED framework in U-Boot which uses driver model for about 9 years now. Recent work is underway to improve it and provide more features. It is probably a good time to drop the old code, which is only used by 5 boards:
I don't believe, from what I can tell, they are feature comparable, at the very least I have not been able to get the Pinephone working with this so as it stands I still don't think this patch set is ready yet.
I don't have that hardware, nor the other 4, so cannot do anything with this feedback.
Don't you have any HW that has a LED on it that you can substitute to see what it does?
Can you please be clear what you are asking me to do?
Either produce patches that work on the the pinephone, or docs I, or other developers, can use to implement the functionality.
Currently on the Pinephone the green LED lights up in the TPL/SPL (very early before ATF) stage and is lit up right through the the various FW stages, with your patch set I get no LED what so ever.
Please note that needing to confirm that we have equivalent functionality between old and new frameworks (and https://lore.kernel.org/all/20241110115054.2555-1-ansuelsmth@gmail.com/ might cover that) is why this series isn't ready for -next at this time.
Link to series: https://patchwork.ozlabs.org/project/uboot/list/?series=431000&state=*
Current status: marked 'changed requested' in patchwork. Applied to sjg tree.
Peter, if you would like to retest this series now that [1] is in -next, please do. Or if you can make time for some development with your device, that would be welcome.
Regards, Simon
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=432093&state=*
participants (4)
-
Patrice CHOTARD -
Peter Robinson -
Simon Glass -
Tom Rini