Re: [PATCH v1 1/1] leds: Unexport of_led_get()

["andriy.shevchenko@linux.intel.com" <andriy.shevchenko@linux.intel.com>]

On Wed, Dec 10, 2025 at 06:30:06PM +0000, Jonathan Brophy wrote:
> > Can you elaborate? I think your downstream code (I have no other ideas where you Q came from)
> > uses some outdated approaches. Try to look at the problem from the level of the existing APIs and 
> > frameworks. We shouldn't really have such an issue (but it might be some special use case, I admit).
> 
> I'm trying to create a virtual led driver but with the removal of
> of_led_get() im struggling to find a way to make it work.

Still it's unclear to me what it means and how the code look like.
Perhaps you need to send some patches for the discussion (maybe as
RFC if you think they are not upstream ready).

> I investigated alternative approaches to avoid of_led_get() dependency, including:
> 
> Direct class_find_device(led_class, ...) calls - Failed because led_class is
> not exported (static in led-class.c)

> bus_find_device_by_fwnode() - Failed because LED devices are class devices,
> not bus devices

> Manual iteration via class_dev_iter_init() - Failed because I cannot obtain
> the led_class pointer
> 
> of_led_get() appears to be the only viable solution because:
> 
> It's the only exported function with access to the non-exported leds_class
> It handles GPIO LED matching quirks (parent node vs child node)
> It provides proper reference counting via led_put()
> 
> Should led_class be exported, or is there a planned fwnode-based alternative
> to of_led_get?

You can introduce it as a precursor to your driver. But OF centric variant
gone for good, we use fwnode in a new code.

-- 
With Best Regards,
Andy Shevchenko