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>

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: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

If choose_times() returns -EINVAL that means "c1" and "c2" haven't been
initialized.  I've added a check for that.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

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: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

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: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Instead of using the WMI wrapper, dell-led can take advantage of
dell_smbios_send_request() for performing the SMBIOS calls required to
change 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>

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>

led_trigger_store can be significantly simplified by using sysfs_streq().
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Switch to resource-managed function devm_led_classdev_register instead
of led_classdev_register and remove unneeded led_classdev_unregister.

Also, remove platform_set_drvdata in probe function and the remove
function, max8997_led_remove as it is now has nothing to do.

The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e;
@@
probefn(struct platform_device *pdev, ...) {
  ...
  e =
- led_classdev_register
+ devm_led_classdev_register
  (...);
   ...
?- led_classdev_unregister(...);
  ...
}
@remove depends on prb@
identifier platform.removefn;
@@
removefn(...) {
...
?- led_classdev_unregister(...);
...
}
//</smpl>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Switch to resource-managed function devm_led_classdev_register instead
of led_classdev_register and remove unneeded led_classdev_unregister.

Also, remove platform_set_drvdata in probe function and the remove
function, da903x_led_remove as it is now has nothing to do.

The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e;
@@
probefn(struct platform_device *pdev, ...) {
  ...
  e =
- led_classdev_register
+ devm_led_classdev_register
  (...);
   ...
?- led_classdev_unregister(...);
  ...
}
@remove depends on prb@
identifier platform.removefn;
@@
removefn(...) {
...
?- led_classdev_unregister(...);
...
}
//</smpl>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Switch to resource-managed function devm_led_classdev_register instead
of led_classdev_register and remove unneeded led_classdev_unregister.

Also, remove unnecessary function pdev_to_gpio, platform_set_drvdata
in the probe function and the remove function, s3c24xx_led_remove as
it is now has nothing to do.

The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e;
@@
probefn(struct platform_device *pdev, ...) {
  ...
  e =
- led_classdev_register
+ devm_led_classdev_register
  (...);
   ...
?- led_classdev_unregister(...);
  ...
}
@remove depends on prb@
identifier platform.removefn;
@@
removefn(...) {
...
?- led_classdev_unregister(...);
...
}
//</smpl>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Switch to resource-managed function devm_led_classdev_register instead
of led_classdev_register and remove unneeded led_classdev_unregister.

Also, remove platform_set_drvdata from probe function and the remove
function, wm831x_status_remove as it is now has nothing to do.

The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e;
@@
probefn(struct platform_device *pdev, ...) {
  ...
  e =
- led_classdev_register
+ devm_led_classdev_register
  (...);
   ...
?- led_classdev_unregister(...);
  ...
}
@remove depends on prb@
identifier platform.removefn;
@@
removefn(...) {
...
?- led_classdev_unregister(...);
...
}
//</smpl>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Switch to resource-managed function devm_led_classdev_register instead
of led_classdev_register and remove unneeded led_classdev_unregister.

Also, remove platform_set_drvdata in probe function and the remove
function, lp8788_led_remove as it is now has nothing to do.

The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e;
@@
probefn(struct platform_device *pdev, ...) {
  ...
  e =
- led_classdev_register
+ devm_led_classdev_register
  (...);
   ...
?- led_classdev_unregister(...);
  ...
}
@remove depends on prb@
identifier platform.removefn;
@@
removefn(...) {
...
?- led_classdev_unregister(...);
...
}
//</smpl>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Switch to resource-managed function devm_led_classdev_register instead
of led_classdev_register and remove unneeded led_classdev_unregister.

Also, remove platform_set_drvdata in probe function and the remove
function, pm860x_led_remove as it is now has nothing to do.

The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e;
@@
probefn(struct platform_device *pdev, ...) {
  ...
  e =
- led_classdev_register
+ devm_led_classdev_register
  (...);
   ...
?- led_classdev_unregister(...);
  ...
}
@remove depends on prb@
identifier platform.removefn;
@@
removefn(...) {
...
?- led_classdev_unregister(...);
...
}
//</smpl>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.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>

