pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()

In order to introduce a pwm api which can be used from atomic context,
we will need two functions for applying pwm changes:

int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
int pwm_apply_atomic(struct pwm *, struct pwm_state *);

This commit just deals with renaming pwm_apply_state(), a following
commit will introduce the pwm_apply_atomic() function.

Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

leds: pwm: Don't disable the PWM when the LED should be off

Disabling a PWM (i.e. calling pwm_apply_state with .enabled = false)
gives no guarantees what the PWM output does. It might freeze where it
currently is, or go in a High-Z state or drive the active or inactive
state, it might even continue to toggle.

To ensure that the LED gets really disabled, don't disable the PWM even
when .duty_cycle is zero.

This fixes disabling a leds-pwm LED on i.MX28. The PWM on this SoC is
one of those that freezes its output on disable, so if you disable an
LED that is full on, it stays on. If you disable a LED with half
brightness it goes off in 50% of the cases and full on in the other 50%.

Fixes: 41c42ff5dbe2 ("leds: simple driver for pwm driven LEDs")
Reported-by: Rogan Dawes <rogan@dawes.za.net>
Reported-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20230922192834.1695727-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>

leds: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230714174651.4058753-1-robh@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>

leds: pwm: Fix error code in led_pwm_create_fwnode()

Negative -EINVAL was intended, not positive EINVAL. Fix it.

Fixes: 95138e01275e ("leds: pwm: Make error handling more robust")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/a33b981a-b2c4-4dc2-b00a-626a090d2f11@moroto.mountain
Signed-off-by: Lee Jones <lee@kernel.org>

leds: pwm: Clear the led structure before parsing each child node

I defined 2 leds in the device tree, in the 1st led node, the
max-brightness is set to 248, while in the 2nd led node, I
mis-spelled the max-brightness to max-brighttness, but the driver
is still able to get the max-brightness 248 for the 2nd node, that
is because the led structure is not cleared before parsing each child
node.

