On Sat 2020-07-11 23:01:11, Ondřej Jirman wrote: > Hello Pavel, > > On Sat, Jul 11, 2020 at 12:04:09PM +0200, Pavel Machek wrote: > > Hi! > > > > > Some LED controllers may come with an internal HW triggering mechanism > > > for the LED and an ability to switch between user control of the LED, > > > or the internal control. One such example is AXP20X PMIC, that allows > > > wither for user control of the LED, or for internal control based on > > > the state of the battery charger. > > > > > > Add support for registering per-LED device trigger. > > > > > > Names of private triggers need to be globally unique, but may clash > > > with other private triggers. This is enforced during trigger > > > registration. Developers can register private triggers just like > > > the normal triggers, by setting private_led to a classdev > > > of the LED the trigger is associated with. > > > > What about this? Should address Marek's concerns about resource use... > > What concerns? Marek's concerns seem to be about case where we register > a trigger for (each led * self-working configuration) which I admit > can be quite a lot of triggers if there are many functions. But that's > not my proposal. > > My proposal is to only register on trigger per LED at most. So on my > system that's 1 extra trigger and on Marek's system that'd be 48 new > triggers. Neither seems like a meaningful problem from resource > use perspective. So.. 48 triggers on Marek's systems means I'll not apply your patch. Please take a look at my version, it is as simple and avoids that problem. If it works for you, you can submit it properly and I'll likely accept it. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: PGP signature
