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

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

[Andy Shevchenko]

There are no users outside the module.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/leds/led-class.c | 3 +--
 include/linux/leds.h     | 1 -
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index eaeb433dcc3e..859056dd1dee 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -256,7 +256,7 @@ static const struct class leds_class = {
  * Returns the LED device parsed from the phandle specified in the "leds"
  * property of a device tree node or a negative error-code on failure.
  */
-struct led_classdev *of_led_get(struct device_node *np, int index)
+static struct led_classdev *of_led_get(struct device_node *np, int index)
 {
 	struct device *led_dev;
 	struct device_node *led_node;
@@ -270,7 +270,6 @@ struct led_classdev *of_led_get(struct device_node *np, int index)
 
 	return led_module_get(led_dev);
 }
-EXPORT_SYMBOL_GPL(of_led_get);
 
 /**
  * led_put() - release a LED device
diff --git a/include/linux/leds.h b/include/linux/leds.h
index b3f0aa081064..b16b803cc1ac 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -294,7 +294,6 @@ void led_remove_lookup(struct led_lookup_data *led_lookup);
 struct led_classdev *__must_check led_get(struct device *dev, char *con_id);
 struct led_classdev *__must_check devm_led_get(struct device *dev, char *con_id);
 
-extern struct led_classdev *of_led_get(struct device_node *np, int index);
 extern void led_put(struct led_classdev *led_cdev);
 struct led_classdev *__must_check devm_of_led_get(struct device *dev,
 						  int index);
-- 
2.47.2

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

[Jonathan Brophy]

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

it would seem the removal of this function has removed the only way to search led phandles the device tree.

The devm version works functionally different and is not a replacement.

virtual led grouping drivers are unable to match phandles.

is there plans to create a fwnode_led_get() replacment for of_led_get ?

The problem is gpio leds don't have fwnode properties so searching by platform does not work.

Reguards jonathan

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

[andriy.shevchenko]

On Wed, Dec 10, 2025 at 10:43:38AM +0000, Jonathan Brophy wrote:
>  [PATCH v1 1/1] leds: Unexport of_led_get()
> 
> it would seem the removal of this function has removed the only way to search
> led phandles the device tree.

Are you talking about upstream drivers that now regressed somehow or is it
about downstream?

> The devm version works functionally different and is not a replacement.
> virtual led grouping drivers are unable to match phandles.
> is there plans to create a fwnode_led_get() replacment for of_led_get ?

When there will be a user that may not call existing APIs.

> The problem is gpio leds don't have fwnode properties so searching by
> platform does not work.

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).


-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Brophy]

> 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.

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?



With Best Regards,
Jonathan brophy

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

[andriy.shevchenko]

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

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

[Jonathan Brophy]

> 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).
 
yes, I think  I will have to do this. 
I'm developing a virtual LED grouping driver that needs to reference existing LEDs via Device Tree phandles.
I plan it to expose the group as a singular or multicolor led.

as below I need to resolve the phandles of led_system_red and led_system_blue but there does not seem to be a way to do it under 
The current api's:

DTS
	virtual_led_set: virtual-monocromatic-leds {
		compatible = "leds-group-virtualcolor";

		led_virtual_violet: virtual-violet {
			color = <LED_COLOR_ID_VIOLET>;
			function = LED_FUNCTION_STATUS;
			leds = <&led_system_red>, <&led_system_blue>;
			
		};

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

I think this may be the only way forward.
Removal of this function makes the virtual led driver under the current api impossible.
I have my driver working with a of bridge following V4L2 fwnode helpers.
v4l2_fwnode_endpoint_parse() and v4l2_fwnode_parse_link() has OF bridges where only DT bindings exist.
Drivers walk endpoints via struct fwnode_handle, then call helpers that internally translate to OF nodes when needed.
I have followed the same architecture on my driver on an older kernel successfully.

I was thinking a simple replacement for the of_led_get() with a patch something like below but I need to formalise and test further:

// In drivers/leds/led-class.c

/**
 * led_get_by_fwnode - Get LED classdev by firmware node reference
 * @fwnode: Firmware node handle pointing to LED
 *
 * Returns LED classdev on success, ERR_PTR on failure.
 * Caller must call led_put() when done.
 */
struct led_classdev *led_get_by_fwnode(struct fwnode_handle *fwnode)
{
    struct device *led_dev;
    struct led_classdev *cdev;
    
    led_dev = class_find_device(leds_class, NULL, fwnode, 
                                led_match_fwnode);
    if (!led_dev)
        return ERR_PTR(-EPROBE_DEFER);
    
    cdev = dev_get_drvdata(led_dev);
    if (!cdev) {
        put_device(led_dev);
        return ERR_PTR(-ENODEV);
    }
    
    return cdev;
}
EXPORT_SYMBOL_GPL(led_get_by_fwnode);

void led_put(struct led_classdev *cdev)
{
    if (cdev && cdev->dev)
        put_device(cdev->dev);
}
EXPORT_SYMBOL_GPL(led_put);

With Best Regards,
Jonathan brophy

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

[Alexander Dahl]

Hello Andy,

Am Wed, Dec 10, 2025 at 11:54:19PM +0200 schrieb 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 guess it is about the patch series Jonathan already sent?

https://lore.kernel.org/linux-leds/20251019092331.49531-1-professorjonny98@gmail.com/T/#u

Greets
Alex

> 
> > 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
> 
> 
> 

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

[andriy.shevchenko]

On Thu, Dec 11, 2025 at 01:34:10PM +0100, Alexander Dahl wrote:
> Am Wed, Dec 10, 2025 at 11:54:19PM +0200 schrieb 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 guess it is about the patch series Jonathan already sent?

I don't know, I wasn't in Cc list there. And it seems the series got a lot of
useful comments already. So. if next version being Cc'ed to me, I would review
it. (Going ahead: the series, if survives the approach, has a lot of style and
related mistakes, like wrong kernel version and data in the ABI documentation.)

> https://lore.kernel.org/linux-leds/20251019092331.49531-1-professorjonny98@gmail.com/T/#u


-- 
With Best Regards,
Andy Shevchenko

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

[andriy.shevchenko]

On Thu, Dec 11, 2025 at 12:49:12AM +0000, Jonathan Brophy wrote:
> > 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).