pwmleds {
compatible = "pwm-leds";

pwm-green {
...
max-brightness = <248>;
};

pwm-red {
...
max-brighttness = <128>;
};

Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20221220073335.393489-1-hui.wang@canonical.com

leds: pwm: add support for default-state device property

This patch adds support for "default-state" devicetree property, which
allows to defer pwm init to first use of led.

This allows to configure the PWM early in bootloader to let the LED
blink until an application in Linux userspace sets something different.

Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: Make error handling more robust

It's easy to miss necessary clean up, e.g. firmware node reference counting,
during error path in ->probe(). Make it more robust by moving to a single
point of return.

Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: Remove platform_data support

Since commit 141f15c66d94 ("leds: pwm: remove header") that platform
interface is not usable from outside and there seems to be no in tree
user anymore. All in-tree users of the leds-pwm driver seem to use DT
currently. Getting rid of the old platform interface allows the
leds-pwm driver to switch over from 'devm_led_classdev_register()' to
'devm_led_classdev_register_ext()'.

Signed-off-by: Alexander Dahl <post@lespocky.de>
Cc: Denis Osterland-Heim <denis.osterland@diehl.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: parse linux,default-trigger DT property in LED core

Do the parsing of `linux,default-trigger` DT property to LED core.
Currently it is done in many different drivers and the code is repeated.

This patch removes the parsing from 23 drivers:
an30259a, aw2013, bcm6328, bcm6358, cr0014114, el15203000, gpio,
is31fl32xx, lm3532, lm36274, lm3692x, lm3697, lp50xx, lp8860, lt3593,
max77650, mt6323, ns2, pm8058, pwm, syscon, tlc591xx and turris-omnia.

There is one driver in drivers/input which parses this property on it's
own. I shall send a separate patch there after this is applied.

There are still 8 drivers that parse this property on their own because
they do not pass the led_init_data structure to the registering
function. I will try to refactor those in the future.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: Allow automatic labels for DT based devices

If LEDs are configured through device tree and the property 'label' is
omitted, the label is supposed to be generated from the properties
'function' and 'color' if present. While this works fine for e.g. the
'leds-gpio' driver, it did not for 'leds-pwm'.

The reason is, you get this label naming magic only if you add a LED
device through 'devm_led_classdev_register_ext()' and pass a pointer to
the current device tree node.

For the following node from dts the LED appeared as 'led-5' in sysfs
before and as 'red:debug' after this change.

pwm_leds {
compatible = "pwm-leds";

led-5 {
function = LED_FUNCTION_DEBUG;
color = <LED_COLOR_ID_RED>;
pwms = <&pwm0 2 10000000 0>;
max-brightness = <127>;

linux,default-trigger = "heartbeat";
panic-indicator;
};
};

Signed-off-by: Alexander Dahl <post@lespocky.de>
Cc: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: Simplify with dev_err_probe()

Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: check result of led_pwm_set() in led_pwm_add()

led_pwm_set() now returns an error when setting the PWM fails.

Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: leds-pwm: Replace zero-length array with flexible-array member

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
int stuff;
struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: remove useless pwm_period_ns

This member seems to was a way to pass PWM period to the LED.
Since there is no header anymore, this is useless.

Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: remove header

The header is only used by leds_pwm.c, so move contents to leds_pwm.c
and remove it.
Apply minor changes suggested by checkpatch.
Remove deprecated and unused pwm_id member.

Suggested-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: convert to atomic PWM API

pwm_config(), pwm_enable() and pwm_disable() should get removed in the
long run. So update the driver to use the atomic API that is here to
stay.

A few side effects:

- led_pwm_set() now returns an error when setting the PWM fails.
- During .probe() the PWM isn't disabled implicitly by pwm_apply_args()
any more.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Tested-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: simplify if condition

.pwm_period_ns is an unsigned integer. So when led->pwm_period_ns > 0
is false, we now assign 0 to a value that is already 0, so it doesn't
hurt and we can skip checking the actual value.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Tested-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: Use struct_size() helper

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct led_pwm_priv {
...
struct led_pwm_data leds[0];
};

Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.

So, replace the following function:

static inline size_t sizeof_pwm_leds_priv(int num_leds)
{
return sizeof(struct led_pwm_priv) +
(sizeof(struct led_pwm_data) * num_leds);
}

with:

struct_size(priv, leds, count)

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

leds: class: Improve LED and LED flash class registration API

Replace of_led_classdev_register() with led_classdev_register_ext(), which
accepts easily extendable struct led_init_data, instead of the fixed
struct device_node argument. The latter can be now passed in an fwnode
property of the struct led_init_data.

The modification is driven by the need for passing additional arguments
required for the forthcoming generic mechanism for composing LED names.
Currently the LED name is conveyed in the "name" char pointer property of
the struct led_classdev. This is redundant since LED class device name
is accessible throughout the whole LED class device life time via
associated struct device's kobj->name property.

The change will not break any existing clients since the patch alters
also existing led_classdev{_flash}_register() macro wrappers, that pass
NULL in place of init_data, which leads to using legacy name
initialization path basing on the struct led_classdev's "name" property.

Three existing users of devm_of_led_classdev_registers() are modified
to use devm_led_classdev_register(), which will not impact their
operation since they in fact didn't need to pass struct device_node on
registration from the beginning.

Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Baolin Wang <baolin.wang@linaro.org>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Daniel Mack <daniel@zonque.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Oleh Kravchenko <oleg@kaa.org.ua>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Simon Shields <simon@lineageos.org>
Acked-by: Pavel Machek <pavel@ucw.cz>

leds: pwm: Support ACPI via firmware-node framework

DT specific handling is replaced by firmware-node abstration to support
ACPI specification of PWM LEDS.

Example ASL:
Device (PWML)
{
Name (_HID, "PRP0001")
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () {"compatible",
Package () {"pwm-leds"}}}})

Device (PWL0)
{
Name (_HID, "PRP0001")
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"label", "alarm-led"},
Package () {"pwms", Package ()
{\_SB_.PCI0.PWM, 0, 600000, 0}},
Package () {"linux,default-state", "off"}}})
}
}

Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

leds: pwm: Use OF variant of LED registering function

The PWM leds can be instantiated from Device Tree so pass the
respective device node to LED core. This provides the LED system with
proper device node and exposes it through uevent.

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

leds: pwm: Simplify with resource-managed devm_led_classdev_register()

Simplify the exit path with resource-managed version of registering LED
class device. The code should be functionally the same, except that on
device removal the led_pwm_priv->num_leds is not decremented to zero
(which should not have any effect as device is going away).

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

