Commit Graph

106 Commits

Author SHA1 Message Date
Heiner Kallweit 66601a29bb leds: class: If no default trigger is given, make hw_control trigger the default trigger
If a hw_control_trigger is defined, it's usually desirable to make it
the default trigger. Therefore make it the default trigger, except
the driver explicitly set a default trigger.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/f33543de-3800-488f-a779-1fa282614462@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-07 08:47:56 +00:00
Takashi Iwai 8f2244c9af leds: class: Don't expose color sysfs entry
The commit c7d80059b0 ("leds: class: Store the color index in struct
led_classdev") introduced a new sysfs entry "color" that is commonly
created for the led classdev.  Unfortunately, this conflicts with the
"color" sysfs entry of already existing drivers such as Logitech HID
or System76 ACPI drivers.  The driver probe fails due to the conflict,
hence it leads to a severe regression with the missing keyboard, for
example.

This patch reverts partially the change in the commit above for
removing the led class color sysfs entries again for addressing the
regressions.  The newly introduced led_classdev.color field is kept as
it's already used by other driver.

Fixes: c7d80059b0 ("leds: class: Store the color index in struct led_classdev")
Reported-by: Johannes Penßel <johannes.penssel@gmail.com>
Closes: https://lore.kernel.org/r/b5646db3-acff-45aa-baef-df3f660486fb@gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218045
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218155
Link: https://bugzilla.suse.com/show_bug.cgi?id=1217172
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20231121162359.9332-1-tiwai@suse.de
Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-22 11:46:03 +00:00
Ivan Orlov 43a707ae58 leds: Make leds_class a static const structure
Now that the driver core allows for struct class to be in read-only
memory, move the leds_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.

Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
Link: https://lore.kernel.org/r/20230810174905.7997-1-ivan.orlov0322@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2023-08-18 08:43:11 +01:00
Jean-Jacques Hiblot c7d80059b0 leds: class: Store the color index in struct led_classdev
Store the color of the LED so that it is not lost after the LED's
name has been composed. This color information can then be exposed to
the user space or used by the LED consumer.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Link: https://lore.kernel.org/r/20230728153731.3742339-3-jjhiblot@traphandler.com
Signed-off-by: Lee Jones <lee@kernel.org>
2023-08-17 09:00:34 +01:00
Jean-Jacques Hiblot afb4815322 leds: Provide devm_of_led_get_optional()
Add an optional variant of devm_of_led_get(). It behaves the same as
devm_of_led_get() except where the LED doesn't exist. In this case,
instead of returning -ENOENT, the function returns NULL.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20230728153731.3742339-2-jjhiblot@traphandler.com
Signed-off-by: Lee Jones <lee@kernel.org>
2023-08-17 09:00:06 +01:00
Astrid Rost 7cd7a2995e led: led-class: Read max-brightness from devicetree
Normally, the maximum brightness is determined by the hardware, and this
property is not required. This property is used to set a software limit.
It could happen that an LED is made so bright that it gets damaged or
causes damage due to restrictions in a specific system, such as mounting
conditions.
Note that this flag is mainly used for PWM-LEDs, where it is not possible
to map brightness to current. Drivers for other controllers should use
led-max-microamp.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Astrid Rost <astrid.rost@axis.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Link: https://lore.kernel.org/r/20230703130313.548519-3-astrid.rost@axis.com
Signed-off-by: Lee Jones <lee@kernel.org>
2023-07-28 09:26:22 +01:00
Azeem Shaikh bf4a35e920 leds: Replace all non-returning strlcpy with strscpy
strlcpy() reads the entire source buffer first.
This read may exceed the destination size limit.
This is both inefficient and can lead to linear read
overflows if a source string is not NUL-terminated [1].
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with strscpy().
No return values were used, so direct replacement is safe.

[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
[2] https://github.com/KSPP/linux/issues/89

Signed-off-by: Azeem Shaikh <azeemshaikh38@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230523021451.2406362-1-azeemshaikh38@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-25 12:31:55 +01:00
Greg Kroah-Hartman 1aaba11da9 driver core: class: remove module * from class_create()
The module pointer in class_create() never actually did anything, and it
shouldn't have been requred to be set as a parameter even if it did
something.  So just remove it and fix up all callers of the function in
the kernel tree at the same time.

Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-17 15:16:33 +01:00
Miaoqian Lin da1afe8e60 leds: led-core: Fix refcount leak in of_led_get()
class_find_device_by_of_node() calls class_find_device(), it will take
the reference, use the put_device() to drop the reference when not need
anymore.

Fixes: 699a8c7c4b ("leds: Add of_led_get() and led_put()")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20221220121807.1543790-1-linmq006@gmail.com
2023-01-30 08:03:13 +00:00
Hans de Goede abc3100fcb leds: led-class: Add generic [devm_]led_get()
Add a generic [devm_]led_get() method which can be used on both devicetree
and non devicetree platforms to get a LED classdev associated with
a specific function on a specific device, e.g. the privacy LED associated
with a specific camera sensor.

Note unlike of_led_get() this takes a string describing the function
rather then an index. This is done because e.g. camera sensors might
have a privacy LED, or a flash LED, or both and using an index
approach leaves it unclear what the function of index 0 is if there is
only 1 LED.

This uses a lookup-table mechanism for non devicetree platforms.
This allows the platform code to map specific LED class_dev-s to a specific
device,function combinations this way.

For devicetree platforms getting the LED by function-name could be made
to work using the standard devicetree pattern of adding a -names string
array to map names to the indexes.

Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230120114524.408368-5-hdegoede@redhat.com
2023-01-27 11:07:11 +00:00
Hans de Goede 537bdca2a0 leds: led-class: Add __devm_led_get() helper
Add a __devm_led_get() helper which registers a passed in led_classdev
with devm for unregistration.

This is a preparation patch for adding a generic (non devicetree specific)
devm_led_get() function.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230120114524.408368-4-hdegoede@redhat.com
2023-01-27 11:06:42 +00:00
Hans de Goede fafef58ef4 leds: led-class: Add led_module_get() helper
Split out part of of_led_get() into a generic led_module_get() helper
function.

This is a preparation patch for adding a generic (non devicetree specific)
led_get() function.

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230120114524.408368-3-hdegoede@redhat.com
2023-01-27 11:06:17 +00:00
Hans de Goede 445110941e leds: led-class: Add missing put_device() to led_put()
led_put() is used to "undo" a successful of_led_get() call,
of_led_get() uses class_find_device_by_of_node() which returns
a reference to the device which must be free-ed with put_device()
when the caller is done with it.

Add a put_device() call to led_put() to free the reference returned
by class_find_device_by_of_node().

And also add a put_device() in the error-exit case of try_module_get()
failing.

Fixes: 699a8c7c4b ("leds: Add of_led_get() and led_put()")
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230120114524.408368-2-hdegoede@redhat.com
2023-01-27 11:06:03 +00:00
Sander Vanheule 495b8966f7 leds: led-core: Update fwnode with device_set_node
Update a newly created device's fwnode and of_node pointers using the
recently added device_set_node helper. This keeps some firmware node
specifics out of led-class and should help tracking future changes
regarding device firmware node updates.

Signed-off-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12 19:43:14 +01:00
Eddie James 419066324e leds: leds-core: Implement the retain-state-shutdown property
Read the retain-state-shutdown device tree property to set the
existing LED_RETAIN_AT_SHUTDOWN flag. Then check the flag when
unregistering, and if set, don't set the brightness to OFF. This
is useful for systems that want to keep the HW state of the LED
across reboots.

Signed-off-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-20 11:00:06 +02:00
Andy Shevchenko 0ac40af860 leds: class: The -ENOTSUPP should never be seen by user space
Drop the bogus error code and let of_led_get() to take care about absent
of_node.

Fixes: e389240ad9 ("leds: Add managed API to get a LED from a device driver")
Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-05-28 11:59:59 +02:00
Lee Jones 6a3a871b4b leds: led-class: Fix incorrectly documented param 'dev'
Fixes the following W=1 kernel build warning(s):

 drivers/leds/led-class.c:521: warning: Function parameter or member 'dev' not described in 'devm_led_classdev_unregister'
 drivers/leds/led-class.c:521: warning: Excess function parameter 'parent' description in 'devm_led_classdev_unregister'

Cc: Pavel Machek <pavel@ucw.cz>
Cc: John Lenz <lenz@cs.wisc.edu>
Cc: Richard Purdie <rpurdie@openedhand.com>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-05-28 11:38:54 +02:00
Abanoub Sameh af0bfab907 leds: led-core: Get rid of enum led_brightness
This gets rid of enum led_brightness in the main led files,
because it is deprecated, and an unsigned int can be used instead.

We can get rid of led_brightness completely and
patches can also be supplied for the other drivers' files.

Signed-off-by: Abanoub Sameh <abanoubsameh@protonmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-02-19 11:35:28 +01:00
Marek Behún c49d6cab0d leds: parse linux,default-trigger DT property in LED core
Do the parsing of `linux,default-trigger` DT property to LED core.
Currently it is done in many different drivers and the code is repeated.

This patch removes the parsing from 23 drivers:
  an30259a, aw2013, bcm6328, bcm6358, cr0014114, el15203000, gpio,
  is31fl32xx, lm3532, lm36274, lm3692x, lm3697, lp50xx, lp8860, lt3593,
  max77650, mt6323, ns2, pm8058, pwm, syscon, tlc591xx and turris-omnia.

There is one driver in drivers/input which parses this property on it's
own. I shall send a separate patch there after this is applied.

There are still 8 drivers that parse this property on their own because
they do not pass the led_init_data structure to the registering
function. I will try to refactor those in the future.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-09-26 21:56:43 +02:00
Kai-Heng Feng 302a085c20 leds: core: Flush scheduled work for system suspend
Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon
system suspend.

led_set_brightness_nopm() uses schedule_work() to set LED brightness.
However, there's no guarantee that the scheduled work gets executed
because no one flushes the work.

So flush the scheduled work to make sure LED gets turned off.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fixes: 81fe8e5b73 ("leds: core: Add led_set_brightness_nosleep{nopm} functions")
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-12 10:10:37 +02:00
Ricardo Ribalda Delgado 64ed6588c2 leds: core: Fix warning message when init_data
The warning message when a led is renamed due to name collition can fail
to show proper original name if init_data is used. Eg:

[    9.073996] leds-gpio a0040000.leds_0: Led (null) renamed to red_led_1 due to name collision

Fixes: bb4e9af034 ("leds: core: Add support for composing LED class device names")
Signed-off-by: Ricardo Ribalda Delgado <ribalda@kernel.org>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-04-06 23:12:08 +02:00
Jean-Jacques Hiblot 7a349e8c53 leds: populate the device's of_node
If initialization data is available and its fwnode is actually a
of_node, store this information in the led device's structure. This
will allow the device to use or provide OF-based API such (devm_xxx).

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-01-06 00:20:22 +01:00
Jean-Jacques Hiblot e389240ad9 leds: Add managed API to get a LED from a device driver
If the LED is acquired by a consumer device with devm_led_get(), it is
automatically released when the device is detached.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-01-06 00:20:18 +01:00
Tomi Valkeinen 699a8c7c4b leds: Add of_led_get() and led_put()
This patch adds basic support for a kernel driver to get a LED device.
This will be used by the led-backlight driver.

Only OF version is implemented for now, and the behavior is similar to
PWM's of_pwm_get() and pwm_put().

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-01-06 00:20:06 +01:00
Dan Murphy 4b83cf07d7 leds: core: Fix devm_classdev_match to reference correct structure
Fix the devm_classdev_match pointer initialization to the correct
structure type.

Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2019-11-03 17:38:51 +01:00
Akinobu Mita 11f7000221 leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/trigger
Reading /sys/class/leds/<led>/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/<led>/trigger to
binary attribute, which is not limited by length. This is _not_ good
design, do not copy it.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>A
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2019-11-03 17:38:14 +01:00
Andy Shevchenko 1dbb9fb408 leds: Allow to call led_classdev_unregister() unconditionally
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 <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-08-26 20:03:58 +02:00
Andy Shevchenko fd81d7e946 leds: Switch to use fwnode instead of be stuck with OF one
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 <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-08-23 23:39:37 +02:00
Jacek Anaszewski be7fc2cc86 Generic Device Lookup Helpers
Persistent tag for others to pull this branch from
 
 Based on patch series from Suzuki K Poulose <suzuki.poulose@arm.com>
 with Subject: [PATCH v3 0/7] drivers: Add generic device lookup helpers
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 
 iQJPBAABCAA5FiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl1AL7obHGdyZWdraEBs
 aW51eGZvdW5kYXRpb24ub3JnAAoJEDjbvchgkmk+X9cP/jXGxNeD4Hv2KfpQb32E
 Zl7bnblRwKaheD1s91WzfV8HFgLcylmu2chW/IGpgX7ujHRr5zIu/H8FApK+Z5F+
 8LiF8HnW2GICcSf95VMLNBXFY3wZq7NzOVnLIPvVcLJdOPPEjfYafQwSxB4WYxW5
 UK4JVsLg8SpAOdqA5bGhlOHWaTssLRsktA0VEh4w0uUOxPeel7gh16GRK8GLlKTq
 8lHiIKaN7PL9eDFTjh1wYP6FFgEAQhKexYVDtVj3fcEf8M0ArJTPIuPgaCKUqmD/
 J233RyFAuMtR8N1jY4ScPlnUyHJzNmM1wF77PRupwIAO0opRjTJ2BNI7GwC1hB2J
 xiPWtHrD21MBh2g44v+b/OwFNJ5AvuIlWEdEnrpNyj2KzrZP9H8G8Fy6CjFdVsEU
 HzccNdkfZ0Y2juJjE/HvpPe3t3NjncUgeuFALzgjYrmm/1KVGL16HH2YFvtGZI5P
 wrJVjyjdkRVU2u5I5+lIHRfULSmQIEPvp2BfkHnsmDmLNQbL8eTYCuowpSdbWWYB
 yFxoavHuga7uDW3MPMr6c62csaUXMyeb1y9gCKnUqhg9lxkbGujFsUBVviFKJTvH
 bWt79T2hqShe22JvwoIMSnH0DGpmFxFfdXk5/D7dGJJ5KUFoQ7bI0Q4wB9wW5+C4
 uNqNTLD+o6uyIXD3wwRy/kkN
 =XFYe
 -----END PGP SIGNATURE-----

Merge tag 'generic_lookup_helpers' into for-next

Generic Device Lookup Helpers

Persistent tag for others to pull this branch from

Based on patch series from Suzuki K Poulose <suzuki.poulose@arm.com>
with Subject: [PATCH v3 0/7] drivers: Add generic device lookup helpers

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

* 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
2019-07-30 22:36:31 +02:00
Suzuki K Poulose 6cda08a20d drivers: Introduce device lookup variants by name
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 <a.zummo@towertech.it>
Cc: Alexander Aring <alex.aring@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Harald Freudenberger <freude@linux.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Lee Jones <lee.jones@linaro.org>
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 <mcoquelin.stm32@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Stefan Schmidt <stefan@datenfreihafen.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20190723221838.12024-2-suzuki.poulose@arm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-30 13:07:41 +02:00
Jacek Anaszewski bb4e9af034 leds: core: Add support for composing LED class device names
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@gmail.com>
Cc: Baolin Wang <baolin.wang@linaro.org>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Daniel Mack <daniel@zonque.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Oleh Kravchenko <oleg@kaa.org.ua>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Simon Shields <simon@lineageos.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
2019-07-25 20:07:52 +02:00
Jacek Anaszewski b2b998c0f9 leds: class: Improve LED and LED flash class registration API
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 <jacek.anaszewski@gmail.com>
Cc: Baolin Wang <baolin.wang@linaro.org>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Daniel Mack <daniel@zonque.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Oleh Kravchenko <oleg@kaa.org.ua>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Simon Shields <simon@lineageos.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
2019-07-25 20:07:50 +02:00
Thomas Gleixner d2912cb15b treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
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 <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-19 17:09:55 +02:00
Pavel Machek 0db37915d9 leds: avoid races with workqueue
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: 1afcadfcd1 ("leds: core: Use set_brightness_work for the blocking op")
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-05-02 22:54:51 +02:00
Luis Henriques 6d71021ab3 leds: class: ensure workqueue is initialized before setting brightness
An application can try to set brightness before all the initialization is
done, in particular before the workqueue is initialized with the call to
led_init_core().  Here's a WARNING easy to trigger:

[   36.780813] WARNING: CPU: 3 PID: 1411 at ../kernel/workqueue.c:1444 __queue_work+0x37b/0x420
[   36.780815] Modules linked in: ...
[   36.780868] CPU: 3 PID: 1411 Comm: systemd-backlig Not tainted 4.16.9-1-default #1 openSUSE Tumbleweed (unreleased)
[   36.780868] Hardware name: Dell Inc. Precision 5510/0N8J4R, BIOS 1.6.1 12/11/2017
[   36.780870] RIP: 0010:__queue_work+0x37b/0x420
[   36.780871] RSP: 0018:ffffaced048b7d78 EFLAGS: 00010086
[   36.780873] RAX: 0000000000000000 RBX: ffffffffb3f01440 RCX: 0000000000000000
[   36.780873] RDX: ffffffffc05a90d8 RSI: 0000000000000000 RDI: ffff8eac7dce2700
[   36.780874] RBP: ffff8ea547c16400 R08: ffff8ea547800000 R09: ffff8eac7dc22700
[   36.780875] R10: 0000000000000000 R11: 0000000000000040 R12: 0000000000000003
[   36.780876] R13: 0000000000000200 R14: ffffffffc05a90d0 R15: ffff8eac7dce8600
[   36.780877] FS:  00007f871e61cf40(0000) GS:ffff8eac7dcc0000(0000) knlGS:0000000000000000
[   36.780878] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   36.780879] CR2: 000055c91115e308 CR3: 0000000883ee0005 CR4: 00000000003606e0
[   36.780880] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   36.780880] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   36.780881] Call Trace:
[   36.780886]  queue_work_on+0x81/0x90
[   36.780889]  brightness_store+0x5d/0x90
[   36.780892]  kernfs_fop_write+0x105/0x180
[   36.780894]  __vfs_write+0x26/0x150
[   36.780897]  ? common_file_perm+0x51/0x150
[   36.780900]  ? security_file_permission+0x3c/0xb0
[   36.780901]  vfs_write+0xad/0x1a0
[   36.780903]  SyS_write+0x42/0x90
[   36.780906]  do_syscall_64+0x76/0x140
[   36.780908]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
[   36.780910] RIP: 0033:0x7f871dd04c94
[   36.780910] RSP: 002b:00007ffeb3a57d38 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[   36.780912] RAX: ffffffffffffffda RBX: 000055c91115c810 RCX: 00007f871dd04c94
[   36.780912] RDX: 0000000000000001 RSI: 000055c91115c810 RDI: 0000000000000004
[   36.780913] RBP: 00007ffeb3a57e10 R08: 0000000000000003 R09: 0000000000000000
[   36.780914] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
[   36.780914] R13: 000055c911158f30 R14: 000055c90f3a9a4e R15: 0000000000000004
[   36.780917] Code: 74 18 e8 49 80 00 00 48 85 c0 74 0e 48 8b 40 20 48 3b 68 08
0f 84 c2 fc ff ff 0f 0b 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b e9
82 fd ff ff 83 cd 02 49 8d 57 60 e9 69 fd ff ff 80 3d
[   36.780942] ---[ end trace 1fce4edad54c4017 ]---

