On 20/05/16 08:25, Jacek Anaszewski wrote: > Hi Tony, > > On 05/19/2016 05:57 PM, Tony Makkiel wrote: >> Hi, >> Is there any particular reason to stipulate, (hardware) blink should be turned off, when brightness is set to 0? Following is copied from "Documentation/leds/leds-class.txt" >> >> "Setting the brightness to zero with brightness_set() callback function >> should completely turn off the LED and cancel the previously programmed >> hardware blinking function, if any." >> >> The chip driver could also use other methods for the same, keeping brightness independent of blink. >> >> For example, delay_on/off >> delay_off=0 ==> blink off, led on. >> delay_on=0 ==> blink off, led off. >> >> Or am I overlooking something? > > Setting brightness to zero not only disables blinking but also > any other active trigger. Besides, would it make sense to have > blinking enabled with brightness set to 0? I agree brightness set to 0, should turn off led. I was thinking of case when user turns led back ON with a brightness value. Ideally led comes back on blinking as was configured previously(making, brightness and blink independent). At present, once the brightness is set, blink also needs to be reconfigured. > > Anyway, we have to keep this interface as-is so as not to break > existing users of the LED API. I see your point now, Thank you. I was under the wrong impression, this could be achieved without code change. Initially, I thought of using delay_on/delay_off, to turn off blink. But with this approach, even if it will save a step initially (no need to reconfigure blink), will add additional step (re-enable trigger) to disable blink. > -- To unsubscribe from this list: send the line "unsubscribe linux-leds" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