leds: pwm: silently error out on EPROBE_DEFER

When probing, if we fail to get the pwm due to probe deferal, we shouldn't
print an error message. Just be silent in this case.

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

leds: pwm: Remove unneeded header file

There is nothing provided by <linux/fb.h> that is used here,
so remove this unneeded header file.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

leds: pwm: Remove atomic code paths

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: Thierry Reding <thierry.reding@gmail.com>

leds: pwm: Use pwm_get_args() where appropriate

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 <boris.brezillon@free-electrons.com>
Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

leds: pwm: fix driver description and make license match the header

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>

leds: call led_pwm_set() in leds-pwm to enforce default LED_OFF

Some PWMs are disabled by default or the default pin setting
does not match the LED_OFF state (e.g., active-low leds).
Hence, the driver may end up reporting 0 brightness, but
the leds are actually on using full brightness, because
it never enforces its default configuration.
So enforce it by calling led_pwm_set() after successfully
registering the device.

Tested on a Phytec phyFLEX i.MX6Q board based on kernel
v3.19.5.

Signed-off-by: Markus Hofstaetter <markus.hofstaetter@ait.ac.at>
Tested-by: Markus Hofstaetter <markus.hofstaetter@ait.ac.at>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>

leds: pwm: remove work queue

Now the core implements the work queue, remove it from the drivers,
and switch to using brightness_set_blocking op.

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Raphael Assenat <raph@8d.com>

leds: leds-pwm: drop one pwm_get_period() call

pwm_get_period() is called twice in case the child parameter is set. I
assume retrieving this parameter once is enough therefore this patch
removes the conditial invocation of pwm_get_period().

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: drop owner assignment from platform_drivers

A platform_driver does not need to set an owner, it will be populated by the
driver core.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

leds: leds-pwm: retrieve configured PWM period

The PWM core is now able to initialize the PWM period from a lookup
table defined by board files. Use it if available and fallback to the
value supplied in pwm_period_ns.

Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

leds: leds-pwm: add DT support for LEDs wired to supply

The non-DT driver allowed an active low property to be specified, but DT
is missing this in its description. Add the property to the DT binding
document, making it optional. It defaults to active high, which retains
compatibility with existing descriptions.

This should only be used for causes where the LED is wired to supply,
and the PWM does not sensibly support its own inversion.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: leds-pwm: implement PWM inversion

Some PWM outputs are wired such that the LED they're controlling is
connected to supply rather than ground. These PWMs may not support
output inversion, or when they do, disabling the PWM may set the
PWM output low, causing a "brightness" value of zero to turn the LED
fully on.

The platform data for this driver already indicates that this was
thought about, and we have the "active_low" property there already.
However, the implementation for this is missing.

Add the trivial implementation for this feature.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: leds-pwm: convert OF parsing code to use led_pwm_add()

Convert the OF parsing code to use the common PWM LED registration code,
which means we have a consistent method, and single point where the
registration happens for both paths.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: leds-pwm: provide a common function to setup a single led-pwm device

Provide a common function to setup a single led-pwm device, replacing
the platform data initialisation path with this function. This allows
us to have a common method of creating these devices in a consistent
manner, which then allows us to place the probe failure cleanup in one
place.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: leds-pwm: properly clean up after probe failure

When probing with DT, we add each LED one at a time. If we find a LED
without a PWM device (because it is not available yet) we fail the
initialisation, unregister previous LEDs, and then by way of managed
resources, we free the structure.

The problem with this is we may have a scheduled and active work_struct
in this structure, and this results in a nasty kernel oops.

We need to cancel this work_struct properly upon cleanup - and the
cleanup we require is the same cleanup as we do when the LED platform
device is removed. Rather than writing this same code three times,
move it into a separate function and use it in all three places.

Fixes: c971ff185f64 ("leds: leds-pwm: Defer led_pwm_set() if PWM can sleep")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

drivers/leds: delete non-required instances of include <linux/init.h>

None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>. Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

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

leds: pwm: Remove a warning on non-DT platforms

This removes a warning on non-DT-enabled platforms:

drivers/leds/leds-pwm.c: In function 'led_pwm_create_of':
drivers/leds/leds-pwm.c:88:22: warning: unused variable 'node'

