Introducing the LM3692x Dual-String white LED driver.

Data sheet is located
http://www.ti.com/lit/ds/snvsa29/snvsa29.pdfSigned-off-by: NDan Murphy <dmurphy@ti.com>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

This patch implements the driver to support the front panel LEDs
for PC Engines APU and APU2 boards.
Signed-off-by: NAlan Mizrahi <alan@mizrahi.com.ve>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

We get a link error when V4L2_FLASH_LED_CLASS=m and AS3645A is built-in:

drivers/leds/leds-as3645a.o: In function `as3645a_v4l2_setup':
leds-as3645a.c:(.text+0x258): undefined reference to `v4l2_flash_init'
leds-as3645a.c:(.text+0x284): undefined reference to `v4l2_flash_indicator_init'
leds-as3645a.c:(.text+0x2a4): undefined reference to `v4l2_flash_release'
drivers/leds/leds-as3645a.o: In function `as3645a_remove':
leds-as3645a.c:(.text+0x784): undefined reference to `v4l2_flash_release'

This adds the same Kconfig dependency that the other V4L2 flash
drivers in drivers/leds use, to avoid that broken configuration.

Fixes: a56ba8fb ("media: leds: as3645a: Add LED flash class driver")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Add a LED flash class driver for the as3654a flash controller. A V4L2 flash
driver for it already exists (drivers/media/i2c/as3645a.c), and this driver
is based on that.
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The PCA955x family of chips are I2C LED blinkers whose pins not used
to control LEDs can be used as general purpose I/Os (GPIOs).

The following adds such a support by defining different operation
modes for the pins (See bindings documentation for more details). The
pca955x driver is then extended with a gpio_chip when some of pins are
operating as GPIOs. The default operating mode is to behave as a LED.

The GPIO support is conditioned by CONFIG_LEDS_PCA955X_GPIO.
Signed-off-by: NCédric Le Goater <clg@kaod.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

SEAD3 is using the generic syscon & regmap based register-bit-led
driver as of commit c764583f ("MIPS: SEAD3: Use register-bit-led
driver via DT for LEDs") merged in the v4.9 cycle. As such the custom
SEAD-3 LED driver is now unused, so remove it.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

All users of the Versatile LED driver are deleted and replaced
with the very generic leds-syscon. Delete the old driver.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

Motorola CPCAP is a PMIC (power management integrated circuit) found
in multiple smartphones. This driver adds support for the chip's LED
controllers. This introduces support for all controllers used by the
Droid 4. According to Motorola's driver (no datasheets available)
there a couple of more LED controllers. I did not add support for
them, since I cannot verify that they work with my modifications.
Signed-off-by: NSebastian Reichel <sre@kernel.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

In ACPI world any ID should be carefully chosen and registered
officially. The discussion [1] as I read it gets to wilful assignment
an ID for non-existing real DSDT example.

Rafael already told [2] how this device would be enumerated using
compatible string. To be more precise look at the possible DSDT excerpt
below:

	Device (LDX0) {
		Name (_HID, "PRP0001")
		Name (_DDN, "TI LP3952 compatible led driver")
		...
	})

	Name (_DSD, Package () {
		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
		Package () {
			Package () {"compatible", "ti,lp3952"},
			...
		}
	})

Based on above, remove non-official ACPI IDs and enumeration from the
driver.

Note: currently driver has no compatible strings at all, to make above
working one should add at least one.

[1] https://e2e.ti.com/support/power_management/led_driver/f/192/t/524926
[2] https://www.spinics.net/lists/linux-acpi/msg67125.html

Cc: Tony Makkiel <tony.makkiel@daqri.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

MT6323 PMIC is a multi-function device that includes LED function.
It allows attaching up to 4 LEDs which can either be on, off or dimmed
and/or blinked with the controller.
Signed-off-by: NSean Wang <sean.wang@mediatek.com>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

The dell-led driver handles a specific WMI GUID present on some Dell
laptops and as such it belongs in the x86 platform driver subsystem.
Source code is moved along with the relevant Kconfig and Makefile
entries, with some minor modifications:

  - Kconfig option is renamed from CONFIG_LEDS_DELL_NETBOOKS to
    CONFIG_DELL_WMI_LED,

  - the X86 Kconfig dependency is removed as the whole
    drivers/platform/x86 menu depends on it, so there is no need to
    duplicate it,

  - the name of the module's source file is removed from the header
    comment to avoid the need to update it in the future.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NAlex Hung <alex.hung@canonical.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

