kernel/linux.git/drivers/leds, branch v4.4.235

leds: lm355x: avoid enum conversion warning

2020-08-21T08:53:00+00:00

[ 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

leds: leds-lp5562 allow firmware files up to the maximum length

2019-10-05T10:27:44+00:00

[ Upstream commit ed2abfebb041473092b41527903f93390d38afa7 ] Firmware files are in ASCII, using 2 hex characters per byte. The maximum length of a firmware string is therefore 16 (commands) * 2 (bytes per command) * 2 (characters per byte) = 64 Fixes: ff45262a85db ("leds: add new LP5562 LED driver") Signed-off-by: Nick Stoughton Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski Signed-off-by: Sasha Levin

leds: lp55xx: fix null deref on firmware load failure

2019-04-27T07:33:51+00:00

[ Upstream commit 5ddb0869bfc1bca6cfc592c74c64a026f936638c ] I've stumbled upon a kernel crash and the logs pointed me towards the lp5562 driver: > <4>[306013.841294] lp5562 0-0030: Direct firmware load for lp5562 failed with error -2 > <4>[306013.894990] lp5562 0-0030: Falling back to user helper > ... > <3>[306073.924886] lp5562 0-0030: firmware request failed > <1>[306073.939456] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > <4>[306074.251011] PC is at _raw_spin_lock+0x1c/0x58 > <4>[306074.255539] LR is at release_firmware+0x6c/0x138 > ... After taking a look I noticed firmware_release() could be called with either NULL or a dangling pointer. Fixes: 10c06d178df11 ("leds-lp55xx: support firmware interface") Signed-off-by: Michal Kazior Signed-off-by: Jacek Anaszewski Signed-off-by: Sasha Levin

leds: lp5523: fix a missing check of return value of lp55xx_read

2019-03-23T07:44:17+00:00

[ Upstream commit 248b57015f35c94d4eae2fdd8c6febf5cd703900 ] When lp55xx_read() fails, "status" is an uninitialized variable and thus may contain random value; using it leads to undefined behaviors. The fix inserts a check for the return value of lp55xx_read: if it fails, returns with its error code. Signed-off-by: Kangjie Lu Signed-off-by: Jacek Anaszewski Signed-off-by: Sasha Levin

leds: leds-gpio: Fix return value check in create_gpio_led()

2018-12-13T08:21:31+00:00

commit 2d88a331e48095cf60ad9bdf3177bd401bf99727 upstream. In case of error, the function gpio_to_desc() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun Signed-off-by: Jacek Anaszewski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman

leds: turn off the LED and wait for completion on unregistering LED class device

2018-12-13T08:21:31+00:00

commit d1aa577f5e191d77d3ad62da93729b5af9532bb4 upstream. Workqueue, 'set_brightness_work' is used for scheduling brightness control. This workqueue is canceled when the LED class device is unregistered. Currently, LED subsystem handles like below. cancel_work_sync(&led_cdev->set_brightness_work) led_set_brightness(led_cdev, LED_OFF) However, this could be a problem. Workqueue is going to be canceled but LED device needs to be off. The worst case is null pointer access due to scheduling a workqueue. LED module is loaded. LED driver private data is allocated by using devm_zalloc(). LED module is unloaded. led_classdev_unregister() is called. cancel_work_sync() led_set_brightness(led_cdev, LED_OFF) schedule_work() if LED driver uses brightness_set_blocking() In the meantime, driver private data will be freed. ..scheduling.. brightness_set_blocking() callback is invoked. For the brightness control, LED driver tries to access private data but resource is removed! To avoid this problem, LED subsystem should turn off the brightness first and wait for completion. led_set_brightness(led_cdev, LED_OFF) flush_work(&led_cdev->set_brightness_work) It guarantees that LED driver turns off the brightness prior to resource management. Cc: linux-leds@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Milo Kim Signed-off-by: Jacek Anaszewski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman

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

2018-12-13T08:21:30+00:00

commit f16703360da7731a057df2ffa902306819c22398 upstream. Some PWMs are disabled by default or the default pin setting does not match the LED_OFF state (e.g., active-low leds). Hence, the driver may end up reporting 0 brightness, but the leds are actually on using full brightness, because it never enforces its default configuration. So enforce it by calling led_pwm_set() after successfully registering the device. Tested on a Phytec phyFLEX i.MX6Q board based on kernel v3.19.5. Signed-off-by: Markus Hofstaetter Tested-by: Markus Hofstaetter Signed-off-by: Jacek Anaszewski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman

leds: pca955x: Correct I2C Functionality

2018-04-13T17:50:09+00:00

[ Upstream commit aace34c0bb8ea3c8bdcec865b6a4be4db0a68e33 ] The driver checks an incorrect flag of functionality of adapter. When a driver requires i2c_smbus_read_byte_data and i2c_smbus_write_byte_data, it should check I2C_FUNC_SMBUS_BYTE_DATA instead I2C_FUNC_I2C. This patch fixes the problem. Signed-off-by: Tin Huynh Signed-off-by: Jacek Anaszewski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Revert "led: core: Fix brightness setting when setting delay_off=0"

2018-03-11T15:19:45+00:00

This reverts commit 20ac8f72514b3af8b62c520d55656ded865eff00, which was commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c upstream. The bug that it should fix was only introduced in Linux 4.7, and in 4.4 it causes a regression. Reported-by: Jacek Anaszewski Cc: Matthieu CASTET Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

leds: do not overflow sysfs buffer in led_trigger_show

2018-03-11T15:19:45+00:00

commit 3b9b95363c45365d606ad4bbba16acca75fdf6d3 upstream. Per the documentation, use scnprintf instead of sprintf to ensure there is never more than PAGE_SIZE bytes of trigger names put into the buffer. Signed-off-by: Nathan Sullivan Signed-off-by: Zach Brown Signed-off-by: Jacek Anaszewski Cc: Willy Tarreau Cc: Vlastimil Babka Signed-off-by: Greg Kroah-Hartman