Really caused by the local variable that is assigned to and then never
used. Just do away with the local var, it's not needed.

Technically this code path can never be entered without DT enabled,
since there's an earlier check about number of children in the calling
function, but the compiler can't see that.

Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: leds-pwm: fix duty time overflow.

Overflow maybe occurs when calculates the duty time. For instance,
the period time is 990000000ns, and the max_brightness is 127, when
setting the brightness to 12, the duty value will be 25906026ns, but
it should be 93543307ns.

Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: pwm: Fix for deferred probe in DT booted mode

We need to make sure that the error code from devm_of_pwm_get() is the one
the module returns in case of failure.
Restructure the code to make this possible for DT booted case.
With this patch the driver can ask for deferred probing when the board is
booted with DT.
Fixes for example omap4-sdp board's keyboard backlight led.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: pwm: Remove redundant of_match_ptr

The data structure of_match_ptr() protects is always compiled in.
Hence of_match_ptr() is not needed.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: use dev_get_platdata()

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: leds-pwm: Defer led_pwm_set() if PWM can sleep

Call to led_pwm_set() can happen inside atomic context, like triggers.
If the PWM call can sleep, defer using a worker.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: leds-pwm: Add device tree bindings

The DT binding for the pwm-leds devices are similar to the gpio-leds type.
LEDs are represented as sub-nodes of the pwm-leds device.
The code for handling the DT boot is based on the code found in the
leds-gpio driver and adapted to use PWMs instead of GPIOs.
To avoid having custom cleanup code in case of DT boot the newly created
devm_of_pwm_get() API is used to get the correct PWM instance.

For usage see:
Documentation/devicetree/bindings/leds/leds-pwm.txt

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: leds-pwm: Simplify cleanup code

The code looks more nicer if we use:

while (i--)

instead:
if (i > 0)
for (i = i - 1; i >= 0; i--)

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: leds-pwm: Preparing the driver for device tree support

In order to be able to add device tree support for leds-pwm driver we need
to rearrange the data structures used by the drivers.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: leds-pwm: Convert to use devm_get_pwm

Update the driver to use the new API for requesting pwm so we can take
advantage of the pwm_lookup table to find the correct pwm to be used for the
LED functionality.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: remove use of __devexit

CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.

Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Jan-Simon Moeller <jansimon.moeller@gmx.de>
Acked-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

leds: remove use of __devexit_p

CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.

Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Jan-Simon Moeller <jansimon.moeller@gmx.de>
Acked-by: Bryan Wu <cooloney@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

leds: leds-pwm: Fix checkpatch warning

Fixes the following checkpatch warning:
WARNING: please, no space before tabs
FILE: leds/leds-pwm.c:29:
^Iunsigned int ^I^Iactive_low;$

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Bryan Wu <cooloney@gmail.com>

leds: Use devm_kzalloc in leds-pwm.c file

devm_kzalloc() makes cleanup simpler.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Bryan Wu <bryan.wu@canonical.com>

leds: convert led platform drivers to module_platform_driver

Factor out some boilerplate code for platform driver registration into
module_platform_driver.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Haojian Zhuang <hzhuang1@marvell.com> [led-88pm860x.c]
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Michael Hennerich <hennerich@blackfin.uclinux.org>
Cc: Mike Rapoport <mike@compulab.co.il>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

leds: leds-pwm: return proper error if pwm_request failed

Return PTR_ERR(led_dat->pwm) instead of 0 if pwm_request failed

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Luotao Fu <l.fu@pengutronix.de>
Cc: Reviewed-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

leds: leds-pwm: Set led_classdev max_brightness

Currently the driver leds-pwm doesn't set max_brightness for the led device
although it's platform data proides a maximum brightness. Instead it stores its
own private driver struct. The max_brightness defaults to 255 for led device if
it has not been set.
As a result any leds-pwm device with a different maximum brightness will show
incorrect behavior, as it is posible to either set a longer then period duty
time or not be able to switch the led to full brightness.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>

leds: simple driver for pwm driven LEDs

Add a simple driver for pwm driver LEDs. pwm_id and period can be defined
in board file. It is developed for pxa, however it is probably generic
enough to be used on other platforms with pwm.

Signed-off-by: Luotao Fu <l.fu@pengutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>