With dell_micmute_led_set() moved to drivers/platform/x86/dell-laptop.c,
all remnants of the mic mute LED handling code can be removed from
drivers/leds/dell-led.c, restoring it back to the state it was in before
commit db6d8cc0 ("dell-led: add mic mute led interface").
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NAlex Hung <alex.hung@canonical.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

Some LEDs may have their brightness level changed autonomously
(outside of kernel control) by hardware / firmware. This commit
adds support for an optional brightness_hw_changed attribute to
signal such changes to userspace (if a driver can detect them):

What:		/sys/class/leds/<led>/brightness_hw_changed
Date:		January 2017
KernelVersion:	4.11
Description:
		Last hardware set brightness level for this LED. Some LEDs
		may be changed autonomously by hardware/firmware. Only LEDs
		where this happens and the driver can detect this, will
		have this file.

		This file supports poll() to detect when the hardware
		changes the brightness.

		Reading this file will return the last brightness level set
		by the hardware, this may be different from the current
		brightness.

Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to
their flags field and call led_classdev_notify_brightness_hw_changed()
with the hardware set brightness when they detect a hardware / firmware
triggered brightness change.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

Some LEDs may have their brightness level changed autonomously
(outside of kernel control) by hardware / firmware. This commit
adds support for an optional brightness_hw_changed attribute to
signal such changes to userspace (if a driver can detect them):

What:		/sys/class/leds/<led>/brightness_hw_changed
Date:		January 2017
KernelVersion:	4.11
Description:
		Last hardware set brightness level for this LED. Some LEDs
		may be changed autonomously by hardware/firmware. Only LEDs
		where this happens and the driver can detect this, will
		have this file.

		This file supports poll() to detect when the hardware
		changes the brightness.

		Reading this file will return the last brightness level set
		by the hardware, this may be different from the current
		brightness.

Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to
their flags field and call led_classdev_notify_brightness_hw_changed()
with the hardware set brightness when they detect a hardware / firmware
triggered brightness change.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

Add the driver to support User LEDs on PXI Embedded Controller.
Signed-off-by: NHui Chun Ong <hui.chun.ong@ni.com>
Signed-off-by: NBrad Mouring <brad.mouring@ni.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

This driver creates a userspace leds driver similar to uinput.

New LEDs are created by opening /dev/uleds and writing a uleds_user_dev
struct. A new LED class device is registered with the name given in the
struct. Reading will return a single byte that is the current brightness.
The poll() syscall is also supported. It will be triggered whenever the
brightness changes. Closing the file handle to /dev/uleds will remove
the leds class device.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

The Kconfig and file naming for the PM8xxx driver is totally
confusing:

- Kconfig options MFD_PM8XXX and MFD_PM8921_CORE, some in-kernel
  users depending on or selecting either at random.
- A driver file named pm8921-core.c even if it is indeed
  used by the whole PM8xxx family of chips.
- An irqchip named pm8xxx since it was (I guess) realized that
  the driver was generic for all pm8xxx PMICs.

As I may want to add support for PM8901 this is starting to get
really messy. Fix this situation by:

- Remove the MFD_PM8921_CORE symbol and rely solely on MFD_PM8XXX
  and convert all users, including LEDs Kconfig and ARM defconfigs
  for qcom and multi_v7 to use that single symbol.
- Renaming the driver to qcom-pm8xxx.c to fit along the two
  other qcom* prefixed drivers.
- Rename functions withing the driver from 8921 to 8xxx to
  indicate it is generic.
- Just drop the =m config from the pxa_defconfig, I have no clue
  why it is even there, it is not a Qualcomm platform. (Possibly
  older Kconfig noise from saveconfig.)

Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NAndy Gross <andy.gross@linaro.org>
Acked-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This makes it possible to create a set of LEDs for Mellanox systems:
"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410",
"msb7800", "msn2740", "msn2100".