This patch initializes and acquires the led_access mutex early in the
of_led_classdev_register function, so that any application trying to write
to sysfs to set brightness will block until initialization ends.

Signed-off-by: Luis Henriques <lhenriques@suse.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-05-24 22:08:26 +02:00
Rafał Miłecki 442c609830 leds: core: add OF variants of LED registering functions
These new functions allow passing an additional device_node argument
that will be internally set for created LED device. Thanks to this LED
core code and triggers will be able to access DT node for reading extra
info.

The easiest solution for achieving this was reworking old functions to
more generic ones & adding simple defines for API compatibility.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-08 21:10:01 +01:00
Hans de Goede 0cb8eb30d4 leds: class: Add new optional brightness_hw_changed attribute
Some LEDs may have their brightness level changed autonomously
(outside of kernel control) by hardware / firmware. This commit
adds support for an optional brightness_hw_changed attribute to
signal such changes to userspace (if a driver can detect them):

What:		/sys/class/leds/<led>/brightness_hw_changed
Date:		January 2017
KernelVersion:	4.11
Description:
		Last hardware set brightness level for this LED. Some LEDs
		may be changed autonomously by hardware/firmware. Only LEDs
		where this happens and the driver can detect this, will
		have this file.

		This file supports poll() to detect when the hardware
		changes the brightness.

		Reading this file will return the last brightness level set
		by the hardware, this may be different from the current
		brightness.

Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to
their flags field and call led_classdev_notify_brightness_hw_changed()
with the hardware set brightness when they detect a hardware / firmware
triggered brightness change.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-01-29 19:59:42 +01:00
Hans de Goede a9c6ce57ec led: core: Use atomic bit-field for the blink-flags
All the LED_BLINK* flags are accessed read-modify-write from e.g.
led_set_brightness and led_blink_set_oneshot while both
set_brightness_work and the blink_timer may be running.

