[Moving this to appropriate thread with minor edits] On Tue, Jul 23, 2013 at 05:45:54PM -0700, Liam wrote: > On Tue, Jul 23, 2013 at 10:54:04AM -0700, Mark A. Greer wrote: > > NOTE: This patch violates the leds infrastructure > > driver interface since the hardware only supports > > blinking all LEDs with the same delay_on/delay_off > > rates. That is, only the LEDs that are set to blink > > will actually blink but all LEDs that are set to blink > > will blink in identical fashion. The delay_on/delay_off > > values of the last LED that is set to blink will be used > > for all of the blinking LEDs. > As written it triggers software-based blinking if the hardware cannot > perform the specified blink pattern. > > There's no value in hardware-based blinking over software UNLESS you want to > sleep the cpu to save power. If you want to save power, you don't want to > end up using software blink just to achieve a specific blink pattern. So you > should be able to disable hardware blink to obtain any blink pattern, or > enable it and save power no matter what. > > I propose, at the top of blink_set(): > if (!HWBLINK) // compile-time or runtime config option > > return EINVAL; // will use software blink > > Under the out-of-range test in blink_set(), set in-range defaults instead of > return EINVAL. Power management may or may not be an important issue on a particular board. If it is important then its not unreasonable for the sofware controlling the blinking to be aware of the hardware's constraints and to keep the blinking within those constraints. I prefer that to driver hacks. Bryan, do you have a preference? -- 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
