linux-toradex.git/include/linux/leds.h, branch v5.1-rc3

leds: Add helper for getting default pattern from Device Tree

2019-01-16T21:08:07+00:00

Multiple LED triggers might need to access default pattern so add a
helper for that.

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Pavel Machek 
Signed-off-by: Jacek Anaszewski

Merge tag 'leds-for-4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds

2018-12-25T22:52:50+00:00

Pull LED updates from Jacek Anaszewski:
 "There are several few-liners, where most of them are fixes and
  improvments. One thing standing out is ground preparation for
  inititializing trigger parameters via Device Tree.

  We introduce LED_INIT_DEFAULT_TRIGGER flag for that purpose and set it
  when default trigger is matched. It indicates that trigger should
  parse DT properties to retrieve the initialization data when set as
  default one"

* tag 'leds-for-4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds:
  led: triggers: Initialize LED_INIT_DEFAULT_TRIGGER if trigger is brought after class
  led: triggers: Add LED_INIT_DEFAULT_TRIGGER flag
  led: triggers: Break the for loop after default trigger is found
  leds: pwm: Use OF variant of LED registering function
  leds: pwm: Simplify with resource-managed devm_led_classdev_register()
  leds: gpio: Drop unneeded manual of_node assignment
  leds: 88pm860x: Use of_node_name_eq for node name comparisons
  leds: powernv: add of_node_put()

led: triggers: Add LED_INIT_DEFAULT_TRIGGER flag

2018-12-10T20:31:55+00:00

Add the flag LED_INIT_DEFAULT_TRIGGER for indicating that trigger
being set is a default trigger for the LED class device, and
thus it should be initialized with settings provided in the fwnode.

Set the flag in the led_trigger_set_default(). It is expected to be
cleared in the activate() op of a trigger after trigger fwnode
initialization data is parsed and applied. This should happen only
once after LED class device registration, to allow leaving triggers
in the idle state on re-apply and let the users apply their own
settings without interference from the default ones.

Signed-off-by: Jacek Anaszewski 
Acked-by: Pavel Machek 
Signed-off-by: Krzysztof Kozlowski

leds: trigger: Introduce audio mute LED trigger

2018-11-28T11:28:30+00:00

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 
Acked-by: Pavel Machek 
Acked-by: Pali Rohár 
Signed-off-by: Takashi Iwai

leds: core: Introduce LED pattern trigger

2018-10-11T19:55:58+00:00

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 
Signed-off-by: Baolin Wang 
Signed-off-by: Jacek Anaszewski

leds: triggers: new function led_set_trigger_data()

2018-07-05T21:21:11+00:00

This is the natural counter part to the already existing
led_get_trigger_data().

Signed-off-by: Uwe Kleine-König 
Acked-by: Pavel Machek 
Signed-off-by: Jacek Anaszewski

leds: triggers: define module_led_trigger helper

2018-07-05T21:21:11+00:00

This helps to simplify modules that provide a simple led_trigger. It's
inspired by module_platform_driver, module_i2c_driver et al.

Signed-off-by: Uwe Kleine-König 
Acked-by: Pavel Machek 
Signed-off-by: Jacek Anaszewski

leds: triggers: add device attribute support

2018-07-05T21:21:10+00:00

As many triggers use device attributes, add support for these in
led_trigger_set which allows simplifying the drivers accordingly.

Signed-off-by: Uwe Kleine-König 
Acked-by: Pavel Machek 
Signed-off-by: Jacek Anaszewski

leds: triggers: let struct led_trigger::activate() return an error code

2018-07-05T21:21:10+00:00

Given that activating a trigger can fail, let the callback return an
indication. This prevents to have a trigger active according to the
"trigger" sysfs attribute but not functional.

All users are changed accordingly to return 0 for now. There is no intended
change in behaviour.

Signed-off-by: Uwe Kleine-König 
Acked-by: Pavel Machek 
Signed-off-by: Jacek Anaszewski

leds: Extends disk trigger for reads and writes

2018-03-11T19:01:55+00:00

This adds two new disk triggers for triggering on reads
and writes respectively, named "disk-read" and "disk-write".

The use case comes from working on the D-Link DNS-313 NAS
box. This features an RGB LED for disk activity. with
these two triggers I can couple the green LED to read
activity and the red LED to write activity, which gives
the appropriate user feedback about what is happening
on the disk. When tested it gave exactly the feedback
desired.

The in-kernel interface is simply changed to pass a bool
indicating if the activity is write activity and update
each trigger (and the composite "disk-activity" trigger)
depending on what is passed in.

Signed-off-by: Linus Walleij 
Reviewed-by: Bartlomiej Zolnierkiewicz 
Acked-by: Pavel Machek 
Acked-by: Tejun Heo 
Acked-by: David S. Miller 
Signed-off-by: Jacek Anaszewski