Switch to resource-managed function devm_led_classdev_register instead
of led_classdev_register and remove unneeded led_classdev_unregister.

To be compatible with this change, remove an unnecessary label by
replacing it with direct return statement.

The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
  .probe = probefn,
  .remove = removefn,
};

@prb@
identifier platform.probefn, pdev;
expression e;
@@
probefn(struct platform_device *pdev, ...) {
  ...
  e =
- led_classdev_register
+ devm_led_classdev_register
  (...);
   ...
?- led_classdev_unregister(...);
  ...
}
@remove depends on prb@
identifier platform.removefn;
@@
removefn(...) {
...
?- led_classdev_unregister(...);
...
}
//</smpl>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Use the GPIO flag definition instead of a numeric literal, so the casual
reader grepping for GPIOF_ will find the GPIO flags used.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Add helpers for calling brightness_set(_blocking) allowing to
simplify the code and make it better readable.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

In case of error, the function gpio_to_desc() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value
check should be replaced with NULL test.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Improve the wording for the comment about the led status, and while at
it also use the standard formatting for multi-line comments.
Signed-off-by: NAntonio Ospite <ao2@ao2.it>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

When a USB LED device is unplugged the remove call chain calls
led_classdev_unregister which tries to switch the LED off.
As the device has been removed already this results in a ENODEV
error message in dmesg.
Avoid this error message by ignoring ENODEV in calls from
led_classdev_unregister if the LED device is flagged as pluggable.

Therefore a new flag LED_HW_PLUGGABLE was introduced which should be set by
all LED drivers handling pluggable LED devices (mainly USB LED devices).
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().

Cc: Riku Voipio <riku.voipio@iki.fi>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().

Cc: Riku Voipio <riku.voipio@iki.fi>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Acked-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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>

Complementing devm_led_classdev_register add a managed version of
led_trigger_register.

I omit a managed version of led_classdev_unregister as the equivalent
devm_led_classdev_unregister isn't used in the kernel as of today.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

The busy status checking isn't needed while reading initial LED status.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

BCM6328 controller has a margin of 20ms per blink step, which means that
we can only set it to 20, 40, 60 ... 1260 ms (0x3f * 20ms).
However, when checking if delay_on == delay_off, we were not considering
the case when the user had set delay_on=20 and delay_off=21, since this
will cause the driver to fallback to software blinking.
This update fixes this issue and improves blink steps by rounding them
in a more sensible way. Now 30-49ms is rounded to 40 ms, and previous
behaviour implied 40-59ms being rounded to 40 ms.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

bcm6358_led_mode is now only called by bcm6358_led_set, so merge both
in one single function.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Instead of duplicating the unlock we can store the return value and use a
single unlock before returning that value, which simplifies the code.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

This adds little endian support while keeping big endian support.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

This adds little endian support while keeping big endian support.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

This lock isn't really needed, since we're only reading the register and
changes made to other LEDs aren't relevant.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Replaces bcm6358_led_mode with bcm6358_led_set so we don't need to handle
the lock.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

This lock isn't really needed, since we're only reading the register and
changes made to other LEDs aren't relevant.
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

- Remove double whitespace
- Add missing brackets
- Add spinlock info
Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

The Kconfig currently controlling compilation of this code is:

drivers/leds/Kconfig:config LEDS_SYSCON
drivers/leds/Kconfig:   bool "LED support for LEDs on system controllers"

...meaning that it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.

Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.

Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

The Kconfig for this driver is currently:

config LEDS_TRIGGER_IDE_DISK
        bool "LED IDE Disk Trigger"

...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

The Kconfig for this driver is currently:

config LEDS_TRIGGER_CPU
        bool "LED CPU Trigger"

...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-leds@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

These new helpers simplify implementing multi-driver modules and
properly handle failure to register one driver by unregistering all
previously registered drivers.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>