linux/drivers/leds, branch v4.7

leds: handle suspend/resume in heartbeat trigger

2016-06-08T09:47:06Z

The following phenomena was observed: when suspending the system, sometimes the heartbeat LED was left on, glowing and wasting power while the rest of the system is asleep, also disturbing power dissapation measures on the odd suspend cycle when it's left on. Clearly this is not how we want the heartbeat trigger to work: it should turn off and leave the LED off during system suspend. This removes the heartbeat trigger when preparing suspend and restores it during resume. The trigger code will make sure all LEDs are left in OFF state after removing the trigger, and will re-enable the trigger on all LEDs after resuming. Cc: linux-pm@vger.kernel.org Signed-off-by: Linus Walleij Reviewed-by: Ulf Hansson Signed-off-by: Jacek Anaszewski

leds: core: Fix brightness setting upon hardware blinking enabled

2016-06-08T09:47:06Z

Commit 76931edd54f8 ("leds: fix brightness changing when software blinking is active") changed the semantics of led_set_brightness() which according to the documentation should disable blinking upon any brightness setting. Moreover it made it different for soft blink case, where it was possible to change blink brightness, and for hardware blink case, where setting any brightness greater than 0 was ignored. While the change itself is against the documentation claims, it was driven also by the fact that timer trigger remained active after turning blinking off. Fixing that would have required major refactoring in the led-core, led-class, and led-triggers because of cyclic dependencies. Finally, it has been decided that allowing for brightness change during blinking is beneficial as it can be accomplished without disturbing blink rhythm. The change in brightness setting semantics will not affect existing LED class drivers that implement blink_set op thanks to the LED_BLINK_SW flag introduced by this patch. The flag state will be from now on checked in led_set_brightness() which will allow to distinguish between software and hardware blink mode. In the latter case the control will be passed directly to the drivers which apply their semantics on brightness set, which is disable the blinking in case of most such drivers. New drivers will apply new semantics and just change the brightness while hardware blinking is on, if possible. The issue was smuggled by subsequent LED core improvements, which modified the code that originally introduced the problem. Fixes: f1e80c07416a ("leds: core: Add two new LED_BLINK_ flags") Signed-off-by: Tony Makkiel Signed-off-by: Jacek Anaszewski

Merge tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm

2016-05-25T17:40:15Z

Pull pwm updates from Thierry Reding: "This set of changes introduces an atomic API to the PWM subsystem. This is influenced by the DRM atomic API that was introduced a while back, though it is obviously a lot simpler. The fundamental idea remains the same, though: drivers provide a single callback to implement the atomic configuration of a PWM channel. As a side-effect the PWM subsystem gains the ability for initial state retrieval, so that the logical state mirrors that of the hardware. Many use-cases don't care about this, but for others it is essential. These new features require changes in all users, which these patches take care of. The core is transitioned to use the atomic callback if available and provides a fallback mechanism for other drivers. Changes to transition users and drivers to the atomic API are postponed to v4.8" * tag 'pwm/for-4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: (30 commits) pwm: Add information about polarity, duty cycle and period to debugfs pwm: Switch to the atomic API pwm: Update documentation pwm: Add core infrastructure to allow atomic updates pwm: Add hardware readout infrastructure pwm: Move the enabled/disabled info into pwm_state pwm: Introduce the pwm_state concept pwm: Keep PWM state in sync with hardware state ARM: Explicitly apply PWM config extracted from pwm_args drm: i915: Explicitly apply PWM config extracted from pwm_args input: misc: pwm-beeper: Explicitly apply PWM config extracted from pwm_args input: misc: max8997: Explicitly apply PWM config extracted from pwm_args backlight: lm3630a: explicitly apply PWM config extracted from pwm_args backlight: lp855x: Explicitly apply PWM config extracted from pwm_args backlight: lp8788: Explicitly apply PWM config extracted from pwm_args backlight: pwm_bl: Use pwm_get_args() where appropriate fbdev: ssd1307fb: Use pwm_get_args() where appropriate regulator: pwm: Use pwm_get_args() where appropriate leds: pwm: Use pwm_get_args() where appropriate input: misc: max77693: Use pwm_get_args() where appropriate ...

leds: pwm: Use pwm_get_args() where appropriate

2016-05-17T12:45:02Z

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework allowing the PWM framework to support hardware readout and expose real PWM state even when the PWM has just been requested (before the user calls pwm_config/enable/disable()). Signed-off-by: Boris Brezillon Acked-by: Jacek Anaszewski Signed-off-by: Thierry Reding

leds: gpio: Support the "panic-indicator" firmware property

2016-05-06T08:26:07Z

Calling a GPIO LEDs is quite likely to work even if the kernel has paniced, so they are ideal to blink in this situation. This commit adds support for the new "panic-indicator" firmware property, allowing to mark a given LED to blink on a kernel panic. Signed-off-by: Ezequiel Garcia Reviewed-by: Matthias Brugger Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

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

2016-05-06T08:22:09Z

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 Reviewed-by: Matthias Brugger Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: ss4200: add DMI data for FSC SCALEO Home Server

2016-04-19T07:03:20Z

The Intel NAS SS4200 was also sold by Fujitsu Siemens (FSC) under the name "SCALEO Home Server". The hardware is equivalent. This patch adds the DMI data of this rebranded device. Signed-off-by: Martin Dummer Signed-off-by: Jacek Anaszewski

leds: ss4200: Add depend on x86 arch

2016-04-19T07:01:19Z

There is only one x86 hardware where the driver leds-ss4200 applies to. Add kconfig dependency to x86 architecture, fix help text whitespace. Signed-off-by: Martin Dummer Signed-off-by: Jacek Anaszewski

leds: ledtrig-ide-disk: Move ide_blink_delay to ledtrig_ide_activity()

2016-04-19T06:57:16Z

Parameters delay_on and delay_off of led_trigger_blink_oneshot() are pointers, to enable blink interval adjustment by LED class drivers of the controllers that implement hardware blinking. Move ide_blink_delay variable to ledtrig_ide_activity() in order to prevent the situation when adjustment committed by one LED class driver influences blink interval of the software fallback blink feature, that is applied to the drivers that don't implement blink_set op. Reviewed-by: Boris Brezillon Signed-off-by: Jacek Anaszewski

leds: tca6507: silence an uninitialized variable warning

2016-04-14T11:08:58Z

If choose_times() returns -EINVAL that means "c1" and "c2" haven't been initialized. I've added a check for that. Signed-off-by: Dan Carpenter Signed-off-by: Jacek Anaszewski