linux.git/drivers/leds, branch v4.7-rc2

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:15+00:00

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:02+00:00

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:07+00:00

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:09+00:00

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:20+00:00

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:19+00:00

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:16+00:00

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:58+00:00

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

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

2016-04-13T08:23:14+00:00

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 
Acked-by: Boris Brezillon 
Signed-off-by: Jacek Anaszewski

leds: trigger: Introduce a kernel panic LED trigger

2016-03-30T09:16:39+00:00

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