01 Oct, 2020
1 commit
-
[ Upstream commit 7c6082b903ac28dc3f383fba57c6f9e7e2594178 ]
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
Acked-by: Pavel Machek
Signed-off-by: Oleh Kravchenko
Signed-off-by: Pavel Machek
Signed-off-by: Sasha Levin
19 Aug, 2020
2 commits
-
[ Upstream commit 302a085c20194bfa7df52e0fe684ee0c41da02e6 ]
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
Acked-by: Jacek Anaszewski
Fixes: 81fe8e5b73e3 ("leds: core: Add led_set_brightness_nosleep{nopm} functions")
Signed-off-by: Pavel Machek
Signed-off-by: Sasha Levin -
[ Upstream commit 985b1f596f9ed56f42b8c2280005f943e1434c06 ]
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: b98d13c72592 ("leds: Add new LED driver for lm355x chips")
Signed-off-by: Arnd Bergmann
Signed-off-by: Pavel Machek
Signed-off-by: Sasha Levin
11 Aug, 2020
5 commits
-
commit eca21c2d8655387823d695b26e6fe78cf3975c05 upstream.
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: 375446df95ee ("leds: 88pm860x: Use devm_led_classdev_register")
Cc: stable # 4.6
Cc: Amitoj Kaur Chawla
Signed-off-by: Johan Hovold
Signed-off-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman -
commit d584221e683bbd173738603b83a315f27d27d043 upstream.
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: 50154e29e5cc ("leds: lm3533: Use devm_led_classdev_register")
Cc: stable # 4.6
Cc: Amitoj Kaur Chawla
Signed-off-by: Johan Hovold
Signed-off-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman -
commit 6f4aa35744f69ed9b0bf5a736c9ca9b44bc1dcea upstream.
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: eed16255d66b ("leds: da903x: Use devm_led_classdev_register")
Cc: stable # 4.6
Cc: Amitoj Kaur Chawla
Signed-off-by: Johan Hovold
Signed-off-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman -
commit a0972fff09479dd09b731360a3a0b09e4fb4d415 upstream.
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: 11e1bbc116a7 ("leds: lm36274: Introduce the TI LM36274 LED driver")
Cc: stable # 5.3
Cc: Dan Murphy
Signed-off-by: Johan Hovold
Signed-off-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman -
commit 47a459ecc800a17109d0c496a4e21e478806ee40 upstream.
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: 8d3b6a4001ce ("leds: wm831x-status: Use devm_led_classdev_register")
Cc: stable # 4.6
Cc: Amitoj Kaur Chawla
Signed-off-by: Johan Hovold
Signed-off-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman
23 Apr, 2020
1 commit
-
[ Upstream commit 64ed6588c2ea618d3f9ca9d8b365ae4c19f76225 ]
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: bb4e9af0348d ("leds: core: Add support for composing LED class device names")
Signed-off-by: Ricardo Ribalda Delgado
Acked-by: Jacek Anaszewski
Signed-off-by: Pavel Machek
Signed-off-by: Sasha Levin
24 Feb, 2020
1 commit
-
[ Upstream commit 697529091ac7a0a90ca349b914bb30641c13c753 ]
Before commit bb29b9cccd95 ("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: bb29b9cccd95 ("leds: pca963x: Add bindings to invert polarity")
Signed-off-by: Zahari Petkov
Signed-off-by: Pavel Machek
Signed-off-by: Sasha Levin
06 Feb, 2020
1 commit
-
[ Upstream commit 2424415d25a765d4302ddfb4de75427e9294dc09 ]
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
Signed-off-by: Pavel Machek
Signed-off-by: Sasha Levin
29 Jan, 2020
1 commit
-
commit 90a8e82d3ca8c1f85ac63f4a94c9b034f05af4ee upstream.
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: d7235f5feaa0 ("leds: gpio: Use generic support for composing LED names")
Cc: Russell King
Reviewed-by: Linus Walleij
Signed-off-by: Jacek Anaszewski
[fixed comment]
Signed-off-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman
26 Jan, 2020
1 commit
-
commit a2cafdfd8cf5ad8adda6c0ce44a59f46431edf02 upstream.
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 ONFixes: e370d010a5fe ("leds: tlc591xx: Driver for the TI 8/16 Channel i2c LED driver")
Signed-off-by: Jean-Jacques Hiblot
Signed-off-by: Pavel Machek
Signed-off-by: Greg Kroah-Hartman
05 Jan, 2020
3 commits
-
[ Upstream commit 5f820ed52371b4f5d8c43c93f03408d0dbc01e5b ]
The NETDEV_CHANGENAME code is not "unneeded" like it is stated in commit
4cb6560514fa ("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: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger")
Fixes: 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename")
Signed-off-by: Martin Schiller
Signed-off-by: Pavel Machek
Signed-off-by: Sasha Levin -
[ Upstream commit fc7b5028f2627133c7c18734715a08829eab4d1f ]
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
Signed-off-by: Pavel Machek
Signed-off-by: Sasha Levin -
[ Upstream commit 396128d2ffcba6e1954cfdc9a89293ff79cbfd7c ]
Instead use devm_regulator_get_optional since the regulator
is optional and check for errors.Signed-off-by: Guido Günther
Acked-by: Pavel Machek
Reviewed-by: Dan Murphy
Signed-off-by: Pavel Machek
Signed-off-by: Sasha Levin
13 Sep, 2019
1 commit
-
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 boundaryReported-by: Pavel Machek
Signed-off-by: Dan Murphy
Signed-off-by: Jacek Anaszewski
06 Sep, 2019
1 commit
-
Error was detected by PVS-Studio:
V522 Dereferencing of the null pointer 'led_cdev->trigger' might take place.Fixes: 2282e125a406 ("leds: triggers: let struct led_trigger::activate() return an error code")
Signed-off-by: Oleh Kravchenko
Reviewed-by: Uwe Kleine-König
Signed-off-by: Jacek Anaszewski
04 Sep, 2019
2 commits
-
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
Signed-off-by: Jacek Anaszewski -
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
Signed-off-by: Jacek Anaszewski
01 Sep, 2019
6 commits
-
Allow all valid GPIOs to be used in the driver.
Fixes: 17354bfe8527 ("leds: Add gpio-led trigger")
Signed-off-by: Andy Shevchenko
Signed-off-by: Jacek Anaszewski -
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
Reviewed-by: Kees Cook
Signed-off-by: Jacek Anaszewski -
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
Acked-by: Pavel Machek
Signed-off-by: Jacek Anaszewski -
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 < 0Fixes: 3fce8e1eb994 ("leds: TI LMU: Add common code for TI LMU devices")
Signed-off-by: Dan Murphy
Signed-off-by: Jacek Anaszewski -
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
Acked-by: Pavel Machek
Signed-off-by: Jacek Anaszewski -
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
Signed-off-by: Jacek Anaszewski
27 Aug, 2019
5 commits
-
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
Signed-off-by: Jacek Anaszewski -
Allow the full scale current to be configured at init.
Valid rangles are 5mA->29.8mA.Signed-off-by: Dan Murphy
Signed-off-by: Jacek Anaszewski -
Fixed misspelled words, added error check during probe
on the init of the registers, and fixed ALS/I2C control
mode.Fixes: bc1b8492c764 ("leds: lm3532: Introduce the lm3532 LED driver")
Reported-by: Pavel Machek
Signed-off-by: Dan Murphy
Acked-by: Pavel Machek
Signed-off-by: Jacek Anaszewski -
Change the define name of the full scale current registers.
Signed-off-by: Dan Murphy
Acked-by: Pavel Machek
Signed-off-by: Jacek Anaszewski -
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: bc1b8492c764 ("leds: lm3532: Introduce the lm3532 LED driver")
Reported-by: Pavel Machek
Signed-off-by: Dan Murphy
Acked-by: Pavel Machek
Signed-off-by: Jacek Anaszewski
24 Aug, 2019
2 commits
-
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
Signed-off-by: Jacek Anaszewski -
Switch the max77650 from OF to the fwnode property API.
Signed-off-by: Andy Shevchenko
Signed-off-by: Jacek Anaszewski
21 Aug, 2019
1 commit
-
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: 52c47742f79d ("leds: triggers: send uevent when changing triggers")
Signed-off-by: Wenwen Wang
Acked-by: Pavel Machek
Signed-off-by: Jacek Anaszewski
09 Aug, 2019
1 commit
-
This LED chip provides a GPIO driver, so include
rather than the legacy header
.Signed-off-by: Linus Walleij
Signed-off-by: Jacek Anaszewski
31 Jul, 2019
1 commit
-
Generic Device Lookup Helpers
Persistent tag for others to pull this branch from
Based on patch series from Suzuki K Poulose
with Subject: [PATCH v3 0/7] drivers: Add generic device lookup helpersSigned-off-by: Greg Kroah-Hartman
* 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
30 Jul, 2019
3 commits
-
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
Cc: Alexander Aring
Cc: Alexander Shishkin
Cc: Arnd Bergmann
Cc: Dan Murphy
Cc: Harald Freudenberger
Cc: Heiko Carstens
Cc: Jacek Anaszewski
Cc: Lee Jones
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
Cc: Pavel Machek
Cc: Peter Oberparleiter
Cc: "Rafael J. Wysocki"
Cc: Stefan Schmidt
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Signed-off-by: Suzuki K Poulose
Reviewed-by: Heikki Krogerus
Acked-by: Alexandre Belloni
Link: https://lore.kernel.org/r/20190723221838.12024-2-suzuki.poulose@arm.com
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Pavel Machek
Signed-off-by: Jacek Anaszewski -
Since commit ebc278f15759 ("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
Signed-off-by: Masahiro Yamada
Signed-off-by: Jacek Anaszewski
26 Jul, 2019
1 commit
-
Use fwnode_property_count_uXX() directly, that makes code neater.
Signed-off-by: Andy Shevchenko
Acked-by: Dan Murphy
Signed-off-by: Jacek Anaszewski