Note, your email user agent is broken or misconfigured, it moves all lines to
be unwrapped. Please, configure it or change to one that works better with
the Linux related mailing lists.

> yes, I think  I will have to do this. 
> I'm developing a virtual LED grouping driver that needs to reference existing
> LEDs via Device Tree phandles.
> I plan it to expose the group as a singular or multicolor led.
> 
> as below I need to resolve the phandles of led_system_red and led_system_blue
> but there does not seem to be a way to do it under 
> The current api's:
> 
> DTS
> 	virtual_led_set: virtual-monocromatic-leds {
> 		compatible = "leds-group-virtualcolor";
> 
> 		led_virtual_violet: virtual-violet {
> 			color = <LED_COLOR_ID_VIOLET>;
> 			function = LED_FUNCTION_STATUS;
> 			leds = <&led_system_red>, <&led_system_blue>;

> 		};

Not an expert here, but sounds like an aggregator approach (gpio-aggregator)
design of which can be considered.

> > You can introduce it as a precursor to your driver. But OF centric variant
> > gone for good, we use fwnode in a new code.
> 
> I think this may be the only way forward.
> Removal of this function makes the virtual led driver under the current api
> impossible.
> I have my driver working with a of bridge following V4L2 fwnode helpers.
> v4l2_fwnode_endpoint_parse() and v4l2_fwnode_parse_link() has OF bridges
> where only DT bindings exist.
> Drivers walk endpoints via struct fwnode_handle, then call helpers that
> internally translate to OF nodes when needed.
> I have followed the same architecture on my driver on an older kernel
> successfully.
> 
> I was thinking a simple replacement for the of_led_get() with a patch
> something like below but I need to formalise and test further:

At glance something like this (of course the proposed code needs some
polishing).

-- 
With Best Regards,
Andy Shevchenko