If these race then the modify step done by one of them may be lost,
switch the LED_BLINK* flags to a new atomic work_flags bit-field
to avoid this race.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22 12:07:05 +01:00
David Lechner eb1ce74699 leds: Use macro for max device node name size
Use a macro instead of hard-coding the max device node name size. The
uleds driver introduced a macro for this value, so using it.

Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22 12:07:02 +01:00
Heiner Kallweit d84d80f38f leds: core: avoid error message when a USB LED device is unplugged
When a USB LED device is unplugged the remove call chain calls
led_classdev_unregister which tries to switch the LED off.
As the device has been removed already this results in a ENODEV
error message in dmesg.
Avoid this error message by ignoring ENODEV in calls from
led_classdev_unregister if the LED device is flagged as pluggable.

Therefore a new flag LED_HW_PLUGGABLE was introduced which should be set by
all LED drivers handling pluggable LED devices (mainly USB LED devices).

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-03-14 09:22:20 +01:00
Milo Kim d1aa577f5e leds: turn off the LED and wait for completion on unregistering LED class device
Workqueue, 'set_brightness_work' is used for scheduling brightness control.
This workqueue is canceled when the LED class device is unregistered.
Currently, LED subsystem handles like below.

  cancel_work_sync(&led_cdev->set_brightness_work)
  led_set_brightness(led_cdev, LED_OFF)

