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. Yours, Linus Walleij
