Hi! > >Why not? Normal triggers can have parameters, these new hw_* triggers > >can have parameters, too, with same semantics. > > > >But... yes, it will mean some work if you really need to support all > >the functionality, and I do think that it should be ok to just support > >a limited subset. (probably hw_on_when_charging" and > >"hw_glows_when_charging" with fixed parameters). > > Well we will also need a normal "glows_when_charging" and "on_when_charging" > because on at least one model hardware, the hw trigger does not work and > we need a software trigger to do "on/glow when charging" > > Thinking more about it, I think that for this specific case, we could > probably drop the hardware control at all since the hw cannot differentiate > between charging and full. Then we could do glow while-charging and > on when full (and AC power present). > > Yes I think that that would actually be best (glow while charging, on when full > done in sw) but how would we model this ? Create "glow-while-charging-on-when-full" trigger? :-). More concretely... I'd create one system that makes sense (glow (*) while charging, on when full), and implement that. It looks like the code already is in ./drivers/power/supply/power_supply_leds.c . When some kind of hardware control is available, you are free to use it, but charger plugin/removal is quite uncommon event so I'm not sure if that is worth effort. Using hardware for the glow effect makes better sense. Best regards, Pavel (*) or blink, for LEDs that only have on/off control. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