However, this could be a problem.
Workqueue is going to be canceled but LED device needs to be off.
The worst case is null pointer access due to scheduling a workqueue.

LED module is loaded.
  LED driver private data is allocated by using devm_zalloc().

LED module is unloaded.
  led_classdev_unregister() is called.
    cancel_work_sync()
      led_set_brightness(led_cdev, LED_OFF)
        schedule_work() if LED driver uses brightness_set_blocking()
        In the meantime, driver private data will be freed.

        ..scheduling..

        brightness_set_blocking() callback is invoked.
          For the brightness control, LED driver tries to access private
          data but resource is removed!

To avoid this problem, LED subsystem should turn off the brightness first
and wait for completion.

  led_set_brightness(led_cdev, LED_OFF)
  flush_work(&led_cdev->set_brightness_work)

It guarantees that LED driver turns off the brightness prior to
resource management.

Cc: linux-leds@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-01-04 09:57:37 +01:00
Jacek Anaszewski 13ae79bbe4 leds: core: Drivers shouldn't enforce SYNC/ASYNC brightness setting
This patch removes SET_BRIGHTNESS_ASYNC and SET_BRIGHTNESS_SYNC flags.
led_set_brightness() now calls led_set_brightness_nosleep() instead of
choosing between sync and async op basing on the flags defined by the
driver.

