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>

Instead of unusual "if (!ret)" use "if (ret)" in lp3952_get_label().
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
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>

It should be ">= MT6323_MAX_LEDS" instead of ">".  Also "reg" is a u32
so it can't be negative and we can remove the test for negative values.

Fixes: 216ec6cc ("leds: Add LED support for MT6323 PMIC")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
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>

In leds-gpio we support LEDs specified in DT so we should use
(devm_)of_led_classdev_register. This allows passing DT node as argument
for use by the LED subsystem.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

These new functions allow passing an additional device_node argument
that will be internally set for created LED device. Thanks to this LED
core code and triggers will be able to access DT node for reading extra
info.

The easiest solution for achieving this was reworking old functions to
more generic ones & adding simple defines for API compatibility.
Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NPavel Machek <pavel@ucw.cz>
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>

To ensure all users of dell-smbios are in drivers/platform/x86, move the
dell_micmute_led_set() method from drivers/leds/dell-led.c to
drivers/platform/x86/dell-laptop.c.
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: NAndy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

The dell_app_wmi_led_set() method introduced in commit db6d8cc0
("dell-led: add mic mute led interface") was implemented as an easily
extensible entry point for other modules to set the state of various
LEDs.  However, almost three years later it is still only used to
control the mic mute LED, so it will be replaced with direct calls to
dell_micmute_led_set().
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: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

