[PATCH 2/6] led-uclass: honour ->label field populated by driver's own .bind

[Marek Vasut]

On 11/14/23 13:11, Christian Gmeiner wrote:
> ping
> 
> Am Mo., 23. Okt. 2023 um 12:45 Uhr schrieb Marek Vasut <marex at denx.de>:
>>
>> On 10/23/23 10:51, Rasmus Villemoes wrote:
>>> On 19/10/2023 15.54, Marek Vasut wrote:
>>>> On 10/19/23 11:58, Rasmus Villemoes wrote:
>>>>> If the driver's own .bind method has populated uc_plat->label, don't
>>>>> override that. This is necessary for an upcoming driver for ti,lp5562,
>>>>> where the DT binding unfortunately says to use "chan-name" and not
>>>>> "label".
>>>>>
>>>>> Signed-off-by: Rasmus Villemoes <rasmus.villemoes at prevas.dk>
>>>>> ---
>>>>>     drivers/led/led-uclass.c | 4 +++-
>>>>>     1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
>>>>> index 5a5d07b9a7..0232fa84de 100644
>>>>> --- a/drivers/led/led-uclass.c
>>>>> +++ b/drivers/led/led-uclass.c
>>>>> @@ -71,7 +71,9 @@ static int led_post_bind(struct udevice *dev)
>>>>>         struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev);
>>>>>         const char *default_state;
>>>>>     -    uc_plat->label = dev_read_string(dev, "label");
>>>>> +    if (!uc_plat->label)
>>>>> +        uc_plat->label = dev_read_string(dev, "label");
>>>>> +
>>>>
>>>> One thing I have to wonder about is, why does this controller have label
>>>> property in the top-level node , what is that used for ?
>>>>
>>>> (see Linux Documentation/devicetree/bindings/leds/leds-lp55xx.yaml)
>>>>
>>>> Reviewed-by: Marek Vasut <marex at denx.de>
>>>
>>> Reading the linux driver, it seems that the top-level label, if any, is
>>> used as part of the naming for individual channels if they don't have
>>> individual chan-name properties:
>>>
>>>
>>>           if (pdata->led_config[chan].name) {
>>>                   led->cdev.name = pdata->led_config[chan].name;
>>>           } else {
>>>                   snprintf(name, sizeof(name), "%s:channel%d",
>>>                           pdata->label ? : chip->cl->name, chan);
>>>                   led->cdev.name = name;
>>>           }
>>>
>>> but I think the rationale in d1188adb2dabc is a bit weak, since the only
>>> example also does have individual chan-name properties.
>>>
>>> [Complete aside: At first I thought it was related to the multi-color
>>> LED work that has been ongoing for many many years (I think there was an
>>> LWN article at some point), where this could be exposed as a single
>>> multi-color LED, as opposed to the "traditional" three/four individual
>>> LEDs. In the former case, there would only be one sysfs entry, but with
>>> attributes exposing the multicolor functionality. I must admit I don't
>>> know the status of that work, when something reaches v31,
>>> http://archive.lwn.net:8080/linux-kernel/20200722071055.GA8984@amd/t/ ,
>>> it's hard to know if it ever lands, or if pieces of it has landed.]
>>
>> +CC Pavel

I think you want to coordinate the effort with Rasmus here .