linux.git/drivers/leds/led-class.c, branch v5.5

leds: core: Fix devm_classdev_match to reference correct structure

2019-11-03T16:38:51+00:00

Fix the devm_classdev_match pointer initialization to the correct
structure type.

Signed-off-by: Dan Murphy 
Signed-off-by: Pavel Machek

leds: remove PAGE_SIZE limit of /sys/class/leds//trigger

2019-11-03T16:38:14+00:00

Reading /sys/class/leds//trigger returns all available LED triggers.
However, the size of this file is limited to PAGE_SIZE because of the
limitation for sysfs attribute.

Enabling LED CPU trigger on systems with thousands of CPUs easily hits
PAGE_SIZE limit, and makes it impossible to see all available LED triggers
and which trigger is currently activated.

We work around it here by converting /sys/class/leds//trigger to
binary attribute, which is not limited by length. This is _not_ good
design, do not copy it.

Signed-off-by: Akinobu Mita 
Cc: "Rafael J. Wysocki" 
Cc: Pavel Machek 
Cc: Dan Murphy A
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Pavel Machek

leds: Allow to call led_classdev_unregister() unconditionally

2019-08-26T18:03:58+00:00

If in the certain driver the LED is optional, and it's a majority of them,
the call of led_classdev_unregister() still requires some additional
checks.

The usual pattern on unregistering is to check for NULL, but we also check
for IS_ERR() in case device_create_with_groups() fails.

The change will reduce a burden in a lot of drivers to repeatedly check
for above conditions.

Signed-off-by: Andy Shevchenko 
Signed-off-by: Jacek Anaszewski

leds: Switch to use fwnode instead of be stuck with OF one

2019-08-23T21:39:37+00:00

There is no need to be stuck with OF node when we may use agnostic
firmware node instead.

It allows users to get property if needed independently of provider.

Note, some OF parts are left because %pfw [1] is in progress.

[1]: https://lore.kernel.org/patchwork/cover/1054863/

Signed-off-by: Andy Shevchenko 
Signed-off-by: Jacek Anaszewski

Merge tag 'generic_lookup_helpers' into for-next

2019-07-30T20:36:31+00:00

Generic Device Lookup Helpers

Persistent tag for others to pull this branch from

Based on patch series from Suzuki K Poulose 
with Subject: [PATCH v3 0/7] drivers: Add generic device lookup helpers

Signed-off-by: Greg Kroah-Hartman 

* tag 'generic_lookup_helpers':
  platform: Add platform_find_device_by_driver() helper
  drivers: Add generic helper to match any device
  drivers: Introduce device lookup variants by ACPI_COMPANION device
  drivers: Introduce device lookup variants by device type
  drivers: Introduce device lookup variants by fwnode
  drivers: Introduce device lookup variants by of_node
  drivers: Introduce device lookup variants by name

drivers: Introduce device lookup variants by name

2019-07-30T11:07:41+00:00

Add a helper to match the device name for device lookup. Also
reuse this generic exported helper for the existing bus_find_device_by_name().
and add similar variants for driver/class.

Cc: Alessandro Zummo 
Cc: Alexander Aring 
Cc: Alexander Shishkin 
Cc: Arnd Bergmann 
Cc: Dan Murphy 
Cc: Harald Freudenberger 
Cc: Heiko Carstens 
Cc: Jacek Anaszewski 
Cc: Lee Jones 
Cc: linux-leds@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-wpan@vger.kernel.org
Cc: Maxime Coquelin 
Cc: Pavel Machek 
Cc: Peter Oberparleiter 
Cc: "Rafael J. Wysocki" 
Cc: Stefan Schmidt 
Cc: Greg Kroah-Hartman 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Suzuki K Poulose 
Reviewed-by: Heikki Krogerus 
Acked-by: Alexandre Belloni 
Link: https://lore.kernel.org/r/20190723221838.12024-2-suzuki.poulose@arm.com
Signed-off-by: Greg Kroah-Hartman

leds: core: Add support for composing LED class device names

2019-07-25T18:07:52+00:00

Add generic support for composing LED class device name. The newly
introduced led_compose_name() function composes device name according
to either  or  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 
Cc: Baolin Wang 
Cc: Dan Murphy 
Cc: Daniel Mack 
Cc: Linus Walleij 
Cc: Oleh Kravchenko 
Cc: Sakari Ailus 
Cc: Simon Shields 
Reviewed-by: Linus Walleij 
Acked-by: Pavel Machek

leds: class: Improve LED and LED flash class registration API

2019-07-25T18:07:50+00:00

Replace of_led_classdev_register() with led_classdev_register_ext(), which
accepts easily extendable struct led_init_data, instead of the fixed
struct device_node argument. The latter can be now passed in an fwnode
property of the struct led_init_data.

The modification is driven by the need for passing additional arguments
required for the forthcoming generic mechanism for composing LED names.
Currently the LED name is conveyed in the "name" char pointer property of
the struct led_classdev. This is redundant since LED class device name
is accessible throughout the whole LED class device life time via
associated struct device's kobj->name property.

The change will not break any existing clients since the patch alters
also existing led_classdev{_flash}_register() macro wrappers, that pass
NULL in place of init_data, which leads to using legacy name
initialization path basing on the struct led_classdev's "name" property.

Three existing users of devm_of_led_classdev_registers() are modified
to use devm_led_classdev_register(), which will not impact their
operation since they in fact didn't need to pass struct device_node on
registration from the beginning.

Signed-off-by: Jacek Anaszewski 
Cc: Baolin Wang 
Cc: Dan Murphy 
Cc: Daniel Mack 
Cc: Linus Walleij 
Cc: Oleh Kravchenko 
Cc: Sakari Ailus 
Cc: Simon Shields 
Acked-by: Pavel Machek

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

2019-06-19T15:09:55+00:00

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Enrico Weigelt 
Reviewed-by: Kate Stewart 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman

leds: avoid races with workqueue

2019-05-02T20:54:51+00:00

There are races between "main" thread and workqueue. They manifest
themselves on Thinkpad X60:

This should result in LED blinking, but it turns it off instead:

    root@amd:/data/pavel# cd /sys/class/leds/tpacpi\:\:power
    root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger
    root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger

It should be possible to transition from blinking to solid on by echo
0 > brightness; echo 1 > brightness... but that does not work, either,
if done too quickly.

Synchronization of the workqueue fixes both.

Fixes: 1afcadfcd184 ("leds: core: Use set_brightness_work for the blocking op")
Signed-off-by: Pavel Machek 
Signed-off-by: Jacek Anaszewski