As dell_micmute_led_set() no longer uses the dell_wmi_perform_query()
method, which was removed in commit 0c41a08e ("dell-led: use
dell_smbios_send_request() for performing SMBIOS calls"), the
DELL_APP_GUID check is redundant and thus can be safely removed.
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>

Currently there is one CPU led trigger per cpu ('cpu0', 'cpu1', ...)

This patch adds a new trigger, 'cpu', with brightness proportional to
the number of active CPUs.

If multiple brightness levels aren't supported on the LED,
it effectively indicates if there is any CPU active.

This is particularly useful on tiny linux boards with more CPU cores than LED pins.
Signed-off-by: NPaulo Costa <me@paulo.costa.nom.br>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

We are going to split <linux/sched/loadavg.h> out of <linux/sched.h>, which
will have to be picked up from a couple of .c files.

Create a trivial placeholder <linux/sched/topology.h> file that just
maps to <linux/sched.h> to make this patch obviously correct and
bisectable.

Include the new header in the files that are going to need it.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

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>

LED class heartbeat trigger allowed only for blinking with max_brightness
value. This patch adds more flexibility by exploiting part of LED core
software blink infrastructure.
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>

Rename devm_get_gpiod_from_child() into
devm_fwnode_get_gpiod_from_child() to reflect the fact that this
function is operating on a fwnode object.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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>

gcc gets confused about the control flow in ktd2692_parse_dt(), causing
it to warn about what seems like a potential bug:

drivers/leds/leds-ktd2692.c: In function 'ktd2692_probe':
drivers/leds/leds-ktd2692.c:244:15: error: '*((void *)&led_cfg+8)' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/leds/leds-ktd2692.c:225:7: error: 'led_cfg.flash_max_microamp' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/leds/leds-ktd2692.c:232:3: error: 'led_cfg.movie_max_microamp' may be used uninitialized in this function [-Werror=maybe-uninitialized]

The code is fine, and slightly reworking it in an equivalent way lets
gcc figure that out too, which gets rid of the warning.

Fixes: 77e7915b ("leds: ktd2692: Add missing of_node_put")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>

Currently all users of fwnode_get_named_gpiod() have no way to
specify a label for the GPIO. So GPIOs listed in debugfs are shown
with label "?". With this change a proper label is used.

Also adjust all users so they can pass a label, properly retrieved
from device tree properties.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Make fwnode_get_named_gpiod() consistent with the rest of
gpiod_get() like API, i.e. configure GPIO pin immediately after
request.

Besides obvious clean up it will help to configure pins based
on firmware provided resources.
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

PWM devices have all been marked as "might sleep" since v4.5. It no
longer makes sense to keep the alternative code paths around because
it is effectively dead code.
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

When the state names got added a script was used to add the extra argument
to the calls. The script basically converted the state constant to a
string, but the cleanup to convert these strings into meaningful ones did
not happen.

Replace all the useless strings with 'subsys/xxx/yyy:state' strings which
are used in all the other places already.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20161221192112.085444152@linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

This patch enables ACPI support for leds-pca955x driver.
Signed-off-by: NTin Huynh <tnhuynh@apm.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/leds//leds-netxbig.ko | grep alias
alias:          platform:leds-netxbig

After this patch:

$ modinfo drivers/leds//leds-netxbig.ko | grep alias
alias:          platform:leds-netxbig
alias:          of:N*T*Clacie,netxbig-ledsC*
alias:          of:N*T*Clacie,netxbig-leds
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

This patch enables ACPI support for leds-pca963x driver.
Signed-off-by: NTin Huynh <tnhuynh@apm.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

All 3 of led_timer_func, led_set_brightness and led_set_software_blink
set blink_brightness. If led_timer_func or led_set_software_blink race
with led_set_brightness they may end up overwriting the new
blink_brightness. The new atomic work_flags does not protect against
this as it just protects the flags and not blink_brightness.

This commit introduces a new new_blink_brightness value which gets
set by led_set_brightness and read by led_timer_func on LED on, fixing
this.

Dealing with the new brightness at LED on time, makes the new
brightness apply sooner, which also fixes a led_set_brightness which
happens while a oneshot blink which ends in LED on is running not
getting applied.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

All the LED_BLINK* flags are accessed read-modify-write from e.g.
led_set_brightness and led_blink_set_oneshot while both
set_brightness_work and the blink_timer may be running.

If these race then the modify step done by one of them may be lost,
switch the LED_BLINK* flags to a new atomic work_flags bit-field
to avoid this race.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.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>

Verify that vendor is Mellanox as the first step of initialization.
If it is not - return ENODEV.
Change module license from "GPL v2" to "Dual BSD/GPL".
Signed-off-by: NVadim Pasternak <vadimp@mellanox.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Allow chip to enter low power state when no LEDs are being lit or in
blink mode.

Cc: Peter Meerwald <p.meerwald@bct-electronic.com>,
Cc: Ricardo Ribalda <ricardo.ribalda@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NMatt Ranostay <matt@ranostay.consulting>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

The value for a led's default_trigger should come from platform data
instead of data (which is always 0).
Signed-off-by: NFelix Brack <fb@ltec.ch>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

PCA9632TK part seems to incorrectly blink at ~1.3x of the programmed
rate. This patchset add a nxp,period-scale devicetree property to
adjust for this misconfiguration.
Signed-off-by: NMatt Ranostay <matt@ranostay.consulting>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

If the driver is built as a module, I2C module alias information is not
filled so the module won't be autoloaded if the device isn't registered
over ACPI. Export the I2C device table alias with MODULE_DEVICE_TABLE()
macro so the information is exported in the module.

Before this patch:

$ modinfo drivers/leds/leds-lp3952.ko | grep alias
alias:          acpi*:TXNW3952:*

After this patch:

$ modinfo drivers/leds/leds-lp3952.ko | grep alias
alias:          i2c:lp3952
alias:          acpi*:TXNW3952:*
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Fix the register access shift argument calculation introduced with
commit a59ce658 ("leds: leds-mc13783: Add MC34708 LED support")
and re-enable access to the "keypad" led for MC13892 MFC devices.
Signed-off-by: NAlexander Kurz <akurz@blala.de>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Fix english spelling.
Signed-off-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Use a macro instead of hard-coding the max device node name size. The
uleds driver introduced a macro for this value, so using it.
Signed-off-by: NDavid Lechner <david@lechnology.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>