Driver obtains LED devices according to system configuration, provided
through system DMI data, like mlxcpld:fan1:green, mlxcpld:fan1:red and
creates devices in form: "devicename:colour:function".

LED setting is controlled through on board CPLD Lattice device.
For setting particular LED off, solid, blink:
echo 0 > /sys/class/leds/mlxcpld\:status\:green/brightness
echo 1 > /sys/class/leds/mlxcpld\:status\:green/brightness
echo timer > /sys/class/leds/mlxcpld\:status\:green/trigger

On module probing all LEDs are set green, on removing - off.

Last setting overwrites previous, f.e. sequence for
changing LED from green - red - green:
echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness
echo 1 > /sys/class/leds/mlxcpld\:psu\:red/brightness
echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness
Note: LEDs cannot be turned on/off simultaneously.

The Kconfig currently controlling compilation of this code is:
drivers/leds/Kconfig:config LEDS_MLXCPLD
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Reviewed-by: NJiri Pirko <jiri@mellanox.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

This adds a driver for the six PM8058 LEDs, three ordinary LEDs,
two "flash" LEDs and one "keypad" LED.

The "keypad" and "flash" LEDs are not really hard-wired to these
usecases: for example on the APQ8060 Dragonboard, the "keypad"
LED is instead used to drive an IR LED used for the proximity
sensor. The "flash" LEDs are just ordinary high-current LED
drivers.

Cc: linux-arm-msm@vger.kernel.org
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

This is a driver for the Integrated Silicon Solution Inc. LED driver
chips series IS31FL319x. They can drive 1, 3, 6  or up to 9
LEDs.

Each LED is individually controllable in brightness (through pwm)
in 256 steps so that RGB LEDs can show any of ca. 16 Mio colors.

The maximum current of the LEDs can be programmed and limited to
5 .. 40mA through a device tree property.

The chip is connected through I2C and can have one of 4 addresses
in the range 0x64 .. 0x67 depending on how the AD pin is connected. The
address is defined by the reg property as usual.

The chip also has a shutdown input which could be connected to a GPIO,
but this driver uses software shutdown if all LEDs are inactivated.

The chip also has breathing and audio features which are not fully
supported by this driver.

Tested-on: OMAP5 based Pyra handheld prototype.
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NAndrey Utkin <andrey_utkin@fastmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

The chip can drive 2 sets of RGB leds. Controller can
be controlled via PWM, I2C and audio synchronisation.
This driver uses I2C to communicate with the chip.

Datasheet: http://www.ti.com/lit/gpn/lp3952Signed-off-by: NTony Makkiel <tony.makkiel@daqri.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

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: NMartin Dummer <martin.dummer@gmx.net>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

With the advent of dell_smbios_find_token(), dell-led does not need to
perform any DMI walking on its own, but it can rather ask dell-smbios to
look up the DMI tokens it needs for changing the state of the microphone
LED.
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>

Si-En Technology was acquired by ISSI in 2011, and it appears that
the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.

Add the "si-en,sn3218" and "si-en,sn3216" compatible strings into the
IS31FL32XX driver as aliases for the issi equivalents, and update
binding documentation.

Datasheets:
    IS31FL3218: http://www.issi.com/WW/pdf/31FL3218.pdf
    SN3218:     http://www.si-en.com/uploadpdf/s2011517171720.pdf

    IS31FL3216: http://www.issi.com/WW/pdf/31FL3216.pdf
    SN3216:     http://www.si-en.com/uploadpdf/SN3216201152410148.pdfSigned-off-by: NDavid Rivshin <drivshin@allworx.com>
Acked-by: NRob Herring <robh@kernel.org>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

The IS31FL32xx family of LED controllers are I2C devices with multiple
constant-current channels, each with independent 256-level PWM control.

Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml

This has been tested on the IS31FL3236 and IS31FL3216, on an ARM
(TI am335x) platform.

The programming paradigm of these devices is similar in the following
ways:
 - All registers are 8 bit
 - All LED control registers are write-only
 - Each LED channel has a PWM register (0-255)
 - PWM register writes are shadowed until an Update register is poked
 - All have a concept of Software Shutdown, which disables output

