On Tue, 2019-11-19 at 20:52 +0100, Enrico Weigelt, metux IT consult wrote: > On 18.11.19 11:38, Vaittinen, Matti wrote: > > Hi, > > > > a) existing DT's (in the field) become incompatible with newer > > > kernel versions > > > > This was my main concern. This of course would not mean that we > > could > > not take this approach for new LED controller drivers - but that > > would > > (probably) lead to dual led registration interface > > Maybe just a flag for that ? Perhaps the driver could also specify a > list of node names for the LEDs, so led-core can do the lookup for > them. This is actually close to what I suggested in my other email to Jacek. > > > b) existing userlands that rely on speicific LED names become > > > incomatible with newer kernel versions. > > > > I didn't even think this far, but yes, I see... LED node name might > > be > > reflected in user-space LED name. I won't start arguing if this is > > sane > > or not - this is what we seem to be living with today :) > > Especially in embedded world, this can really make sense: > applications > just use a defined LED name, no matter which board it's running on. > Convention over configuration. Definitely. I am all for generating the name based on LED _function_ - no matter what the board is. I like the LED name generation base on 'function' DT property. But node names tend to be somewhat generic - or board specific (to avoid collisions). So using node name directly is not (as far as my understanding goes - which is limited on this topic) optimal for guaranteeing coherent view (across the boards) for user- space. Wow, what a nice sentence for non native English speaker like me xD > Personally, I also like to use LED subsystem as frontend for things > like > gpio-driven relais, etc, and assign semantically fitting names > instead > of "technical" ones, This is outside of my experience so I just believe what you say :) > > > I didn't invest too much of time on this yet - but at first glimpse > > it > > seemed that at least some of the drivers did use reg - property > > with > > fixed value to do the matching. Those could set the property name > > to > > 'reg' and value to 'X' and leave the DT node lookup and common > > property > > parsing to the LED core. If my patch won't get too big objection > > (and > > if no fatal flaws are found from the idea) - then I might try and > > find > > the time to do some follow-up patches simplifying existing LED > > drivers... > > Sounds good :) > > > --mtx >
