On Sun, Jun 9, 2019 at 8:08 PM Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx> 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@xxxxxxxxx> > Cc: Baolin Wang <baolin.wang@xxxxxxxxxx> > Cc: Pavel Machek <pavel@xxxxxx> > Cc: Dan Murphy <dmurphy@xxxxxx> > Cc: Daniel Mack <daniel@xxxxxxxxxx> > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> > Cc: Oleh Kravchenko <oleg@xxxxxxxxxx> > Cc: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> > Cc: Simon Shields <simon@xxxxxxxxxxxxx> 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@xxxxxxxxxx> Yours, Linus Walleij
