linux-kernel - Re: [PATCH v1 1/1] leds: Unexport of_led

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] [day] [month] [year] [list]

Message-ID: <aTrMV22s-c3GBgU2@smile.fi.intel.com>
Date: Thu, 11 Dec 2025 15:51:19 +0200
From: "andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>
To: Jonathan Brophy <J.Brophy@...killsystems.co.nz>
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()

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