linux-toradex.git/drivers/leds/trigger, branch v5.17-rc4

leds: trigger: Disable CPU trigger on PREEMPT_RT

2021-10-13T18:07:57+00:00

The CPU trigger is invoked on ARM from CPU-idle. That trigger later
invokes led_trigger_event() which may invoke the callback of the actual driver.
That driver can acquire a spinlock_t which is okay on kernel without
PREEMPT_RT. On a PREEMPT_RT enabled kernel this lock is turned into a
sleeping lock and must not be acquired with disabled interrupts.

Disable the CPU trigger on PREEMPT_RT.

Signed-off-by: Sebastian Andrzej Siewior 
Link: https://lkml.kernel.org/r/20210924111501.m57cwwn7ahiyxxdd@linutronix.de
Signed-off-by: Pavel Machek

leds: trigger: remove reference to obsolete CONFIG_IDE_GD_ATA

2021-08-18T06:59:47+00:00

Commit b7fb14d3ac63 ("ide: remove the legacy ide driver") removes the
definition of the config IDE_GD_ATA.

So, remove the obsolete reference in ./drivers/leds/trigger/Kconfig.

Signed-off-by: Lukas Bulwahn 
Signed-off-by: Pavel Machek

leds: trigger: audio: Add an activate callback to ensure the initial brightness is set

2021-08-03T21:57:17+00:00

Some 2-in-1s with a detachable (USB) keyboard(dock) have mute-LEDs in
the speaker- and/or mic-mute keys on the keyboard.

Examples of this are the Lenovo Thinkpad10 tablet (with its USB kbd-dock)
and the HP x2 10 series.

The detachable nature of these keyboards means that the keyboard and
thus the mute LEDs may show up after the user (or userspace restoring
old mixer settings) has muted the speaker and/or mic.

Current LED-class devices with a default_trigger of "audio-mute" or
"audio-micmute" initialize the brightness member of led_classdev with
ledtrig_audio_get() before registering the LED.

This makes the software state after attaching the keyboard match the
actual audio mute state, e.g. cat /sys/class/leds/foo/brightness will
show the right value.

But before this commit nothing was actually calling the led_classdev's
brightness_set[_blocking] callback so the value returned by
ledtrig_audio_get() was never actually being sent to the hw, leading
to the mute LEDs staying in their default power-on state, after
attaching the keyboard, even if ledtrig_audio_get() returned a different
state.

This could be fixed by having the individual LED drivers call
brightness_set[_blocking] themselves after registering the LED,
but this really is something which should be done by a led-trigger
activate callback.

Add an activate callback for this, fixing the issue of the
mute LEDs being out of sync after (re)attaching the keyboard.

Cc: Takashi Iwai 
Fixes: faa2541f5b1a ("leds: trigger: Introduce audio mute LED trigger")
Reviewed-by: Marek Behún 
Signed-off-by: Hans de Goede 
Signed-off-by: Pavel Machek

Merge tag 'leds-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds

2021-07-03T18:57:42+00:00

Pull LED updates from Pavel Machek:
 "This contains quite a lot of fixes, with more fixes in my inbox that
  did not make it (sorry)"

* tag 'leds-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: (36 commits)
  leds: lgm: Fix up includes
  leds: ktd2692: Fix an error handling path
  leds: as3645a: Fix error return code in as3645a_parse_node()
  leds: turris-omnia: add missing MODULE_DEVICE_TABLE
  leds: lp55xx: Initialize enable GPIO direction to output
  leds: lm36274: Add missed property.h
  leds: el15203000: Make error handling more robust
  leds: pwm: Make error handling more robust
  leds: lt3593: Make use of device properties
  leds: lp50xx: Put fwnode in error case during ->probe()
  leds: lm3697: Don't spam logs when probe is deferred
  leds: lm3692x: Put fwnode in any case during ->probe()
  leds: lm36274: Correct headers (of*.h -> mod_devicetable.h)
  leds: lm36274: Put fwnode in error case during ->probe()
  leds: lm3532: Make error handling more robust
  leds: lm3532: select regmap I2C API
  leds: lgm-sso: Drop duplicate NULL check for GPIO operations
  leds: lgm-sso: Remove unneeded of_match_ptr()
  leds: lgm-sso: Fix clock handling
  leds: el15203000: Introduce to_el15203000_led() helper
  ...

