kernel/drivers/leds/leds-mlxreg.c, branch linux-6.19.y

leds: mlxreg: Use devm_mutex_init() for mutex initialization

2024-04-11T16:35:18Z

In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead. Signed-off-by: George Stark Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240411161032.609544-8-gnstark@salutedevices.com Signed-off-by: Lee Jones

leds: mlxreg: Drop an excess struct mlxreg_led_data member

2024-03-07T08:48:16Z

Drop one struct member description to fix a kernel-doc warning: drivers/leds/leds-mlxreg.c:42: warning: Excess struct member 'led_data' description in 'mlxreg_led_data' Signed-off-by: Randy Dunlap Acked-by: Vadim Pasternak Link: https://lore.kernel.org/r/20240229071931.7870-4-rdunlap@infradead.org Signed-off-by: Lee Jones

leds: Convert all platform drivers to return void

2023-11-01T11:28:35Z

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). All platform drivers below drivers/leds/ unconditionally return zero in their remove callback and so can be converted trivially to the variant returning void. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20230917130947.1122198-1-u.kleine-koenig@pengutronix.de Signed-off-by: Lee Jones

leds: Explicitly include correct DT includes

2023-07-28T09:02:32Z

The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20230714174651.4058753-1-robh@kernel.org Signed-off-by: Lee Jones

leds: leds-mlxreg: Fix incorrect documentation of struct member 'led_cdev' and 'led_cdev_name'

2021-05-28T09:38:59Z

Fixes the following W=1 kernel build warning(s): drivers/leds/leds-mlxreg.c:42: warning: Function parameter or member 'led_cdev' not described in 'mlxreg_led_data' drivers/leds/leds-mlxreg.c:42: warning: Function parameter or member 'led_cdev_name' not described in 'mlxreg_led_data' Cc: Vadim Pasternak Cc: Pavel Machek Cc: linux-leds@vger.kernel.org Signed-off-by: Lee Jones Signed-off-by: Pavel Machek

leds: mlxreg: Fix possible buffer overflow

2019-11-03T16:39:00Z

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

leds: mlxreg: Add support for capability register

2019-02-23T17:20:46Z

Add support for capability register in order to distinct between the systems with minor LED configuration differences. It reduces the amount of code describing systems' LED configuration. For example one system can be equipped with six LED, while the other with only four. Reading this information from the capability registers allows to use the same LED structure for such systems and set the relevant configuration dynamically based on capability register content. Signed-off-by: Vadim Pasternak Acked-by: Jacek Anaszewski Signed-off-by: Darren Hart (VMware)

leds: add driver for support Mellanox regmap LEDs for BMC and x86 platform

2018-02-19T20:09:20Z

Driver obtains LED devices according to system configuration and creates devices in form: "devicename:color:function", like The full path is to be: /sys/class/leds/mlxreg\:status\:amber/brightness After timer trigger activation: echo timer > /sys/class/leds/mlxreg\:status\:amber/trigger Attributes for LED blinking will appaer in sysfs infrastructure: /sys/class/leds/mlxreg\:status\:amber/delay_off /sys/class/leds/mlxreg\:status\:amber/delay_on LED setting is controlled through the on-board programmable devices, which exports its register map. This device could be attached to any bus type, for which register mapping is supported. Signed-off-by: Vadim Pasternak Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski