leds: trigger: Add new LED Input events trigger

Add a new trigger which turns LEDs on when there is input
(/dev/input/event*) activity and turns them back off again after there has
been no activity

leds: trigger: Add new LED Input events trigger

Add a new trigger which turns LEDs on when there is input
(/dev/input/event*) activity and turns them back off again after there has
been no activity for 5 seconds.

This is primarily intended to control LED devices which are a backlight for
capacitive touch-buttons, such as e.g. the menu / home / back buttons found
on the bottom bezel of many somewhat older smartphones and tablets.

This can also be used to turn on the keyboard backlight LED on input
events and turn the keyboard backlight off again when idle.

Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

ALSA: control-led: Integrate mute led trigger

This driver is the only one calling ledtrig_audio_set(), therefore
the LED audio trigger isn't usable standalone. So it makes sense
to fully integrate L

ALSA: control-led: Integrate mute led trigger

This driver is the only one calling ledtrig_audio_set(), therefore
the LED audio trigger isn't usable standalone. So it makes sense
to fully integrate LED audio triger handling here.

The module aliases ensure that the driver is auto-loaded (if built
as module) if a LED device has one of the two audio triggers as
default trigger.

In addition disable building the old audio mute LED trigger.

Signed-off-by: Heiner Kallweit <[email protected]>
Reviewed-by: Takashi Iwai <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: triggers: gpio: Rewrite to use trigger-sources

By providing a GPIO line as "trigger-sources" in the FWNODE
(such as from the device tree) and combining with the
GPIO trigger, we can support a

leds: triggers: gpio: Rewrite to use trigger-sources

By providing a GPIO line as "trigger-sources" in the FWNODE
(such as from the device tree) and combining with the
GPIO trigger, we can support a GPIO LED trigger in a natural
way from the hardware description instead of using the
custom sysfs and deprecated global GPIO numberspace.

Example:

gpio: gpio@0 {
compatible "my-gpio";
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
#trigger-source-cells = <2>;
};

leds {
compatible = "gpio-leds";
led-my-gpio {
label = "device:blue:myled";
gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
linux,default-trigger = "gpio";
trigger-sources = <&gpio 1 GPIO_ACTIVE_HIGH>;
};
};

Make this the norm, unmark the driver as broken.

Delete the sysfs handling of GPIOs.

Since GPIO descriptors inherently can describe inversion,
the inversion handling can just be deleted.

Signed-off-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: Mark GPIO LED trigger broken

The GPIO LED trigger exposes a userspace ABI where a user
can echo a GPIO number from the global GPIO numberspace into
a file that will trigger a certain LED when

leds: Mark GPIO LED trigger broken

The GPIO LED trigger exposes a userspace ABI where a user
can echo a GPIO number from the global GPIO numberspace into
a file that will trigger a certain LED when active.

This is problematic because the global GPIO numberspace is
inherently instable. The trigger came about at a time when
systems had one GPIO controller that defined hard-wired
GPIOs numbered 0..N and this number space was stable.

We have since moved to dynamic allocation of GPIO numbers
and there is no real guarantee that a GPIO number will stay
consistent even across a reboot: consider a USB attached
GPIO controller for example. Or two. Or the effect of
probe order after adding -EPROBE_DEFER to the kernel.

The trigger was added to support keypad LEDs on the Nokia
n810 from the GPIO event when a user slides up/down the
keypad. This is arch/arm/boot/dts/omap2420-n810.dts.
A userspace script is needed to activate the trigger.
This will be broken unless the script was updated recently
since the OMAP GPIO controller now uses dynamic GPIO
number allocations.

I want to know that this trigger has active users that
cannot live without it if we are to continue to support it.

Option if this is really needed: I can develop a new trigger
that can associate GPIOs with LEDs as triggers using device
tree, which should also remove the use of userspace custom
scripts to achieve this and be much more trustworthy, if
someone with the Nokia n810 or a device with a similar need
is willing to test it.

Suggested-by Pavel Machek <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

leds: trigger: Disable CPU trigger on PREEMPT_RT

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.
T

leds: trigger: Disable CPU trigger on PREEMPT_RT

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 <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Pavel Machek <[email protected]>

show more ...

leds: trigger: remove reference to obsolete CONFIG_IDE_GD_ATA

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

So, remove the obsolete refe

leds: trigger: remove reference to obsolete CONFIG_IDE_GD_ATA

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 <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>

show more ...

leds: trigger: implement a tty trigger

Usage is as follows:

myled=ledname
tty=ttyS0

echo tty > /sys/class/leds/$myled/trigger
echo $tty > /sys/class/leds/$myled/ttyname

. When this new trigge

leds: trigger: implement a tty trigger

Usage is as follows:

myled=ledname
tty=ttyS0

echo tty > /sys/class/leds/$myled/trigger
echo $tty > /sys/class/leds/$myled/ttyname

. When this new trigger is active it periodically checks the tty's
statistics and when it changed since the last check the led is flashed
once.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

docs: leds: convert to ReST

Rename the leds documentation files to ReST, add an
index for them and adjust in order to produce a nice html
output via the Sphinx build system.

At its new index.rst, l

docs: leds: convert to ReST

Rename the leds documentation files to ReST, add an
index for them and adjust in order to produce a nice html
output via the Sphinx build system.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project

treewide: Add SPDX license identifier - Makefile/Kconfig

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0-only

Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

leds: trigger: Introduce audio mute LED trigger

This patch adds a new LED trigger for coupling the audio mixer change
with the LED on laptops or other devices. Currently there are two
trigger types

leds: trigger: Introduce audio mute LED trigger

This patch adds a new LED trigger for coupling the audio mixer change
with the LED on laptops or other devices. Currently there are two
trigger types, "audio-mute" and "audio-micmute".

The audio driver triggers the LED brightness change via
ledtrig_audio_set() call with the proper type (either mute or
mic-mute). OTOH, the consumers may call ledtrig_audio_get() for the
initial brightness value that may have been set by the audio driver
beforehand.

This new stuff will be used by HD-audio codec driver and some platform
drivers (thinkpad_acpi and dell-laptop, also upcoming huawei-wmi).

Acked-by: Jacek Anaszewski <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Acked-by: Pali Rohár <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>

show more ...

leds: core: Introduce LED pattern trigger

This patch adds a new LED trigger that LED device can configure
to employ software or hardware pattern engine.

Consumers can write 'pattern' file to enable

leds: core: Introduce LED pattern trigger

This patch adds a new LED trigger that LED device can configure
to employ software or hardware pattern engine.

Consumers can write 'pattern' file to enable the software pattern
which alters the brightness for the specified duration with one
software timer.

Moreover consumers can write 'hw_pattern' file to enable the hardware
pattern for some LED controllers which can autonomously control
brightness over time, according to some preprogrammed hardware
patterns.

Signed-off-by: Raphael Teysseyre <[email protected]>
Signed-off-by: Baolin Wang <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

leds: triggers: don't depend on LEDS_TRIGGERS twice

All the triggers are defined in a big if LEDS_TRIGGERS...endif block.
So there is no need to let each driver depend on LEDS_TRIGGERS explicitly
on

leds: triggers: don't depend on LEDS_TRIGGERS twice

All the triggers are defined in a big if LEDS_TRIGGERS...endif block.
So there is no need to let each driver depend on LEDS_TRIGGERS explicitly
once more.

Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

leds: trigger: Introduce a NETDEV trigger

This commit introduces a NETDEV trigger for named device
activity. Available triggers are link, rx, and tx.

Signed-off-by: Ben Whitten <[email protected]

leds: trigger: Introduce a NETDEV trigger

This commit introduces a NETDEV trigger for named device
activity. Available triggers are link, rx, and tx.

Signed-off-by: Ben Whitten <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

ledtrig-activity: Grammar s/a immediate/an immediate/

Fixes: 7df4f9a9f0667ee6 ("leds: ledtrig-activity: Add a system activity LED trigger")
Signed-off-by: Geert Uytterhoeven <[email protected]

ledtrig-activity: Grammar s/a immediate/an immediate/

Fixes: 7df4f9a9f0667ee6 ("leds: ledtrig-activity: Add a system activity LED trigger")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

leds: ledtrig-activity: Add a system activity LED trigger

The "activity" trigger was inspired by the heartbeat one, but aims at
providing instant indication of the immediate CPU usage. Under idle
co

leds: ledtrig-activity: Add a system activity LED trigger

The "activity" trigger was inspired by the heartbeat one, but aims at
providing instant indication of the immediate CPU usage. Under idle
condition, it flashes 10ms every second. At 100% usage, it flashes
90ms every 100ms. The blinking frequency increases from 1 to 10 Hz
until either the load is high enough to saturate one CPU core or 50%
load is reached on a single-core system. Then past this point only the
duty cycle increases from 10 to 90%.

This results in a very visible activity reporting allowing one to
immediately tell whether a machine is under load or not, making it
quite suitable to be used in clusters.

Signed-off-by: Willy Tarreau <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

leds: convert IDE trigger to common disk trigger

This patch converts the IDE specific LED trigger to a generic disk
activity LED trigger. The libata core is now a trigger source just
like before the

leds: convert IDE trigger to common disk trigger

This patch converts the IDE specific LED trigger to a generic disk
activity LED trigger. The libata core is now a trigger source just
like before the IDE disk driver. It's merely a replacement of the
string ide by disk.

The patch is taken from http://dev.gentoo.org/~josejx/ata.patch and is
widely used by any ibook/powerbook owners with great satisfaction.
Likewise, it is very often used successfully on different ARM platforms.

Unlike the original patch, the existing 'ide-disk' trigger is still
available for backward compatibility. That reduce the amount of patches
in affected device trees out of the mainline kernel. For further
development, the new name 'disk-activity' should be used.

Cc: Joseph Jezak <[email protected]>
Cc: Jörg Sommer <[email protected]>
Cc: Richard Purdie <[email protected]>
Signed-off-by: Stephan Linz <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which
allows to mark a specific LED to be switched to the "panic"
t

leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which
allows to mark a specific LED to be switched to the "panic"
trigger, on a kernel panic.

This is useful to allow the user to assign a regular trigger
to a given LED, and still blink that LED on a kernel panic.

Signed-off-by: Ezequiel Garcia <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

leds: trigger: Introduce a MTD (NAND/NOR) trigger

This commit introduces a MTD trigger for flash (NAND/NOR) device
activity. The implementation is copied from IDE disk.

This trigger deprecates the

leds: trigger: Introduce a MTD (NAND/NOR) trigger

This commit introduces a MTD trigger for flash (NAND/NOR) device
activity. The implementation is copied from IDE disk.

This trigger deprecates the "nand-disk" LED trigger, but for backwards
compatibility, we still keep the "nand-disk" trigger around.

The motivation for deprecating the "nand-disk" LED trigger is that
it only works for NAND drivers, whereas the "mtd" LED trigger
is more generic (in fact, "nand-disk" currently only works for
certain NAND drivers).

Signed-off-by: Ezequiel Garcia <[email protected]>
Acked-by: Boris Brezillon <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

leds: trigger: Introduce a kernel panic LED trigger

This commit introduces a new LED trigger which allows to configure
a LED to blink on a kernel panic (through panic_blink).

Notice that currently

leds: trigger: Introduce a kernel panic LED trigger

This commit introduces a new LED trigger which allows to configure
a LED to blink on a kernel panic (through panic_blink).

Notice that currently the Openmoko FreeRunner (GTA02) mach code
sets panic_blink to blink a hard-coded LED. The new trigger is
meant to introduce a generic mechanism to achieve this.

Signed-off-by: Ezequiel Garcia <[email protected]>
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

leds: Allow compile test of GPIO consumers if !GPIOLIB

The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consume

leds: Allow compile test of GPIO consumers if !GPIOLIB

The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
functionality only, can still be compiled if GPIOLIB is not enabled.

Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where
appropriate.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Cc: Richard Purdie <[email protected]>
Cc: [email protected]
Signed-off-by: Jacek Anaszewski <[email protected]>

show more ...

leds: add camera LED triggers

Some LED devices support flash/torch functionality through the LED subsystem.
This patch enables direct LED trigger controls by the driver.
Flash on/off and torch on/of

leds: add camera LED triggers

Some LED devices support flash/torch functionality through the LED subsystem.
This patch enables direct LED trigger controls by the driver.
Flash on/off and torch on/off can be done simply by other driver space.
Two trigger APIs are added, ledtrig_flash_ctrl() and ledtrig_torch_ctrl().

Signed-off-by: Milo(Woogyom) Kim <[email protected]>
Signed-off-by: Bryan Wu <[email protected]>

show more ...

leds: move LED trigger drivers into new subdirectory

For better driver management, new subdirectory, 'trigger' is created.
All LED trigger drivers are moved into this directory.

Internal header, 'l

leds: move LED trigger drivers into new subdirectory

For better driver management, new subdirectory, 'trigger' is created.
All LED trigger drivers are moved into this directory.

Internal header, 'leds.h' is included in each LED trigger drivers.
Fix the location of header file, "leds.h" -> "../leds.h" in driver files.
One exception is here, 'ledtrig-timer.c'.
There is no need to include 'leds.h'. so '#include "leds.h"' line was removed.

Signed-off-by: Milo(Woogyom) Kim <[email protected]>
Signed-off-by: Bryan Wu <[email protected]>

show more ...