Add pointer to datasheet and fix typo in printk message.
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Trivial cleanup removing empty line at wrong place.
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Apparently it is quite easy to forget ">" in quoting of email
address. This fixes it.
Signed-off-by: NPavel Machek <pavel@ucw.cz>

We need the of_match table if we want to use the compatible string in
the pmic's child node and get the led driver loaded automatically.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

If a node is ignored, do not get a reference to it. Fix the bug by moving
fwnode_handle_get() where a reference to an fwnode is saved for clarity.
Reported-by: NAndy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

When switching to using generic LED name composition mechanism via
devm_led_classdev_register_ext() API the part of code initializing
struct gpio_led's template name property was removed alongside.
It was however overlooked that the property was also passed to
devm_fwnode_get_gpiod_from_child() in place of "label" parameter,
which when set to NULL, results in gpio label being initialized to '?'.

It could be observed in debugfs and failed to properly identify
gpio association with LED consumer.

Fix this shortcoming by updating the GPIO label after the LED is
registered and its final name is known.

Fixes: d7235f5f ("leds: gpio: Use generic support for composing LED names")
Cc: Russell King <linux@armlinux.org.uk>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
[fixed comment]
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Otherwise there's a noticeable glow even with brightness 0. Also
turning off the regulator can save additional power.
Signed-off-by: NGuido Günther <agx@sigxcpu.org>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Move the relevant parts out of lm3692x_remove() and call it from
there. No functional change.
Signed-off-by: NGuido Günther <agx@sigxcpu.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

This moves lm3692x_init so it can be used from
lm3692x_brightness_set. Rename to lm3692_leds_enable to pair up
with lm3692x_leds_disable. No functional change.
Signed-off-by: NGuido Günther <agx@sigxcpu.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

The current is given by the formular from page 12 of
https://www.ti.com/lit/ds/symlink/lm36922.pdf. We use this to limit the
led's max_brightness using the led-max-microamp DT property.

The formula for the lm36923 is identical according to the data sheet.
Signed-off-by: NGuido Günther <agx@sigxcpu.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Overvoltage protection is currently using the default of 29V.  Make it
configurable via DT.
Signed-off-by: NGuido Günther <agx@sigxcpu.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

If initialization data is available and its fwnode is actually a
of_node, store this information in the led device's structure. This
will allow the device to use or provide OF-based API such (devm_xxx).
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

If the LED is acquired by a consumer device with devm_led_get(), it is
automatically released when the device is detached.
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

This patch adds basic support for a kernel driver to get a LED device.
This will be used by the led-backlight driver.

Only OF version is implemented for now, and the behavior is similar to
PWM's of_pwm_get() and pwm_put().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Add pointer to datasheet and fix typo in printk message.
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Signed-off-by: NPavel Machek <pavel@ucw.cz>

Bad string from userspace is not worth printing warning on; gotos that
just directly return are not good, plus a comment fix.

Cc: jacek.anaszewski@gmail.com, linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org, dmurphy@ti.com
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Trivial cleanup removing empty line at wrong place.
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Apparently it is quite easy to forget ">" in quoting of email
address. This fixes it.
Signed-off-by: NPavel Machek <pavel@ucw.cz>

This driver adds support for the LED operational mode of the
tps6105x MFD device.
Acked-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: NSven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

We need the of_match table if we want to use the compatible string in
the pmic's child node and get the led driver loaded automatically.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

The Rohm BD2802 have no in-kernel users so we can drop the
GPIO number from the platform data and require users to
provide the GPIO line using machine descriptors.

As the descriptors come with inherent polarity inversion
semantics, we invert the calls to set the GPIO line such
that 0 means "unasserted" and 1 means "asserted".

Put a note in the driver that machine descriptor tables
will need to specify that the line is active low.