However, there are some differences in devices:
 - 3236/3235 have a separate Control register for each LED,
   (3218/3216 pack the enable bits into fewer registers)
 - 3236/3235 have a per-channel current divisor setting
 - 3236/3235 have a Global Control register that can turn off all LEDs
 - 3216 is unique in a number of ways
    - OUT9-OUT16 can be configured as GPIOs instead of LED controls
    - LEDs can be programmed with an 8-frame animation, with
      programmable delay between frames
    - LEDs can be modulated by an input audio signal
    - Max output current can be adjusted from 1/4 to 2x globally
    - Has a Configuration register instead of a Shutdown register

This driver currently only supports the base PWM control function
of these devices. The following features of these devices are not
implemented, although it should be possible to add them in the future:
 - All devices are capable of going into a lower-power "software
   shutdown" mode.
 - The is31fl3236 and is31fl3235 can reduce the max output current
   per-channel with a divisor of 1, 2, 3, or 4.
 - The is31fl3216 can use some LED channels as GPIOs instead.
 - The is31fl3216 can animate LEDs in hardware.
 - The is31fl3216 can modulate LEDs according to an audio input.
 - The is31fl3216 can reduce/increase max output current globally.
Signed-off-by: NDavid Rivshin <drivshin@allworx.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Ran into this on UML:

drivers/built-in.o: In function `bcm6328_leds_probe':
drivers/leds/leds-bcm6328.c:340: undefined reference to `devm_ioremap_resource'
drivers/built-in.o: In function `bcm6358_leds_probe':
drivers/leds/leds-bcm6358.c:173: undefined reference to `devm_ioremap_resource'
collect2: error: ld returned 1 exit status

devm_ioremap_resource() is defined only when HAS_IOMEM is selected.
Signed-off-by: NVegard Nossum <vegard.nossum@oracle.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Fixes the following randconfig problem

leds-sead3.c:(.text+0x7dc): undefined reference to `led_classdev_unregister'
leds-sead3.c:(.text+0x7e8): undefined reference to `led_classdev_unregister'
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-leds@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

The commit [b6789320: leds:lp55xx: fix firmware loading error]
tries to address the firmware file handling with user helper, but it
sets a wrong Kconfig CONFIG_FW_LOADER_USER_HELPER_FALLBACK.  Since the
wrong option was enabled, the system got a regression -- it suffers
from the unexpected long delays for non-present firmware files.

This patch corrects the Kconfig dependency to the right one,
CONFIG_FW_LOADER_USER_HELPER.  This doesn't change the fallback
behavior but only enables UMH when needed.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=944661
Fixes: b6789320 ('leds:lp55xx: fix firmware loading error')
Cc: <stable@vger.kernel.org> # v4.2+
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Fix missing Kconfig LEDS_CLASS dependency.
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

The leds-ns2 driver is also used by the n090401 board (Seagate NAS
4-Bay), which is based on the Marvell Armada-370 SoC.

Then this patch allows to select the leds-ns2 driver if MACH_ARMADA_370
is enabled. Additionally, this also updates the Kconfig help message.
Signed-off-by: NSimon Guinot <simon.guinot@sequanux.org>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

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.

If COMPILE_TEST is enabled, relax the dependency on GPIOLIB for the
recently introduced symbols LEDS_AAT1290 and LEDS_KTD2692.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

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: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

The Qualcomm PM8941 WLED block is used for backlight and should therefor
be in the backlight framework and not in the LED framework. This moves
the driver and adapts to the backlight api instead.
Signed-off-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Tested-by: NRob Clark <robdclark@gmail.com>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: NJingoo Han <jingoohan1@gmail.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

This patch implements LED driver for PowerNV platform using the existing
generic LED class framework.

PowerNV platform has below type of LEDs:
  - System attention
      Indicates there is a problem with the system that needs attention.
  - Identify
      Helps the user locate/identify a particular FRU or resource in the
      system.
  - Fault
      Indicates there is a problem with the FRU or resource at the
      location with which the indicator is associated.

We register classdev structures for all individual LEDs detected on the
system through LED specific device tree nodes. Device tree nodes specify
what all kind of LEDs present on the same location code. It registers
LED classdev structure for each of them.

All the system LEDs can be found in the same regular path /sys/class/leds/.
We don't use LED colors. We use LED node and led-types property to form
LED classdev. Our LEDs have names in this format.

        <location_code>:<attention|identify|fault>

