linux-kernel - Re: [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver

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: <54dcb6cc-7765-f64c-33fd-2920f3865153@ti.com>
Date:   Thu, 17 May 2018 09:34:37 -0500
From:   Dan Murphy <dmurphy@...com>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Pavel Machek <pavel@....cz>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>
Subject: Re: [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Jacek

On 05/16/2018 04:17 PM, Dan Murphy wrote:
<snip>

>>>>
>>>>
>>>>>>> +               if (!ret)
>>>>>>
>>>>>> if (ret) sounds more natural. And better just to split
>>>>>>
>>>>>>> +                       snprintf(led->led_name, sizeof(led->led_name),
>>>>>>> +                               "%s:%s", led->led_node->name, name);
>>>>>>> +               else
>>>>>>> +                       snprintf(led->led_name, sizeof(led->led_name),
>>>>>>> +                               "%s:torch", led->led_node->name);
>>>>>>
>>>>>> const char *tmp;
>>>>>>
>>>>>> ret = device_property_read_...(&tmp);
>>>>>> if (ret)
>>>>>>   tmp = ...
>>>>>> sprintf(...);
>>>
>>> We're no longer taking devicename section of a LED class device name
>>> from DT, so it will look differently anyway.
>>>

So in adding the device_property code I think we again are reaching the LED label issue.
In ARM with DT we would take the parent device node name and append it to the label
if the optional label property was not available.  In migrating to the device_property
APIs we don't or can't depend on that parent node anymore.

So for the case where the label property does not exist should we use a hard coded name
or should we try to use the name from a device_id table.

This is how we did this for the leds-lp8860 driver.  If the label did not exist we used the
i2c_device_id table and pulled the string from there.

Thoughts?

<snip>

-- 
------------------
Dan Murphy