From now on, if a user wants to make sure that brightness will be set
synchronously, they have to use led_set_brightness_sync() API. It is now
being made publicly available since it has become apparent that it is
a caller who should decide whether brightness is to be set in
a synchronous or an asynchronous way.

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2016-01-04 09:57:31 +01:00
Jacek Anaszewski 81fe8e5b73 leds: core: Add led_set_brightness_nosleep{nopm} functions
This patch adds led_set_brightness_nosleep() and led_set_brightness_nopm()
functions, that guarantee setting LED brightness in a non-blocking way.
The latter is used from pm_ops context and doesn't modify the brightness
cached in the struct led_classdev. Its execution always ends up with
a call to brightness setting op - either directly or through
a set_brightness_work, regardless of LED_SUSPENDED flag state.

The patch also replaces led_set_brightness_async() with
led_set_brightness_nosleep() in all places where the most vital was setting
brightness in a non sleeping way but not necessarily asynchronously, which
is not needed for non-blocking drivers.

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2016-01-04 09:57:30 +01:00
Jacek Anaszewski 757b06ae04 leds: core: Move LED core callbacks out of led-class.c
Since the API for controlling LED brightness and blinking is defined in
the LED core, move the related timer and work callbacks to the led-core.c,
and initialize them through a new led_core_init API.

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Pavel Machek <pavel@ucw.cz>
2015-11-03 08:59:22 +01:00
Ricardo Ribalda Delgado e5b5a61fcb leds/led-class: Add missing put_device()
Devices found by class_find_device must be freed with put_device().
Otherwise the reference count will not work properly.