Cc: Kim Kyuwon <chammoru@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Before commit bb29b9cc ("leds: pca963x: Add bindings to invert
polarity") Mode register 2 was initialized directly with either 0x01
or 0x05 for open-drain or totem pole (push-pull) configuration.

Afterwards, MODE2 initialization started using bitwise operations on
top of the default MODE2 register value (0x05). Using bitwise OR for
setting OUTDRV with 0x01 and 0x05 does not produce correct results.
When open-drain is used, instead of setting OUTDRV to 0, the driver
keeps it as 1:

Open-drain: 0x05 | 0x01 -> 0x05 (0b101 - incorrect)
Totem pole: 0x05 | 0x05 -> 0x05 (0b101 - correct but still wrong)

Now OUTDRV setting uses correct bitwise operations for initialization:

Open-drain: 0x05 & ~0x04 -> 0x01 (0b001 - correct)
Totem pole: 0x05 | 0x04 -> 0x05 (0b101 - correct)

Additional MODE2 register definitions are introduced now as well.

Fixes: bb29b9cc ("leds: pca963x: Add bindings to invert polarity")
Signed-off-by: NZahari Petkov <zahari@balena.io>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

If a node is ignored, do not get a reference to it. Fix the bug by moving
fwnode_handle_get() where a reference to an fwnode is saved for clarity.
Reported-by: NAndy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

When switching to using generic LED name composition mechanism via
devm_led_classdev_register_ext() API the part of code initializing
struct gpio_led's template name property was removed alongside.
It was however overlooked that the property was also passed to
devm_fwnode_get_gpiod_from_child() in place of "label" parameter,
which when set to NULL, results in gpio label being initialized to '?'.

It could be observed in debugfs and failed to properly identify
gpio association with LED consumer.

Fix this shortcoming by updating the GPIO label after the LED is
registered and its final name is known.

Fixes: d7235f5f ("leds: gpio: Use generic support for composing LED names")
Cc: Russell King <linux@armlinux.org.uk>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
[fixed comment]
Signed-off-by: NPavel Machek <pavel@ucw.cz>

We can now safely read user kcpustat fields on nohz_full CPUs.
Use the appropriate accessor.

[ mingo: Fixed build failure. ]
Reported-by: NYauheni Kaliuta <yauheni.kaliuta@redhat.com>
Signed-off-by: NFrederic Weisbecker <frederic@kernel.org>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com> (maintainer:LED SUBSYSTEM)
Cc: Pavel Machek <pavel@ucw.cz> (maintainer:LED SUBSYSTEM)
Cc: Dan Murphy <dmurphy@ti.com> (reviewer:LED SUBSYSTEM)
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wanpeng Li <wanpengli@tencent.com>
Link: https://lkml.kernel.org/r/20191121024430.19938-6-frederic@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>

The NETDEV_CHANGENAME code is not "unneeded" like it is stated in commit
4cb65605 ("leds: trigger: netdev: fix refcnt leak on interface
rename").

The event was accidentally misinterpreted equivalent to
NETDEV_UNREGISTER, but should be equivalent to NETDEV_REGISTER.

This was the case in the original code from the openwrt project.

Otherwise, you are unable to set netdev led triggers for (non-existent)
netdevices, which has to be renamed. This is the case, for example, for
ppp interfaces in openwrt.

Fixes: 06f502f5 ("leds: trigger: Introduce a NETDEV trigger")
Fixes: 4cb65605 ("leds: trigger: netdev: fix refcnt leak on interface rename")
Signed-off-by: NMartin Schiller <ms@dev.tdt.de>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

an30259a_probe misses a check for devm_regmap_init_i2c and may cause
problems.
Add a check and print errors like other leds drivers.
Signed-off-by: NChuhong Yuan <hslester96@gmail.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Error was detected by PVS-Studio:
V512 A call of the 'sprintf' function will lead to overflow of
the buffer 'led_data->led_cdev_name'.
Acked-by: NJacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NOleh Kravchenko <oleg@kaa.org.ua>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

This driver can use the of_device_get_match_data() API to simplify the
code. Replace calls to of_match_device() with this newer API under the
assumption that where it is called will be when we know the device is
backed by a DT node. This nicely avoids referencing the match table when
it is undefined with configurations where CONFIG_OF=n.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Riku Voipio <riku.voipio@iki.fi>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: <linux-leds@vger.kernel.org>
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Fix the devm_classdev_match pointer initialization to the correct
structure type.
Signed-off-by: NDan Murphy <dmurphy@ti.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Convert LED flash class registration to device managed class
registration API.
Signed-off-by: NDan Murphy <dmurphy@ti.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Add the missing device managed API for registration and
unregistration for the LED flash class.
Signed-off-by: NDan Murphy <dmurphy@ti.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Update the Kconfig to be consistent in the case of using
"LED" in the Kconfig.  LED is an acronym and should be
capitalized.
Signed-off-by: NDan Murphy <dmurphy@ti.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Reading /sys/class/leds/<led>/trigger returns all available LED triggers.
However, the size of this file is limited to PAGE_SIZE because of the
limitation for sysfs attribute.

Enabling LED CPU trigger on systems with thousands of CPUs easily hits
PAGE_SIZE limit, and makes it impossible to see all available LED triggers
and which trigger is currently activated.

We work around it here by converting /sys/class/leds/<led>/trigger to
binary attribute, which is not limited by length. This is _not_ good
design, do not copy it.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>A
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

The TLC chips actually offer 257 levels:
- 0: led OFF
- 1-255: Led dimmed is using a PWM. The duty cycle range from 0.4% to 99.6%
- 256: led fully ON

Fixes: e370d010 ("leds: tlc591xx: Driver for the TI 8/16 Channel i2c LED driver")
Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Use LM3692X_RAMP_EN instead of LM3692X_PWM_HYSTER_4LSB
since the later is a flag for the PWM register. The
actual register value remains unchanged.
Signed-off-by: NGuido Günther <agx@sigxcpu.org>
Reviewed-by: NDan Murphy <dmurphy@ti.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

The current setup of LM3692X_BOOST_CTRL uses flags from LM3692X_BRT_CTRL.
Use flags from LM3692X_BOOST_CTRL but leave the resulting register value
unchanged.
Signed-off-by: NGuido Günther <agx@sigxcpu.org>
Reviewed-by: NDan Murphy <dmurphy@ti.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

Instead use devm_regulator_get_optional since the regulator
is optional and check for errors.
Signed-off-by: NGuido Günther <agx@sigxcpu.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Reviewed-by: NDan Murphy <dmurphy@ti.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>

The driver currently reports successful initialization on every failure
as long as it's able to power off the regulator. Don't check the return
value of regulator_disable to avoid that.
Signed-off-by: NGuido Günther <agx@sigxcpu.org>
Acked-by: NPavel Machek <pavel@ucw.cz>
Reviewed-by: NDan Murphy <dmurphy@ti.com>
Signed-off-by: NPavel Machek <pavel@ucw.cz>