lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