I wrote: > I'd like to control a LED to possibly be any of: > > * Off > * On > * Blinking > > I've had this working fine in 3.14.x kernel. > > But when upgrading to 4.4.x, I found that the transition from "blinking" > to "on" didn't work. Namely, if it's blinking and then I call > led_set_brightness(led_cdev, LED_FULL), then it wouldn't work (I can't > remember if it turned off, or remained blinking; it wasn't on anyway). > I worked around it by calling led_set_brightness(led_cdev, LED_OFF) just > before led_set_brightness(led_cdev, LED_FULL). > > Now I have upgraded to 4.9.x, and found that the transition from > "blinking" to "on" again isn't working. The LED ends up being off > instead of on. > > Examining the code of led_set_brightness(): > > * Behaviour is different depending on whether the brightness is LED_OFF > (it schedules the blink to be turned off "soon") or other (it alters > the brightness of subsequent blinks). > * It looks as though there are race conditions in the transition from > blinking to steady off -- it schedules the blink to be turned off > "soon", so it's difficult to guarantee a reliable transition from > blinking to on/off. > > The combination of the above two points makes it seem difficult to > robustly go from blinking to off/on. > > So, my questions are: > > * What is the correct way to use the API to reliably control an LED for > a combination of off/on/blinking? > * Is my above analysis of the code correct, so that there are indeed > race conditions going from blinking to off, leading to undefined > behaviour? Can that be fixed? I also thought I could perhaps use led_blink_set_oneshot() to effectively turn the LED on or off in a blink-compatible way. But, I see that if a one-shot blink is in-progress, then any attempt to change the 'invert' parameter is ineffective because the function exits early. -- Craig McQueen
