[U-Boot] __led_set usage is inconsistent

Hi,
I hope that this is not a common question. I have read doc/README.LED, compiled in the GPIO LED driver, provided my GPIO number, enabled the LED command and then noticed that "led 0 on" didn't do what I wanted.
It appears that the semantic of "state" in __led_set(mask, state) is used in two different ways.
1.) status_led_set is using STATUS_LED_ON|STATUS_LED_OFF for the state parameter. 2.) cmd_led.c is using 0|1 when calling __led_set.
The confusing is in the implementation as well. 1.) drivers/misc/gpio_led.c expects it to be STATUS_LED_* 2.) board/ti/beagle/led.c wants 0|1
Which part of the code is right? Will a patch to use an enum for the state be appreciated?
holger

On Friday 13 July 2012 08:30:12 Holger Freyther wrote:
I hope that this is not a common question. I have read doc/README.LED, compiled in the GPIO LED driver, provided my GPIO number, enabled the LED command and then noticed that "led 0 on" didn't do what I wanted.
It appears that the semantic of "state" in __led_set(mask, state) is used in two different ways.
1.) status_led_set is using STATUS_LED_ON|STATUS_LED_OFF for the state parameter. 2.) cmd_led.c is using 0|1 when calling __led_set.
The confusing is in the implementation as well. 1.) drivers/misc/gpio_led.c expects it to be STATUS_LED_* 2.) board/ti/beagle/led.c wants 0|1
Which part of the code is right? Will a patch to use an enum for the state be appreciated?
i would lean towards cmd_led.c needing to be updated. the gpio_led.c was written with any eye towards how the status led framework is used in the rest of the tree, not for people manually poking the state. so in that regard, it works fine -- everyone calls status_led_set(..., STATUS_LED_{OFF,ON}). -mike
participants (2)
-
Holger Freyther
-
Mike Frysinger