linux-kernel - Re: [PATCH v5 05/26] leds: core: Add support for composing LED class device names

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: <CACRpkdYdqKZVKSaQB0THi=iZcRT04EKX2-85__Hw1f53o8vsuw@mail.gmail.com>
Date:   Fri, 28 Jun 2019 09:46:14 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>
Cc:     Linux LED Subsystem <linux-leds@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Pavel Machek <pavel@....cz>, Rob Herring <robh@...nel.org>,
        Dmitry Torokhov <dtor@...gle.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Dan Murphy <dmurphy@...com>,
        Baolin Wang <baolin.wang@...aro.org>,
        Daniel Mack <daniel@...que.org>,
        Oleh Kravchenko <oleg@....org.ua>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Simon Shields <simon@...eageos.org>
Subject: Re: [PATCH v5 05/26] leds: core: Add support for composing LED class
 device names

On Sun, Jun 9, 2019 at 8:08 PM Jacek Anaszewski
<jacek.anaszewski@...il.com> wrote:

> Add generic support for composing LED class device name. The newly
> introduced led_compose_name() function composes device name according
> to either <color:function> or <devicename:color:function> pattern,
> depending on the configuration of initialization data.
>
> Backward compatibility with in-driver hard-coded LED class device
> names is assured thanks to the default_label and devicename properties
> of newly introduced struct led_init_data.
>
> In case none of the aforementioned properties was found, then, for OF
> nodes, the node name is adopted for LED class device name.
>
> At the occassion of amending the Documentation/leds/leds-class.txt
> unify spelling: colour -> color.
>
> Alongside these changes added is a new tool - tools/leds/get_led_device_info.sh.
> The tool allows retrieving details of a LED class device's parent device,
> which proves that using vendor or product name for devicename part
> of LED name doesn't convey any added value since that information had been
> already available in sysfs. The script performs also basic validation
> of a LED class device name.
>
> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@...il.com>
> Cc: Baolin Wang <baolin.wang@...aro.org>
> Cc: Pavel Machek <pavel@....cz>
> Cc: Dan Murphy <dmurphy@...com>
> Cc: Daniel Mack <daniel@...que.org>
> Cc: Linus Walleij <linus.walleij@...aro.org>
> Cc: Oleh Kravchenko <oleg@....org.ua>
> Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>
> Cc: Simon Shields <simon@...eageos.org>

This is good progress on trying to bring order in chaos.

A problem with LEDs is that it invites bikeshedding because it is too
relateable.

So by the motto "rough consensus and running code":
Reviewed-by: Linus Walleij <linus.walleij@...aro.org>

Yours,
Linus Walleij