Hi, On 12/7/22 01:25, Linus Walleij wrote: > On Mon, Dec 5, 2022 at 4:01 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > >> An alternative approach, would be to add support for LED >> lookup tables to the LED class code (like we already have >> for GPIOs) and use this to allow tying a LED classdev to >> a struct device on non devicetree platforms. >> >> Given the problems with the swnode approach from above >> I believe that this would actually be better then >> the swnode approach. >> >> Lookup tables like this use device-names, so we don't need >> to have swnode-s ready for both the provider and the consumer >> at the time of adding the lookup table entry. Instead all >> that is necessary is to know the device-names of both >> the provider and the consumer which are both known in >> advance. > > I think this looks like a good idea. > > We attach other resources such as clocks, regulators, > DMA channels, GPIOs exactly this way. So why not LEDs? > > As GPIO maintainer I every now and then get a suggestion > like this to "just let this pass as a GPIO because it makes > my life so much easier", but it is the same curse as the > input subsystem has: it is versatile and well engineered so > it starts to look like a golden hammer (everything start to > look like nails). > > But we are two GPIO maintainers and right now Bartosz > does the majority of the work, and if he thinks it's the best > idea ever I will certainly reconsider. Ok, I will give the LED lookup table approach a go and post a new series replacing this one when its ready. Feel free to drop this series from your queue. (Note given that that is going to be a whole new approach I plan to start the new series at v1 again). Regards, Hans
