Nick Forbes wrote:
> The leds-gpio driver initialises all LEDs in the OFF state, however
> it incorrectly sets the "brightness" value to 255 (LED_FULL) for LEDs
> which are ".active_low". This results in the LED being off at
> initialisation, but the /sys/class/leds/xxxx/brightness value being
> 255 instead of 0.
> The attached patch corrects this and also allows each LED to be
> initialised in the ON state via ".default_trigger". The patch has
> been developed against AR7 but will work for any targets that use
> "leds-gpio", and should go in the relevant "patches" folder
> ("patches-2.6.23" for AR7).
Shouldn't the patch simply fix the line that sets the brightness?
> - led_dat->cdev.brightness = cur_led->active_low ? LED_FULL :
> LED_OFF;
> + led_dat->cdev.brightness = init_state ? LED_FULL : LED_OFF;
+ led_dat->cdev.brightness = LED_OFF;
Since the gpio_led_set function handles the inversion of that 0 value
into a non-zero value for the GPIO pin, this seems like a true bug in
the driver which should be submitted upstream.
Then you could just call gpio_led_set() in the board initialisation code.
Unless you've already submitted this patch upstream and had it approved
by the leds-gpio author, I strongly object to modifying a standard
upstream file in this manner.
You're effectively creating a permanently incompatible fork of the
leds-gpio driver with your patch, whereas I thought a goal of OpenWrt
was to push kernel patches upstream wherever possible rather than
carrying incompatible patches locally.
-- Rod
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
