With these kernel configs:
CONFIG_LEDS_CLASS=m
# CONFIG_LEDS_CLASS_MULTICOLOR is not set
CONFIG_LEDS_LP55XX_COMMON=y
CONFIG_LEDS_LP5521=m
CONFIG_LEDS_LP5562=m
leds-lp55xx-common.c has a build error because it is builtin and
calls an interface that is built as a loadable module (due to
LEDS_CLASS=m). By making LEDS_LP55XX_COMMON depend on LEDS_CLASS,
this config combination cannot happen, thus preventing the build error.
ld: drivers/leds/leds-lp55xx-common.o: in function `lp55xx_register_leds':
leds-lp55xx-common.c:(.text+0xc5f): undefined reference to `devm_led_classdev_register_ext'
Fixes: 33b3a561f4 ("leds: support new LP8501 device - another LP55xx common")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Milo Kim <milo.kim@ti.com>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Pavel Machek <pavel@ucw.cz>
IBM created an implementation of the PCA9552 on a PIC16F
microcontroller. The I2C device addresses are different from the
hardware PCA9552, so add a new compatible string and associated
platform data to be able to probe this device.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Vishwanatha Subbanna <vishwa@linux.vnet.ibm.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
clang static analysis reports this problem
leds-mt6323.c:275:12: warning: Division by zero
duty_hw = MT6323_CAL_HW_DUTY(*delay_on, period);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is because period can be 0.
period = *delay_on + *delay_off;
There is a later check that *delay_on/off are valid.
if (!*delay_on && !*delay_off) {
*delay_on = 500;
*delay_off = 500;
}
Setting the delay_on/off means period needs to be recalculated
anyway. So move the period statements after this check.
Fixes: 216ec6cc4c ("leds: Add LED support for MT6323 PMIC")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The driver includes machine header for GPIO registers but actually does
not use them.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Okay, so... this one is interesting. RGB LEDs are very common, and we
need to have some kind of support for them. Multicolor is for
arbitrary set of LEDs in one package, RGB is for LEDs that can produce
full range of colors. We do not have real multicolor LED that is not
RGB in the pipeline, so that one is disabled for now.
You can expect this saga to continue with next pull requests.
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCXyskqQAKCRAw5/Bqldv6
8ge0AJ9JRTa/0Xkl7JuKUpC93jAnvjpK+ACgsDijb77H5zmtwC8xa0kXiDsbh3E=
=aSJX
-----END PGP SIGNATURE-----
Merge tag 'leds-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds
Pull LED updates from Pavel Machek:
"Okay, so... this one is interesting. RGB LEDs are very common, and we
need to have some kind of support for them. Multicolor is for
arbitrary set of LEDs in one package, RGB is for LEDs that can produce
full range of colors. We do not have real multicolor LED that is not
RGB in the pipeline, so that one is disabled for now.
You can expect this saga to continue with next pull requests"
* tag 'leds-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: (37 commits)
MAINTAINERS: Remove myself as LED subsystem maintainer
leds: disallow /sys/class/leds/*:multi:* for now
leds: add RGB color option, as that is different from multicolor.
Make LEDS_LP55XX_COMMON depend on I2C to fix build errors:
Documentation: ABI: leds-turris-omnia: document sysfs attribute
leds: initial support for Turris Omnia LEDs
dt-bindings: leds: add cznic,turris-omnia-leds binding
leds: pattern trigger -- check pattern for validity
leds: Replace HTTP links with HTTPS ones
leds: trigger: add support for LED-private device triggers
leds: lp5521: Add multicolor framework multicolor brightness support
leds: lp5523: Update the lp5523 code to add multicolor brightness function
leds: lp55xx: Add multicolor framework support to lp55xx
leds: lp55xx: Convert LED class registration to devm_*
dt-bindings: leds: Convert leds-lp55xx to yaml
leds: multicolor: Introduce a multicolor class definition
leds: Add multicolor ID to the color ID list
dt: bindings: Add multicolor class dt bindings documention
leds: lp5523: Fix various formatting issues in the code
leds: lp55xx: Fix file permissions to use DEVICE_ATTR macros
...
All the LEDs in the queue are RGB, so they should not use multi for
their color.
Make sure we don't add such LED by mistake (and make it part of ABI).
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Multicolor is a bit too abstract. Yes, we can have
Green-Magenta-Ultraviolet LED, but so far all the LEDs we support are
RGB, and not even RGB-White or RGB-Yellow variants emerged.
Multicolor is not a good fit for RGB LED. It does not really know
about LED color. In particular, there's no way to make LED "white".
Userspace is interested in knowing "this LED can produce arbitrary
color", which not all multicolor LEDs can.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
leds-lp55xx-common.c:(.text+0x9d): undefined reference to `i2c_smbus_read_byte_data'
leds-lp55xx-common.c:(.text+0x8fc): undefined reference to `i2c_smbus_write_byte_data'
These errors happened when I2C=m and LEDS_LP55XX_COMMON=y, so
prevent that from being possible.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
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
Cc: Milo Kim <milo.kim@ti.com>
Cc: Mathias Nyman <mathias.nyman@nokia.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This adds basic support for LEDs on the front side of CZ.NIC's Turris
Omnia router.
There are 12 RGB LEDs. The controller supports HW triggering mode for
the LEDs, but this driver does not support it yet, and sets all the LEDs
defined in device-tree into SW mode upon probe.
This driver uses the multicolor LED framework.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Some LED controllers may come with an internal HW triggering mechanism
for the LED and the ability to switch between SW control and the
internal HW control. This includes most PHYs, various ethernet switches,
the Turris Omnia LED controller or AXP20X PMIC.
This adds support for registering such triggers.
This code is based on work by Pavel Machek <pavel@ucw.cz> and
Ondřej Jirman <megous@megous.com>.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Add the multicolor brightness call back to support the multicolor
framework. This function allows setting the brightness across
grouped LED channels in a single call.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Add the multicolor brightness call back to support the multicolor
framework. This call back allows setting brightness on grouped channels
in a single function.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Add multicolor framework support for the lp55xx family.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Convert the LED class registration calls to the LED devm_*
registration calls.
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Introduce a multicolor class that groups colored LEDs
within a LED node.
The multicolor class groups monochrome LEDs and allows controlling two
aspects of the final combined color: hue and lightness. The former is
controlled via the intensity file and the latter is controlled
via brightness file.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
[squashed leds: multicolor: Fix camel case in documentation in]
Add a new color ID that is declared as MULTICOLOR as with the
multicolor framework declaring a definitive color is not accurate
as the node can contain multiple colors.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Fix checkpatch errors and warnings for the LP5523.c device
driver.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Fix the checkpatch warnings for the use of the file permission macros.
In converting the file permissions to the DEVICE_ATTR_XX macros the
call back function names needed to be updated within the code.
This means that the lp55xx_ needed to be dropped in the name to keep in
harmony with the ABI documentation.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes. Also, remove unnecessary
function sizeof_gpio_leds_priv().
This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes. Also, remove unnecessary
function sizeof_ns2_led_priv().
This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The leds-gpio driver mixes up the legacy GPIO flags with the
GPIO descriptor flags and passes a legacy flag to
devm_gpiod_get_index().
Fix this by replacing the flags variable with the strict
descriptor flag.
Fixes: 45d4c6de4e ("leds: gpio: Try to lookup gpiod from device")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon
system suspend.
led_set_brightness_nopm() uses schedule_work() to set LED brightness.
However, there's no guarantee that the scheduled work gets executed
because no one flushes the work.
So flush the scheduled work to make sure LED gets turned off.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fixes: 81fe8e5b73 ("leds: core: Add led_set_brightness_nosleep{nopm} functions")
Signed-off-by: Pavel Machek <pavel@ucw.cz>
If the GPIO has not been configured yet, writing to inverted will raise
a kernel warning.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This driver provides a GPIO chip, so include <linux/gpio/driver.h>
and not the legacy <linux/gpio.h> header.
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: Joel Stanley <joel@jms.id.au>
Cc: Matt Spinler <mspinler@linux.vnet.ibm.com>
Cc: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The LP55xx driver is already using the of_gpio() functions to
pick a global GPIO number for "enable" from the device tree and
request the line. Simplify it by just using a GPIO descriptor.
Make sure to keep the enable GPIO line optional, change the
naming from "lp5523_enable" to "LP55xx enable" to reflect that
this is used on all LP55xx LED drivers.
Cc: Milo Kim <milo.kim@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This converts the s3c24xx LED driver to use GPIO descriptors
and also modify all board files to account for these changes
by registering the appropriate GPIO tables for each board.
The driver was using a custom flag to indicate open drain
(tristate) but this can be handled by standard descriptor
machine tables.
The driver was setting non-pull-up for the pin using the custom
S3C24xx GPIO API, but this is a custom pin control system used
by the S3C24xx and no generic GPIO function, so this has simply
been pushed back into the respective board files.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Right now the driver uses only 3 LED modes:
0: On
1: HW Blinking (Interval 1)
3: Off
However, the controller supports a second HW blinking interval, which results
in 4 possible LED modes:
0: On
1: HW Blinking (Interval 1)
2: HW Blinking (Interval 2)
3: Off
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Drop the pointless and needlessly confusing casts of struct-device
pointers.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: 8d3b6a4001 ("leds: wm831x-status: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot use devres so that
deregistration ends up being tied to the parent device, something which
leads to use-after-free on driver unbind when the class device is
released while still being registered.
Fixes: 11e1bbc116 ("leds: lm36274: Introduce the TI LM36274 LED driver")
Cc: stable <stable@vger.kernel.org> # 5.3
Cc: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: 50154e29e5 ("leds: lm3533: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: eed16255d6 ("leds: da903x: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes: 375446df95 ("leds: 88pm860x: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
clang points out that doing arithmetic between diffent enums is usually
a mistake:
drivers/leds/leds-lm355x.c:167:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion]
reg_val = pdata->pin_tx2 | pdata->ntc_pin;
~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
drivers/leds/leds-lm355x.c:178:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion]
reg_val = pdata->pin_tx2 | pdata->ntc_pin | pdata->pass_mode;
~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
In this driver, it is intentional, so add a cast to hide the false-positive
warning. It appears to be the only instance of this warning at the moment.
Fixes: b98d13c725 ("leds: Add new LED driver for lm355x chips")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
New drivers: aw2013, sgm3140, some fixes. Nothing much to see here,
next release should be more interesting.
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCXtjlggAKCRAw5/Bqldv6
8mi4AJ9sFTwt9zcnIB3dZcD+C9J/GtCU7ACgwlN9UsQ1qvpEG1xE0mSgLlPvebQ=
=HymN
-----END PGP SIGNATURE-----
Merge tag 'leds-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds
Pull LED updates from Pavel Machek:
"New drivers: aw2013, sgm3140, some fixes
Nothing much to see here, next release should be more interesting"
* tag 'leds-5.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds:
leds: add aw2013 driver
dt-bindings: leds: Add binding for aw2013
leds: trigger: remove redundant assignment to variable ret
leds: netxbig: Convert to use GPIO descriptors
leds: add sgm3140 driver
dt-bindings: leds: Add binding for sgm3140
leds: ariel: Add driver for status LEDs on Dell Wyse 3020
leds: pwm: check result of led_pwm_set() in led_pwm_add()
leds: tlc591xxt: hide error on EPROBE_DEFER
leds: tca6507: Include the right header
leds: lt3593: Drop surplus include
leds: lp3952: Include the right header
leds: lm355x: Drop surplus include
This commit adds support for AWINIC AW2013 3-channel LED driver.
The chip supports 3 PWM channels and is controlled with I2C.
Signed-off-by: Nikita Travkin <nikitos.tr@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The variable ret is being assigned with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This converts the NetXbig LED driver to use GPIO descriptors
instead of using the legacy interfaces in <linux/of_gpio.h>
and <linux/gpio.h> to iteratively parse the device tree for
global GPIO numbers.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Add a driver for the SGMICRO SGM3140 Buck/Boost Charge Pump LED driver.
This device is controlled by two GPIO pins, one for enabling and the
second one for switching between torch and flash mode.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This adds support for controlling the LEDs attached to the Embedded
Controller on a Dell Wyse 3020 "Ariel" board.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
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>
If devm_led_classdev_register_ext() fails with EPROBE_DEFER, we get:
tlc591xx 0-0040: couldn't register LED (null)
Only print the error if the error is something else than EPROBE_DEFER.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The TCA6507 optionally presents a GPIO controller, so include
<linux/gpio/driver.h> instead of the legacy <linux/gpio.h>.
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This driver is already including and using the proper
<linux/gpio/consumer.h> header, there is no need to include
the legacy <linux/gpio.h> header.
Cc: Daniel Mack <daniel@zonque.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This driver is using the GPIO descriptor API properly
as it should be but is including the legacy GPIO header
<linux/gpio.h>. Fix it by including <linux/gpio/consumer.h>
instead.
Cc: Tony Makkiel <tony.makkiel@daqri.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This driver includes <linux/gpio.h> but does not use
any symbols from that file, so drop the include.
Cc: G.Shark Jeong <gshark.jeong@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The warning message when a led is renamed due to name collition can fail
to show proper original name if init_data is used. Eg:
[ 9.073996] leds-gpio a0040000.leds_0: Led (null) renamed to red_led_1 due to name collision
Fixes: bb4e9af034 ("leds: core: Add support for composing LED class device names")
Signed-off-by: Ricardo Ribalda Delgado <ribalda@kernel.org>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The bitfield 'enabled' should bit unsigned, so make it unsigned.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
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 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
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 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
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>
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>
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>
.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>
This patch implemenets a driver to support the front panel LEDs of
SGI Octane (IP30) workstations.
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/leds/leds-bd2802.c: In function 'bd2802_probe':
drivers/leds/leds-bd2802.c:663:35: warning:
variable 'pdata' set but not used [-Wunused-but-set-variable]
commit 4c3718f9d6 ("leds: bd2802: Convert to use GPIO descriptors")
left behind this unused variable.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This converts the NS2 LED driver to use GPIO descriptors.
We take care to request the GPIOs "as is" which is what
the current driver goes to lengths to achieve, then we use
GPIOs throughout.
As the nodes for each LED does not have any corresponding
device, we need to use the DT-specific accessors to get these
GPIO descriptors from the device tree.
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Nothing in the kernel includes the external header
<linux/platform_data/leds-kirkwood-ns2.h> so just push the
contents into the ns2 leds driver. If someone wants to use
platform data or board files to describe this device they
should be able to do so using GPIO machine descriptors but
in any case device tree should be the way forward for these
systems in all cases I can think of, and the driver already
supports that.
Cc: Simon Guinot <simon.guinot@sequanux.org>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Pavel 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: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Move the relevant parts out of lm3692x_remove() and call it from
there. No functional change.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel 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: Guido Günther <agx@sigxcpu.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel 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: Guido Günther <agx@sigxcpu.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Overvoltage protection is currently using the default of 29V. Make it
configurable via DT.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel 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: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Pavel 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: Jean-Jacques Hiblot <jjhiblot@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel 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: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This driver adds support for the LED operational mode of the
tps6105x MFD device.
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Pavel 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: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Pavel 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: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Before commit bb29b9cccd ("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: bb29b9cccd ("leds: pca963x: Add bindings to invert polarity")
Signed-off-by: Zahari Petkov <zahari@balena.io>
Signed-off-by: Pavel 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: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Pavel 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: d7235f5fea ("leds: gpio: Use generic support for composing LED names")
Cc: Russell King <linux@armlinux.org.uk>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
[fixed comment]
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Pull LED updates from Pavel Machek:
"This contains usual small updates to drivers, and removal of PAGE_SIZE
limits on /sys/class/leds/<led>/trigger.
We should not be really having that many triggers; but with cpu
activity triggers we do, and we'll eventually need to fix it, but...
remove the limit for now"
* tag 'leds-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: (26 commits)
leds: trigger: netdev: fix handling on interface rename
leds: an30259a: add a check for devm_regmap_init_i2c
leds: mlxreg: Fix possible buffer overflow
leds: pca953x: Use of_device_get_match_data()
leds: core: Fix leds.h structure documentation
leds: core: Fix devm_classdev_match to reference correct structure
leds: core: Remove extern from header
leds: lm3601x: Convert class registration to device managed
leds: flash: Add devm_* functions to the flash class
leds: flash: Remove extern from the header file
leds: flash: Convert non extended registration to inline
leds: Kconfig: Be consistent with the usage of "LED"
leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/trigger
leds: tlc591xx: update the maximum brightness
leds: lm3692x: Use flags from LM3692X_BRT_CTRL
leds: lm3692x: Use flags from LM3692X_BOOST_CTRL
leds: lm3692x: Handle failure to probe the regulator
leds: lm3692x: Don't overwrite return value in error path
leds: lm3692x: Print error value on dev_err
leds: tlc591xx: use devm_led_classdev_register_ext()
...
The NETDEV_CHANGENAME code is not "unneeded" like it is stated in commit
4cb6560514 ("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: 06f502f57d ("leds: trigger: Introduce a NETDEV trigger")
Fixes: 4cb6560514 ("leds: trigger: netdev: fix refcnt leak on interface rename")
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Pavel 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: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Pavel 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: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
Signed-off-by: Pavel 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: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Fix the devm_classdev_match pointer initialization to the correct
structure type.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Convert LED flash class registration to device managed class
registration API.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Add the missing device managed API for registration and
unregistration for the LED flash class.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel 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: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel 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: Akinobu 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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Pavel 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: e370d010a5 ("leds: tlc591xx: Driver for the TI 8/16 Channel i2c LED driver")
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Pavel 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: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel 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: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Instead use devm_regulator_get_optional since the regulator
is optional and check for errors.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel 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: Guido Günther <agx@sigxcpu.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This gives a way better idea what is going on.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Use devm_led_classdev_register_ext() to pass the fwnode to the LED core.
The fwnode can then be used by the firmware core to create meaningful
names.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Use the managed API of the LED class (devm_led_classdev_register()
instead of led_classdev_register()).
This allows us to remove the code used to track-and-destroy the LED devices.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The driver currently ignores errors from register writes at probe time.
It will hence register an LED class device no matter whether the
pyhsical device is present or not.
To fix this, make the device probe fail in case regmap operations
return an error.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
This patch adds a LED class driver for the LEDs found on
the Crane Merchandising System EL15203000 LEDs board
(aka RED LEDs board).
Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Now that we have a vtime safe kcpustat accessor for CPUTIME_SYSTEM, use
it to start fixing frozen kcpustat values on nohz_full CPUs.
Reported-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J . Wysocki <rjw@rjwysocki.net>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Wanpeng Li <wanpengli@tencent.com>
Link: https://lkml.kernel.org/r/20191016025700.31277-15-frederic@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Fix the error handling for the led-max-microamp property.
Need to check if the property is present and then if it is
retrieve the setting and its max boundary
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Error was detected by PVS-Studio:
V522 Dereferencing of the null pointer 'led_cdev->trigger' might take place.
Fixes: 2282e125a4 ("leds: triggers: let struct led_trigger::activate() return an error code")
Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Move the static keyword to the front of declaration of ramp_table,
and resolve the following compiler warning that can be seen when
building with warnings enabled (W=1):
drivers/leds/leds-ti-lmu-common.c:14:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Move the static keyword to the front of declarations ramp_table,
als_avrg_table and als_imp_table, and resolve the following
compiler warnings that can be seen when building with warnings
enabled (W=1):
drivers/leds/leds-lm3532.c:209:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
drivers/leds/leds-lm3532.c:266:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
drivers/leds/leds-lm3532.c:281:1: warning:
‘static’ is not at beginning of declaration [-Wold-style-declaration]
Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Allow all valid GPIOs to be used in the driver.
Fixes: 17354bfe85 ("leds: Add gpio-led trigger")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
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>
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 is31fl32xx_priv {
...
struct is31fl32xx_led_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_is31fl32xx_priv(int num_leds)
{
return sizeof(struct is31fl32xx_priv) +
(sizeof(struct is31fl32xx_led_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>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fix the coccinelle issues found in the TI LMU common code
drivers/leds/leds-ti-lmu-common.c:97:20-29: WARNING: Unsigned expression compared with zero: ramp_down < 0
drivers/leds/leds-ti-lmu-common.c:97:5-12: WARNING: Unsigned expression compared with zero: ramp_up < 0
Fixes: 3fce8e1eb9 ("leds: TI LMU: Add common code for TI LMU devices")
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
We may currently get unpaired regulator calls when configuring the LED
brightness via sysfs in case of regulator calls producing errors. Let's
fix this by maintaining local state for enabled.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
We have a MFD driver compiled as module instantiating this driver. When
unloading that module, those LED devices are not removed, which produces
conflicts, when that module is inserted again.
Signed-off-by: Alexander Dahl <ada@thorsis.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
If in the certain driver the LED is optional, and it's a majority of them,
the call of led_classdev_unregister() still requires some additional
checks.
The usual pattern on unregistering is to check for NULL, but we also check
for IS_ERR() in case device_create_with_groups() fails.
The change will reduce a burden in a lot of drivers to repeatedly check
for above conditions.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Allow the full scale current to be configured at init.
Valid rangles are 5mA->29.8mA.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fixed misspelled words, added error check during probe
on the init of the registers, and fixed ALS/I2C control
mode.
Fixes: bc1b8492c7 ("leds: lm3532: Introduce the lm3532 LED driver")
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Change the define name of the full scale current registers.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fix the brightness control for I2C mode. Instead of
changing the full scale current register update the ALS target
register for the appropriate banks.
In addition clean up some code errors and random misspellings found
during coding.
Tested on Droid4 as well as LM3532 EVM connected to a BeagleBoneBlack
Fixes: bc1b8492c7 ("leds: lm3532: Introduce the lm3532 LED driver")
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
There is no need to be stuck with OF node when we may use agnostic
firmware node instead.
It allows users to get property if needed independently of provider.
Note, some OF parts are left because %pfw [1] is in progress.
[1]: https://lore.kernel.org/patchwork/cover/1054863/
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Switch the max77650 from OF to the fwnode property API.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
In led_trigger_set(), 'event' is allocated in kasprintf(). However, it is
not deallocated in the following execution if the label 'err_activate' or
'err_add_groups' is entered, leading to memory leaks. To fix this issue,
free 'event' before returning the error.
Fixes: 52c47742f7 ("leds: triggers: send uevent when changing triggers")
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
This LED chip provides a GPIO driver, so include
<linux/gpio/driver.h> rather than the legacy header
<linux/gpio.h>.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Persistent tag for others to pull this branch from
Based on patch series from Suzuki K Poulose <suzuki.poulose@arm.com>
with Subject: [PATCH v3 0/7] drivers: Add generic device lookup helpers
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl1AL7obHGdyZWdraEBs
aW51eGZvdW5kYXRpb24ub3JnAAoJEDjbvchgkmk+X9cP/jXGxNeD4Hv2KfpQb32E
Zl7bnblRwKaheD1s91WzfV8HFgLcylmu2chW/IGpgX7ujHRr5zIu/H8FApK+Z5F+
8LiF8HnW2GICcSf95VMLNBXFY3wZq7NzOVnLIPvVcLJdOPPEjfYafQwSxB4WYxW5
UK4JVsLg8SpAOdqA5bGhlOHWaTssLRsktA0VEh4w0uUOxPeel7gh16GRK8GLlKTq
8lHiIKaN7PL9eDFTjh1wYP6FFgEAQhKexYVDtVj3fcEf8M0ArJTPIuPgaCKUqmD/
J233RyFAuMtR8N1jY4ScPlnUyHJzNmM1wF77PRupwIAO0opRjTJ2BNI7GwC1hB2J
xiPWtHrD21MBh2g44v+b/OwFNJ5AvuIlWEdEnrpNyj2KzrZP9H8G8Fy6CjFdVsEU
HzccNdkfZ0Y2juJjE/HvpPe3t3NjncUgeuFALzgjYrmm/1KVGL16HH2YFvtGZI5P
wrJVjyjdkRVU2u5I5+lIHRfULSmQIEPvp2BfkHnsmDmLNQbL8eTYCuowpSdbWWYB
yFxoavHuga7uDW3MPMr6c62csaUXMyeb1y9gCKnUqhg9lxkbGujFsUBVviFKJTvH
bWt79T2hqShe22JvwoIMSnH0DGpmFxFfdXk5/D7dGJJ5KUFoQ7bI0Q4wB9wW5+C4
uNqNTLD+o6uyIXD3wwRy/kkN
=XFYe
-----END PGP SIGNATURE-----
Merge tag 'generic_lookup_helpers' into for-next
Generic Device Lookup Helpers
Persistent tag for others to pull this branch from
Based on patch series from Suzuki K Poulose <suzuki.poulose@arm.com>
with Subject: [PATCH v3 0/7] drivers: Add generic device lookup helpers
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tag 'generic_lookup_helpers':
platform: Add platform_find_device_by_driver() helper
drivers: Add generic helper to match any device
drivers: Introduce device lookup variants by ACPI_COMPANION device
drivers: Introduce device lookup variants by device type
drivers: Introduce device lookup variants by fwnode
drivers: Introduce device lookup variants by of_node
drivers: Introduce device lookup variants by name
Add a helper to match the device name for device lookup. Also
reuse this generic exported helper for the existing bus_find_device_by_name().
and add similar variants for driver/class.
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexander Aring <alex.aring@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: Harald Freudenberger <freude@linux.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: linux-leds@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-wpan@vger.kernel.org
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Stefan Schmidt <stefan@datenfreihafen.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20190723221838.12024-2-suzuki.poulose@arm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The variable gpio_ext_np in the function netxbig_leds_get_of_pdata takes
the value returned by of_parse_phandle; hence, it must be put in order
to prevent a memory leak. Add an of_node_put for gpio_ext_np before a
return statement, and move a pre-existing of_node_put statement to right
after the last usage of this variable.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Since commit ebc278f157 ("ARM: mvebu: remove static LED setup for
netxbig boards"), no one in upstream passes in the platform data to
this driver.
Squash leds-kirkwood-netxbig.h into the driver, and remove the legacy
board-file support.
Link: https://lkml.org/lkml/2019/7/20/83
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Use fwnode_property_count_uXX() directly, that makes code neater.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Use fwnode_property_count_uXX() directly, that makes code neater.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Use fwnode_property_count_uXX() directly, that makes code neater.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Simon Shields <simon@lineageos.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Switch to using generic LED support for composing LED class
device name.
After switching to new led_classdev_register_ext() the validity
of struct led_classdev's name property is no longer guaranteed,
and therefore rely on struct device's kobj.name instead.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Switch to using generic LED support for composing LED class
device name.
After switching to new led_classdev_register_ext() the validity
of struct led_classdev's name property is no longer guaranteed,
and therefore rely on struct device's kobj.name instead.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Switch to using generic LED support for composing LED class
device name.
At this occassion remove initialization of struct led_classdev's
dev->of_node property in the driver, since now it will be taken from
fwnode assigned to struct led_init_data and passed to the new
devm_led_classdev_register_ext() API.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Oleh Kravchenko <oleg@kaa.org.ua>
Acked-by: Pavel Machek <pavel@ucw.cz>
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Tested-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Switch to using generic LED support for composing LED class
device name.
At this occassion remove initialization of struct led_classdev's
dev->of_node property in the driver, since now it will be taken from
fwnode assigned to struct led_init_data and passed to the new
devm_led_classdev_register_ext() API.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Tested-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Switch to using generic LED support for composing LED class
device name.
While at it, avoid iterating through available child of nodes
in favor of obtaining single expected child node using single
call to of_get_next_available_child().
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Dan Murphy <dmurphy@ti.com>
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Daniel Mack <daniel@zonque.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Switch to using generic LED support for composing LED class
device name.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Reviewed-by: Baolin Wang <baolin.wang@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Add generic support for composing LED class device name. The newly
introduced led_compose_name() function composes device name according
to either <color:function> or <devicename:color:function> pattern,
depending on the configuration of initialization data.
Backward compatibility with in-driver hard-coded LED class device
names is assured thanks to the default_label and devicename properties
of newly introduced struct led_init_data.
In case none of the aforementioned properties was found, then, for OF
nodes, the node name is adopted for LED class device name.
At the occassion of amending the Documentation/leds/leds-class.txt
unify spelling: colour -> color.
Alongside these changes added is a new tool - tools/leds/get_led_device_info.sh.
The tool allows retrieving details of a LED class device's parent device,
which proves that using vendor or product name for devicename part
of LED name doesn't convey any added value since that information had been
already available in sysfs. The script performs also basic validation
of a LED class device name.
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>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
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>
We have a dedicated pointer for that, so use it. Much easier to read and
less computation involved.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Define pr_fmt() macro for prefixing the module name to all
pr_*() outputs, in order to increase log message clarity.
Signed-off-by: Enrico Weigelt <info@metux.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
The current error message on failed probing tends to be a bit
misleading. Fix it to tell exactly that an APU v1 was not found.
Signed-off-by: Enrico Weigelt <info@metux.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Randy Dunlap