On Sun, Jun 9, 2019 at 8:08 PM Jacek Anaszewski <[email protected]> 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 <[email protected]> > Cc: Baolin Wang <[email protected]> > Cc: Pavel Machek <[email protected]> > Cc: Dan Murphy <[email protected]> > Cc: Daniel Mack <[email protected]> > Cc: Linus Walleij <[email protected]> > Cc: Oleh Kravchenko <[email protected]> > Cc: Sakari Ailus <[email protected]> > Cc: Simon Shields <[email protected]> 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 <[email protected]> Yours, Linus Walleij
