- 30 Jan, 2023 37 commits
-
-
Arnd Bergmann authored
Since ASIC3 MFD driver is removed, the LED support is also obsolete. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230105134622.254560-25-arnd@kernel.org
-
Henning Schild authored
If we register a "leds-gpio" platform device for GPIO pins that do not exist we get a -EPROBE_DEFER and the probe will be tried again later. If there is no driver to provide that pin we will poll forever and also create a lot of log messages. So check if that GPIO driver is configured, if so it will come up eventually. If not, we exit our probe function early and do not even bother registering the "leds-gpio". This method was chosen over "Kconfig depends" since this way we can add support for more devices and GPIO backends more easily without "depends":ing on all GPIO backends. Fixes: a6c80bec ("leds: simatic-ipc-leds-gpio: Add GPIO version of Siemens driver") Signed-off-by:
Henning Schild <henning.schild@siemens.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
Replace open coded fwnode_device_is_compatible() in the driver. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by:
-
Andy Shevchenko authored
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by:
-
Andy Shevchenko authored
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by:
-
Andy Shevchenko authored
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Andy Shevchenko authored
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by:
-
Andy Shevchenko authored
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by:
-
Andy Shevchenko authored
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by:
-
Andy Shevchenko authored
There are users inside and outside LED framework that have implemented a local copy of led_init_default_state_get(). In order to deduplicate that, as the first step move the declaration from LED header to the global one. Signed-off-by:
-
Andy Shevchenko authored
Add missing includes and forward declarations to leds.h. While at it, replace headers by forward declarations and vise versa. Signed-off-by:
-
Andy Shevchenko authored
Clang complains that devm_add_action() takes a parameter with a wrong type: warning: cast from 'void (*)(struct mutex *)' to 'void (*)(void *)' converts to incompatible function type [-Wcast-function-type-strict] err = devm_add_action(dev, (void (*)(void *))mutex_destroy, &is31->lock); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. It appears that the commit e1af5c81 ("leds: is31fl319x: Fix devm vs. non-devm ordering") missed two things: - whilst the commit mentions devm_add_action_or_reset() the actual change utilised devm_add_action() call by mistake - strictly speaking the parameter is not compatible by type Fix both issues by switching to devm_add_action_or_reset() and adding a wrapper for mutex_destroy() call. Reported-by:kernel test robot <lkp@intel.com> Fixes: e1af5c81 ("leds: is31fl319x: Fix devm vs. non-devm ordering") Signed-off-by:
Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by:
-
Miaoqian Lin authored
class_find_device_by_of_node() calls class_find_device(), it will take the reference, use the put_device() to drop the reference when not need anymore. Fixes: 699a8c7c ("leds: Add of_led_get() and led_put()") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Signed-off-by:
-
Hui Wang authored
I defined 2 leds in the device tree, in the 1st led node, the max-brightness is set to 248, while in the 2nd led node, I mis-spelled the max-brightness to max-brighttness, but the driver is still able to get the max-brightness 248 for the 2nd node, that is because the led structure is not cleared before parsing each child node. pwmleds { compatible = "pwm-leds"; pwm-green { ... max-brightness = <248>; }; pwm-red { ... max-brighttness = <128>; }; Signed-off-by:Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
- 27 Jan, 2023 3 commits
-
-
Hans de Goede authored
Add a generic [devm_]led_get() method which can be used on both devicetree and non devicetree platforms to get a LED classdev associated with a specific function on a specific device, e.g. the privacy LED associated with a specific camera sensor. Note unlike of_led_get() this takes a string describing the function rather then an index. This is done because e.g. camera sensors might have a privacy LED, or a flash LED, or both and using an index approach leaves it unclear what the function of index 0 is if there is only 1 LED. This uses a lookup-table mechanism for non devicetree platforms. This allows the platform code to map specific LED class_dev-s to a specific device,function combinations this way. For devicetree platforms getting the LED by function-name could be made to work using the standard devicetree pattern of adding a -names string array to map names to the indexes. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
Add a __devm_led_get() helper which registers a passed in led_classdev with devm for unregistration. This is a preparation patch for adding a generic (non devicetree specific) devm_led_get() function. Reviewed-by:
-
Hans de Goede authored
Split out part of of_led_get() into a generic led_module_get() helper function. This is a preparation patch for adding a generic (non devicetree specific) led_get() function. Reviewed-by:
-