kernel.h: split out panic and oops helpers

2021-07-01T18:06:04+00:00

kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.

There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by moving out panic_notifier.h
- unload kernel.h from something which has its own domain

At the same time convert users tree-wide to use new headers, although for
the time being include new header back to kernel.h to avoid twisted
indirected includes for existing users.

[akpm@linux-foundation.org: thread_info.h needs limits.h]
[andriy.shevchenko@linux.intel.com: ia64 fix]
  Link: https://lkml.kernel.org/r/20210520130557.55277-1-andriy.shevchenko@linux.intel.com

Link: https://lkml.kernel.org/r/20210511074137.33666-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Andy Shevchenko 
Reviewed-by: Bjorn Andersson 
Co-developed-by: Andrew Morton 
Acked-by: Mike Rapoport 
Acked-by: Corey Minyard 
Acked-by: Christian Brauner 
Acked-by: Arnd Bergmann 
Acked-by: Kees Cook 
Acked-by: Wei Liu 
Acked-by: Rasmus Villemoes 
Signed-off-by: Andrew Morton 
Acked-by: Sebastian Reichel 
Acked-by: Luis Chamberlain 
Acked-by: Stephen Boyd 
Acked-by: Thomas Bogendoerfer 
Acked-by: Helge Deller  # parisc
Signed-off-by: Linus Torvalds

leds: trigger: ledtrig-cpu: Fix incorrectly documented param 'ledevt'

2021-05-28T09:38:53+00:00

Fixes the following W=1 kernel build warning(s):

 drivers/leds/trigger/ledtrig-cpu.c:52: warning: Function parameter or member 'ledevt' not described in 'ledtrig_cpu'
 drivers/leds/trigger/ledtrig-cpu.c:52: warning: Excess function parameter 'evt' description in 'ledtrig_cpu'

Cc: Pavel Machek 
Cc: Linus Walleij 
Cc: Bryan Wu 
Cc: linux-leds@vger.kernel.org
Signed-off-by: Lee Jones 
Signed-off-by: Pavel Machek

Merge tag 'leds-5.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds

2021-05-03T19:23:03+00:00

Pull LED updates from Pavel Machek:
 "Nothing too exciting here, just some fixes"

* tag 'leds-5.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds:
  leds: pca9532: Assign gpio base dynamically
  leds: trigger: pattern: Switch to using the new API kobj_to_dev()
  leds: LEDS_BLINK_LGM should depend on X86
  leds: lgm: Fix spelling mistake "prepate" -> "prepare"
  MAINTAINERS: Remove Dan Murphy's bouncing email
  leds-lm3642: convert comma to semicolon
  leds: rt4505: Add support for Richtek RT4505 flash LED controller
  leds: rt4505: Add DT binding document for Richtek RT4505
  leds: Kconfig: LEDS_CLASS is usually selected.
  leds: lgm: Improve Kconfig help
  leds: lgm: fix gpiolib dependency

leds: trigger: pattern: Switch to using the new API kobj_to_dev()

2021-04-25T21:38:10+00:00

Switch to using the new API kobj_to_dev() to fix the below warnning:
./drivers/leds/trigger/ledtrig-pattern.c:336:60-61: WARNING opportunity
for kobj_to_dev()

Signed-off-by: Tian Tao 
Signed-off-by: Pavel Machek

leds: trigger/tty: Use led_set_brightness_sync() from workqueue

2021-03-10T08:27:56+00:00

led_set_brightness() involves scheduling a workqueue. As here the led's
brightness setting is done in context of the trigger's workqueue this is
unjustified overhead and it's more sensible to use
led_set_brightness_sync().

Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger")
Reported-by: Pavel Machek 
Acked-by: Pavel Machek 
Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20210219133307.4840-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman

leds: trigger: Fix error path to not unlock the unlocked mutex

2021-03-10T08:27:55+00:00

ttyname is allocated before the mutex is taken, so it must not be
unlocked in the error path.

Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger")
Reported-by: Pavel Machek 
Acked-by: Pavel Machek 
Signed-off-by: Uwe Kleine-König 
Link: https://lore.kernel.org/r/20210219133307.4840-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman