[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SYAPR01MB2863A415594BCC2FCAD80876B2A1A@SYAPR01MB2863.ausprd01.prod.outlook.com>
Date: Thu, 11 Dec 2025 00:49:12 +0000
From: Jonathan Brophy <J.Brophy@...killsystems.co.nz>
To: "andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>
CC: "lee@...nel.org" <lee@...nel.org>, "linux-leds@...r.kernel.org"
<linux-leds@...r.kernel.org>, Pavel Machek <pavel@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v1 1/1] leds: Unexport of_led_get()
> 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
Powered by blists - more mailing lists