Fixes: a96aa64cb5 ("leds/led-class: Handle LEDs with the same name")
Reported-by: Alan Tull <delicious.quinoa@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2015-08-28 14:06:19 +02:00
Linus Torvalds 13d45f79a2 Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
Pull LED subsystem updates from Bryan Wu:
 "In this cycle, we finished to merge patches for LED Flash class
  driver.

  Other than that we have some bug fixes and new drivers for LED
  controllers"

* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (33 commits)
  leds:lp55xx: fix firmware loading error
  leds: fix max77693-led build errors
  leds: fix aat1290 build errors
  leds: aat1290: pass flags parameter to devm_gpiod_get
  leds: ktd2692: pass flags parameter to devm_gpiod_get
  drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c
  leds: aat1290: add support for V4L2 Flash sub-device
  DT: aat1290: Document handling external strobe sources
  leds: max77693: add support for V4L2 Flash sub-device
  media: Add registration helpers for V4L2 flash sub-devices
  v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it
  Documentation: leds: Add description of v4l2-flash sub-device
  leds: add BCM6358 LED driver
  leds: add DT binding for BCM6358 LED controller
  leds: fix brightness changing when software blinking is active
  Documentation: leds-lp5523: describe master fader attributes
  leds: lp5523: add master_fader support
  leds: leds-gpio: Allow compile test if !GPIOLIB
  leds: leds-gpio: Add missing #include <linux/of.h>
  gpiolib: Add missing dummies for the unified device properties interface
  ...
