lkml.org 
[lkml]   [2017]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH/RFC] DT: leds: Fix 'label' property description and add 'colour' property
From
Date
cc devicetree@vger.kernel.org

On 12/14/2017 10:35 PM, Jacek Anaszewski wrote:
> On 12/11/2017 05:27 PM, Rob Herring wrote:
>> On Mon, Dec 4, 2017 at 4:43 AM, Pavel Machek <pavel@ucw.cz> wrote:
>>> Hi!
>>>
>>>> Label property was imposed a uniqueness requirement, which was erroneous,
>>>> since ePAPR defines it to "a human readable string describing a device".
>>
>> But it still needs to be unique to be useful. It's just unique from a
>
> This patch is a follow-up of your following statement from [0]:
>
>>>>>>>>
> I really dislike how this naming convention is used for label. label is
> supposed to be the phyically identifiable name. Having the devicename
> defeats that. Perhaps color, too. We'd be better off with a color
> property. It seems we're overloading the naming with too many things.
> Now we're adding device association.
> <<<<<<<
>
>
> In effect, I intended to remove the uniqueness requirement for the
> label since the label alone doesn't make a LED class device name
> in case of many current LED class drivers.
>
> Instead I inferred from your message that label should contain only
> LED function. Therefore I'm splitting colour (maybe color would fit
> better here, but adopted the spelling from
> Documentation/leds/leds-class.txt, to be decided which one fits better.)
>
> But see below.
>
>> different perspective. Ideally, if you had a block diagram level
>> drawing of a device or board showing LEDs (and displays with
>> backlights), you would simply take the labels from that drawing.
>>
>>>> Also the binding description misleadingly suggested direct usage of label
>>>> for LED class device name, whereas it should only define a LED function.
>>>>
>>>> Therefore an additional 'colour' property is being introduced, which together
>>>> with the parent DT node name used for devicename shall be used for naming LED
>>>> class device according to the patterh
>>>> <devicename>:<colour>:<function>.
>>>
>>>
>>>> -- label : The label for this LED. If omitted, the label is taken from the node
>>>> - name (excluding the unit address). It has to uniquely identify
>>>> - a device, i.e. no other LED class device can be assigned the same
>>>> - label.
>>>> +- label : The label for this LED. It should describe its function. If omitted,
>>>> + the label is taken from the node name (excluding the unit address).
>>>
>>> So the label contains "as1235:green:capslock"? I guess it might be
>>> nice to mention that. Or just the "capslock" part?
>>>
>>> Also.. it would be good to start pushing for more consistency in the
>>> labels: I have these on the thinkpad:
>>>
>>> input5::scrolllock/ tpacpi::dock_status2/ tpacpi::unknown_led/
>>> mmc0::/ tpacpi:green:batt/ tpacpi::unknown_led2/
>>> phy0-led/ tpacpi:orange:batt/ tpacpi::unknown_led3/
>>> tpacpi::bay_active/ tpacpi::power/
>>>
>>> On embedded system, I'd like to see <devicename> to corespond
>>> to.. device the led belongs to, as opposed to name of the chip that
>>> drives the led. Maybe we should do 'main_camera:white:flash' instead of
>>> 'as4132:white:flash' because userspace already has information on what
>>> chip it is (sysfs paths), but can not easily figure out to which
>>> device the flash belongs.
>>
>> A couple of points:
>>
>> I already mentioned DT node naming policies in the lm3692x thread, so
>> I won't repeat here.
>>
>> Using the node name is not going to guarantee uniqueness in the names.
>> Even if you added the unit address it would still not. I can easily
>> have 2 or more LED driver chips at the same I2C address on different
>> buses. The only guaranteed unique name is the full DT path. Once
>> you've added some OS specific numbering to make device names unique,
>> then I'm not sure there's a lot of value in naming things after what
>> drives them. You can walk the sysfs hierarchy to determine that
>> anyway.
>>
>> A case I care about is I have a family of boards that all have a
>> common defined set of 4 LEDs. They could be driven by anything, but I
>> want the same interface presented to userspace across boards.
>
> In effect it looks like we should drop devicename section from
> the LED class devicename pattern, label should describe only
> LED function and additional color property could be introduced,
> to be concatenated with LED function as a final LED class device
> name.
>
>
> [0] https://www.mail-archive.com/linux-media@vger.kernel.org/msg119473.html
>

\
 
 \ /
  Last update: 2017-12-17 13:51    [W:0.064 / U:0.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site