linux-kernel - Re: [PATCH RFC] leds: leds-lp50xx: Handle reg to get correct multi

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: <449cf572-f637-42c9-b804-aaf74178e96b@gmail.com>
Date: Wed, 14 May 2025 21:55:43 +0200
From: Jacek Anaszewski <jacek.anaszewski@...il.com>
To: Johan Adolfsson <Johan.Adolfsson@...s.com>, Lee Jones <lee@...nel.org>,
 Pavel Machek <pavel@...nel.org>
Cc: "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Kernel <Kernel@...s.com>
Subject: Re: [PATCH RFC] leds: leds-lp50xx: Handle reg to get correct
 multi_index

Hi Johan,

On 5/14/25 16:34, Johan Adolfsson wrote:
> From: Jacek Anaszewski <jacek.anaszewski@...il.com>
> Sent: Tuesday, May 13, 2025 21:52
> To: Johan Adolfsson; Lee Jones; Pavel Machek
> Cc: linux-leds@...r.kernel.org; linux-kernel@...r.kernel.org; Kernel
> Subject: Re: [PATCH RFC] leds: leds-lp50xx: Handle reg to get correct multi_index
> ..
>>>                        }
>>> +                     ret = fwnode_property_read_u32(led_node, "reg", &multi_index);
>>> +                     if (ret) {
>>> +                             multi_index = num_colors;
>>
>> Why not to fail if 'reg' parsing fails?
>> It is marked required in DT bindings [0].
> 
> I didn't want to start failing if reg is missing since it has never been handled until now, despite what the doc says since 2022...

There is one in-tree user [0], and we will need to patch it as well,
because it uses reg 0,1,2 for each RGB LED module, instead of iout
numbers as it will be after your change.

We will need to also state clearly in the bindings that 'reg' property
maps to iouts for the non-banked RGB LED modules.

For banked RGB LED modules it is more tricky, because there is one
LED multicolor class device created for them. Probably to be correct
we would need make the 'reg' properties in the subnodes also arrays
reflecting iouts that will be governed by BANK_A_Color, BANK_B_Color,
and BANK_C_Color registers respectively. And DT parser in the driver
would need to enforce proper iout definition for the banked modules

E.g. the multi-led@3 node from the example should look like below:

             multi-led@3 {
                 #address-cells = <1>;
                 #size-cells = <0>;
                 reg = <0x3>, <0x4>, <0x5>;
                 color = <LED_COLOR_ID_RGB>;
                 function = LED_FUNCTION_STANDBY;

                 led@9 {
                     reg = <0x9>, <0xc>, <0xf>;
                     color = <LED_COLOR_ID_RED>;
                 };

                 led@a {
                     reg = <0xa>, <0xd>, <0x10>;
                     color = <LED_COLOR_ID_GREEN>;
                 };

                 led@b {
                     reg = <0xb>, <0xe>, <0x11>;
                     color = <LED_COLOR_ID_BLUE>;
                 };


[0] arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-fuji.dts

-- 
Best regards,
Jacek Anaszewski