Any positive brightness value would turn on the LED and a zero value would
turn off the LED. The driver will return LED_FULL (255) for any turned on
LED and LED_OFF (0) for any turned off LED.

The platform level implementation of LED get and set state has been
achieved through OPAL calls. These calls are made available for the
driver by exporting from architecture specific codes.
Signed-off-by: NVasant Hegde <hegdevasant@linux.vnet.ibm.com>
Signed-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
Acked-by: NStewart Smith <stewart@linux.vnet.ibm.com>
Tested-by: NStewart Smith <stewart@linux.vnet.ibm.com>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

LP55xx driver uses not firmware file but raw data to load program through
the firmware interface.(Documents/leds/leds-lp55xx.txt)

  For example, here is how to run blinking green channel pattern.
  (The second engine is seleted and MUX is mapped to 'RGB' mode)
  echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
  echo "RGB" > /sys/bus/i2c/devices/xxxx/engine_mux
  echo 1 > /sys/class/firmware/lp5562/loading
  echo "4000600040FF6000" > /sys/class/firmware/lp5562/data
  echo 0 > /sys/class/firmware/lp5562/loading
  echo 1 > /sys/bus/i2c/devices/xxxx/run_engine

However, '/sys/class/firmware/<device name>' is not created after the
firmware loader user helper was introduced.
This feature is used in the case below.

  As soon as the firmware download is requested by the driver, firmware
  class subsystem tries to find the binary file.
  If it gets failed, then it just falls back to user helper to load
  raw data manually. Here, you can see the device file under
  /sys/class/firmware/.

To make it happen, LP55xx driver requires two configurations.

  1. Enable CONFIG_FW_LOADER_USER_HELPER_FALLBACK in Kconfig
  2. Set option, 'FW_OPT_USERHELPER' on requesting the firmware data.
     It means the second option should be 'false' in
     request_firmware_nowait().
     This option enables to load firmware data manually by calling
     fw_load_from_user_helper().

Cc: linux-leds@vger.kernel.org
Signed-off-by: NMilo Kim <milo.kim@ti.com>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

Fix build errors when LEDS_MAX77693=y and V4L2_FLASH_LED_CLASS=m
by restricting LEDS_MAX77693 to =m if V4L2_FLASH_LED_CLASS=m.

drivers/leds/leds-max77693.c:1062: undefined reference to `v4l2_flash_release'
drivers/leds/leds-max77693.c:1068: undefined reference to `v4l2_flash_release'
drivers/built-in.o: In function `max77693_register_led':
drivers/leds/leds-max77693.c:968: undefined reference to `v4l2_flash_init'
drivers/built-in.o: In function `max77693_led_probe':
drivers/leds/leds-max77693.c:1048: undefined reference to `v4l2_flash_release'
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

Fix build errors when LEDS_AAT1290=y and V4L2_FLASH_LED_CLASS=m
by restricting LEDS_AAT1290 to =m if V4L2_FLASH_LED_CLASS=m.

drivers/built-in.o: In function `aat1290_led_remove':
leds-aat1290.c:(.text+0xe5d77): undefined reference to `v4l2_flash_release'
drivers/built-in.o: In function `aat1290_led_probe':
leds-aat1290.c:(.text+0xe6494): undefined reference to `v4l2_flash_init'
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

Add support for V4L2 Flash sub-device to the aat1290 LED Flash class
driver. The support allows for V4L2 Flash sub-device to take the control
of the LED Flash class device.
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

This change creates a new input handler called "leds" that exports LEDs on input
devices as standard LED class devices in sysfs and allows controlling their
state via sysfs or via any of the standard LED triggers. This allows to
re-purpose and reassign LDEs on the keyboards to represent states other
than the standard keyboard states (CapsLock, NumLock, etc).

The old API of controlling input LEDs by writing into /dev/input/eventX
devices is still present and will take precedence over accessing via LEDs
subsystem (i.e. it may override state set by a trigger). If input device is
"grabbed" then requests coming through LED subsystem will be ignored.
Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
Tested-by: NPavel Machek <pavel@ucw.cz>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This adds support for the LED controller on Broadcom's BCM6358.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>