2015-07-01 19:09:11 -07:00
Stas Sergeev 76931edd54 leds: fix brightness changing when software blinking is active
The following sequence:
echo timer >/sys/class/leds/<name>/trigger
echo 1 >/sys/class/leds/<name>/brightness
should change the ON brightness for blinking.
The function led_set_brightness() was mistakenly initiating the
delayed blink stop procedure, which resulted in no blinking with
the timer trigger still active.

This patch fixes the problem by changing led_set_brightness()
to not initiate the delayed blink stop when brightness is not 0.

CC: Richard Purdie <rpurdie@rpsys.net>
CC: Kyungmin Park <kyungmin.park@samsung.com>
CC: linux-leds@vger.kernel.org
CC: linux-kernel@vger.kernel.org

Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Stas Sergeev <stsp@users.sourceforge.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-05-25 13:26:47 -07:00
Grygorii Strashko 084609bf72 leds / PM: fix hibernation on arm when gpio-led used with CPU led trigger
Setting a dev_pm_ops suspend/resume pair of callbacks but not a set of
hibernation callbacks means those pm functions will not be
called upon hibernation - that leads to system crash on ARM during
freezing if gpio-led is used in combination with CPU led trigger.
It may happen after freeze_noirq stage (GPIO is suspended)
and before syscore_suspend stage (CPU led trigger is suspended)
- usually when disable_nonboot_cpus() is called.

Log:
  PM: noirq freeze of devices complete after 1.425 msecs
  Disabling non-boot CPUs ...
    ^ system may crash or stuck here with message (TI AM572x)

  WARNING: CPU: 0 PID: 3100 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x22c/0x370()
  44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access

  CPU1: shutdown
    ^ or here

Fix this by using SIMPLE_DEV_PM_OPS, which appropriately
assigns the suspend and hibernation callbacks and move
led_suspend/led_resume under CONFIG_PM_SLEEP to avoid
build warnings.

Fixes: 73e1ab41a8 (leds: Convert led class driver from legacy pm ops to dev_pm_ops)
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-05-12 23:58:24 +02:00
Sakari Ailus ccdc45075a leds: Don't treat the LED name as a format string
The LED name was wrongly interpreted as format string. Stop doing that.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
2015-03-30 14:26:32 -07:00
Sakari Ailus 6f06c7f87c leds: Use log level warn instead of info when telling about a name clash
The LED names are expected to be unique in the system. Use KERN_WARNING log
level to notify the user about the matter.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
2015-03-30 14:26:25 -07:00