user/sven/linux.git/drivers/leds, branch v5.4.3

leds: lm3532: Fix optional led-max-microamp prop error handling

2019-09-12T18:45:52Z

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 Signed-off-by: Dan Murphy Signed-off-by: Jacek Anaszewski

led: triggers: Fix dereferencing of null pointer

2019-09-05T20:32:45Z

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

leds: ti-lmu-common: Move static keyword to the front of declaration

2019-09-03T18:34:46Z

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

leds: lm3532: Move static keyword to the front of declarations

2019-09-03T18:34:39Z

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

leds: trigger: gpio: GPIO 0 is valid

2019-09-01T11:33:30Z

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

leds: pwm: Use struct_size() helper

2019-09-01T11:33:29Z

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

leds: is31fl32xx: Use struct_size() helper

2019-09-01T11:33:29Z

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

leds: ti-lmu-common: Fix coccinelle issue in TI LMU

2019-09-01T11:33:28Z

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: 3fce8e1eb994 ("leds: TI LMU: Add common code for TI LMU devices") Signed-off-by: Dan Murphy Signed-off-by: Jacek Anaszewski

leds: lm3532: Avoid potentially unpaired regulator calls

2019-09-01T11:33:27Z

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

leds: syscon: Use resource managed variant of device register

2019-09-01T11:33:27Z

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