summaryrefslogtreecommitdiff
path: root/drivers/leds
AgeCommit message (Collapse)AuthorFilesLines
2024-08-11leds: triggers: Flush pending brightness before activating triggerThomas Weißschuh2-5/+6
[ Upstream commit ab477b766edd3bfb6321a6e3df4c790612613fae ] The race fixed in timer_trig_activate() between a blocking set_brightness() call and trigger->activate() can affect any trigger. So move the call to flush_work() into led_trigger_set() where it can avoid the race for all triggers. Fixes: 0db37915d912 ("leds: avoid races with workqueue") Fixes: 8c0f693c6eff ("leds: avoid flush_work in atomic context") Cc: stable@vger.kernel.org Tested-by: Dustin L. Howett <dustin@howett.net> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-led-trigger-flush-v2-1-f4f970799d77@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-11leds: trigger: Call synchronize_rcu() before calling trig->activate()Hans de Goede1-0/+7
[ Upstream commit b1bbd20f35e19774ea01989320495e09ac44fba3 ] Some triggers call led_trigger_event() from their activate() callback to initialize the brightness of the LED for which the trigger is being activated. In order for the LED's initial state to be set correctly this requires that the led_trigger_event() call uses the new version of trigger->led_cdevs, which has the new LED. AFAICT led_trigger_event() will always use the new version when it is running on the same CPU as where the list_add_tail_rcu() call was made, which is why the missing synchronize_rcu() has not lead to bug reports. But if activate() is pre-empted, sleeps or uses a worker then the led_trigger_event() call may run on another CPU which may still use the old trigger->led_cdevs list. Add a synchronize_rcu() call to ensure that any led_trigger_event() calls done from activate() always use the new list. Triggers using led_trigger_event() from their activate() callback are: net/bluetooth/leds.c, net/rfkill/core.c and drivers/tty/vt/keyboard.c. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240531120124.75662-1-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org> Stable-dep-of: ab477b766edd ("leds: triggers: Flush pending brightness before activating trigger") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-11leds: trigger: Store brightness set by led_trigger_event()Heiner Kallweit1-2/+4
[ Upstream commit 822c91e72eac568ed8d83765634f00decb45666c ] If a simple trigger is assigned to a LED, then the LED may be off until the next led_trigger_event() call. This may be an issue for simple triggers with rare led_trigger_event() calls, e.g. power supply charging indicators (drivers/power/supply/power_supply_leds.c). Therefore persist the brightness value of the last led_trigger_event() call and use this value if the trigger is assigned to a LED. In addition add a getter for the trigger brightness value. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/b1358b25-3f30-458d-8240-5705ae007a8a@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> Stable-dep-of: ab477b766edd ("leds: triggers: Flush pending brightness before activating trigger") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-11leds: trigger: Remove unused function led_trigger_rename_static()Heiner Kallweit1-13/+0
[ Upstream commit c82a1662d4548c454de5343b88f69b9fc82266b3 ] This function was added with a8df7b1ab70b ("leds: add led_trigger_rename function") 11 yrs ago, but it has no users. So remove it. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/d90f30be-f661-4db7-b0b5-d09d07a78a68@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> Stable-dep-of: ab477b766edd ("leds: triggers: Flush pending brightness before activating trigger") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03leds: mt6360: Fix memory leak in mt6360_init_isnk_properties()Javier Carrasco1-1/+4
commit e41d574b359ccd8d99be65c6f11502efa2b83136 upstream. The fwnode_for_each_child_node() loop requires manual intervention to decrement the child refcount in case of an early return. Add the missing calls to fwnode_handle_put(child) to avoid memory leaks in the error paths. Cc: stable@vger.kernel.org Fixes: 679f8652064b ("leds: Add mt6360 driver") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20240611-leds-mt6360-memleak-v1-1-93642eb5011e@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03leds: ss4200: Convert PCIBIOS_* return codes to errnosIlpo Järvinen1-2/+5
commit ce068e83976140badb19c7f1307926b4b562fac4 upstream. ich7_lpc_probe() uses pci_read_config_dword() that returns PCIBIOS_* codes. The error handling code assumes incorrectly it's a normal errno and checks for < 0. The return code is returned from the probe function as is but probe functions should return normal errnos. Remove < 0 from the check and convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it. Fixes: a328e95b82c1 ("leds: LED driver for Intel NAS SS4200 series (v5)") Cc: <stable@vger.kernel.org> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240527132700.14260-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03Revert "leds: led-core: Fix refcount leak in of_led_get()"Luca Ceresoli1-1/+0
[ Upstream commit 940b27161afc6ec53fc66245a4fb3518394cdc92 ] This reverts commit da1afe8e6099980fe1e2fd7436dca284af9d3f29. Commit 699a8c7c4bd3 ("leds: Add of_led_get() and led_put()"), introduced in 5.5, added of_led_get() and led_put() but missed a put_device() in led_put(), thus creating a leak in case the consumer device is removed. Arguably device removal was not very popular, so this went apparently unnoticed until 2022. In January 2023 two different patches got merged to fix the same bug: - commit da1afe8e6099 ("leds: led-core: Fix refcount leak in of_led_get()") - commit 445110941eb9 ("leds: led-class: Add missing put_device() to led_put()") They fix the bug in two different ways, which creates no patch conflicts, and both were merged in v6.2. The result is that now there is one more put_device() than get_device()s, instead of one less. Arguably device removal is not very popular yet, so this apparently hasn't been noticed as well up to now. But it blew up here while I'm working with device tree overlay insertion and removal. The symptom is an apparently unrelated list of oopses on device removal, with reasons: kernfs: can not remove 'uevent', no directory kernfs: can not remove 'brightness', no directory kernfs: can not remove 'max_brightness', no directory ... Here sysfs fails removing attribute files, which is because the device name changed and so the sysfs path. This is because the device name string got corrupted, which is because it got freed too early and its memory reused. Different symptoms could appear in different use cases. Fix by removing one of the two fixes. The choice was to remove commit da1afe8e6099 because: * it is calling put_device() inside of_led_get() just after getting the device, thus it is basically not refcounting the LED device at all during its entire lifetime * it does not add a corresponding put_device() in led_get(), so it fixes only the OF case The other fix (445110941eb9) is adding the put_device() in led_put() so it covers the entire lifetime, and it works even in the non-DT case. Fixes: da1afe8e6099 ("leds: led-core: Fix refcount leak in of_led_get()") Co-developed-by: Hervé Codina <herve.codina@bootlin.com> Signed-off-by: Hervé Codina <herve.codina@bootlin.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20240625-led-class-device-leak-v2-1-75fdccf47421@bootlin.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03leds: trigger: Unregister sysfs attributes before calling deactivate()Hans de Goede1-1/+1
[ Upstream commit c0dc9adf9474ecb7106e60e5472577375aedaed3 ] Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback. Calling device_remove_groups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data. Move the device_remove_groups() call to before deactivate() to close this race window. This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling device_add_groups(). Fixes: a7e7a3156300 ("leds: triggers: add device attribute support") Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240504162533.76780-1-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27leds: sgm3140: Add missing timer cleanup and flash gpio controlOndrej Jirman1-0/+3
[ Upstream commit 205c29887a333ee4b37596e6533373e38cb23947 ] Enabling strobe and then setting brightness to 0 causes the driver to enter invalid state after strobe end timer fires. We should cancel strobe mode resources when changing brightness (aka torch mode). Fixes: cef8ec8cbd21 ("leds: add sgm3140 driver") Signed-off-by: Ondrej Jirman <megi@xff.cz> Link: https://lore.kernel.org/r/20240217191133.1757553-1-megi@xff.cz Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-27leds: aw2013: Unlock mutex before destroying itGeorge Stark1-0/+1
[ Upstream commit 6969d0a2ba1adc9ba6a49b9805f24080896c255c ] In the probe() callback in case of error mutex is destroyed being locked which is not allowed so unlock the mutex before destroying. Fixes: 59ea3c9faf32 ("leds: add aw2013 driver") Signed-off-by: George Stark <gnstark@salutedevices.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231214173614.2820929-2-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-02-05leds: trigger: panic: Don't register panic notifier if creating the trigger ↵Heiner Kallweit1-1/+4
failed [ Upstream commit afacb21834bb02785ddb0c3ec197208803b74faa ] It doesn't make sense to register the panic notifier if creating the panic trigger failed. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/8a61e229-5388-46c7-919a-4d18cc7362b2@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-26leds: aw2013: Select missing dependency REGMAP_I2CDang Huynh1-0/+1
[ Upstream commit 75469bb0537ad2ab0fc1fb6e534a79cfc03f3b3f ] The AW2013 driver uses devm_regmap_init_i2c, so REGMAP_I2C needs to be selected. Otherwise build process may fail with: ld: drivers/leds/leds-aw2013.o: in function `aw2013_probe': leds-aw2013.c:345: undefined reference to `__devm_regmap_init_i2c' Signed-off-by: Dang Huynh <danct12@riseup.net> Acked-by: Nikita Travkin <nikita@trvn.ru> Fixes: 59ea3c9faf32 ("leds: add aw2013 driver") Link: https://lore.kernel.org/r/20231103114203.1108922-1-danct12@riseup.net Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-01-20leds: ledtrig-tty: Free allocated ttyname buffer on deactivateFlorian Eckert1-0/+4
commit 25054b232681c286fca9c678854f56494d1352cc upstream. The ttyname buffer for the ledtrig_tty_data struct is allocated in the sysfs ttyname_store() function. This buffer must be released on trigger deactivation. This was missing and is thus a memory leak. While we are at it, the TTY handler in the ledtrig_tty_data struct should also be returned in case of the trigger deactivation call. Cc: stable@vger.kernel.org Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger") Signed-off-by: Florian Eckert <fe@dev.tdt.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20231127081621.774866-1-fe@dev.tdt.de Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-20leds: trigger: ledtrig-cpu:: Fix 'output may be truncated' issue for 'cpu'Christophe JAILLET1-2/+2
[ Upstream commit ff50f53276131a3059e8307d11293af388ed2bcd ] In order to teach the compiler that 'trig->name' will never be truncated, we need to tell it that 'cpu' is not negative. When building with W=1, this fixes the following warnings: drivers/leds/trigger/ledtrig-cpu.c: In function ‘ledtrig_cpu_init’: drivers/leds/trigger/ledtrig-cpu.c:155:56: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 5 [-Werror=format-truncation=] 155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu); | ^~ drivers/leds/trigger/ledtrig-cpu.c:155:52: note: directive argument in the range [-2147483648, 7] 155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu); | ^~~~~~~ drivers/leds/trigger/ledtrig-cpu.c:155:17: note: ‘snprintf’ output between 5 and 15 bytes into a destination of size 8 155 | snprintf(trig->name, MAX_NAME_LEN, "cpu%d", cpu); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 8f88731d052d ("led-triggers: create a trigger for CPU activity") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/3f4be7a99933cf8566e630da54f6ab913caac432.1695453322.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20leds: pwm: Don't disable the PWM when the LED should be offUwe Kleine-König1-1/+1
[ Upstream commit 76fe464c8e64e71b2e4af11edeef0e5d85eeb6aa ] Disabling a PWM (i.e. calling pwm_apply_state with .enabled = false) gives no guarantees what the PWM output does. It might freeze where it currently is, or go in a High-Z state or drive the active or inactive state, it might even continue to toggle. To ensure that the LED gets really disabled, don't disable the PWM even when .duty_cycle is zero. This fixes disabling a leds-pwm LED on i.MX28. The PWM on this SoC is one of those that freezes its output on disable, so if you disable an LED that is full on, it stays on. If you disable a LED with half brightness it goes off in 50% of the cases and full on in the other 50%. Fixes: 41c42ff5dbe2 ("leds: simple driver for pwm driven LEDs") Reported-by: Rogan Dawes <rogan@dawes.za.net> Reported-by: Fabio Estevam <festevam@denx.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Fabio Estevam <festevam@denx.de> Link: https://lore.kernel.org/r/20230922192834.1695727-1-u.kleine-koenig@pengutronix.de Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20leds: turris-omnia: Do not use SMBUS callsMarek Behún1-12/+42
[ Upstream commit 6de283b96b31b4890e3ee8c86caca2a3a30d1011 ] The leds-turris-omnia driver uses three function for I2C access: - i2c_smbus_write_byte_data() and i2c_smbus_read_byte_data(), which cause an emulated SMBUS transfer, - i2c_master_send(), which causes an ordinary I2C transfer. The Turris Omnia MCU LED controller is not semantically SMBUS, it operates as a simple I2C bus. It does not implement any of the SMBUS specific features, like PEC, or procedure calls, or anything. Moreover the I2C controller driver also does not implement SMBUS, and so the emulated SMBUS procedure from drivers/i2c/i2c-core-smbus.c is used for the SMBUS calls, which gives an unnecessary overhead. When I first wrote the driver, I was unaware of these facts, and I simply used the first function that worked. Drop the I2C SMBUS calls and instead use simple I2C transfers. Fixes: 089381b27abe ("leds: initial support for Turris Omnia LEDs") Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20230918161104.20860-2-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-11-20leds: turris-omnia: Drop unnecessary mutex lockingMarek Behún1-10/+1
[ Upstream commit 760b6b7925bf09491aafa4727eef74fc6bf738b0 ] Do not lock driver mutex in the global LED panel brightness sysfs accessors brightness_show() and brightness_store(). The mutex locking is unnecessary here. The I2C transfers are guarded by I2C core locking mechanism, and the LED commands itself do not interfere with other commands. Fixes: 089381b27abe ("leds: initial support for Turris Omnia LEDs") Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230802160748.11208-2-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Stable-dep-of: 6de283b96b31 ("leds: turris-omnia: Do not use SMBUS calls") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-10leds: Drop BUG_ON check for LED_COLOR_ID_MULTIMarek Behún1-4/+0
[ Upstream commit 9dc1664fab2246bc2c3e9bf2cf21518a857f9b5b ] Commit c3f853184bed ("leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false") fixed a no-op BUG_ON. This turned out to cause a regression, since some in-tree device-tree files already use LED_COLOR_ID_MULTI. Drop the BUG_ON altogether. Fixes: c3f853184bed ("leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false") Reported-by: Da Xue <da@libre.computer> Closes: https://lore.kernel.org/linux-leds/ZQLelWcNjjp2xndY@duo.ucw.cz/T/ Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20230918140724.18634-1-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13leds: trigger: tty: Do not use LED_ON/OFF constants, use ↵Marek Behún1-4/+8
led_blink_set_oneshot instead [ Upstream commit 730094577e0c37e1bc40be37cbd41f71b0a8a2a4 ] The tty LED trigger uses the obsolete LED_ON & LED_OFF constants when setting LED brightness. This is bad because the LED_ON constant is equal to 1, and so when activating the tty LED trigger on a LED class device with max_brightness greater than 1, the LED is dimmer than it can be (when max_brightness is 255, the LED is very dimm indeed; some devices translate 1/255 to 0, so the LED is OFF all the time). Instead of directly setting brightness to a specific value, use the led_blink_set_oneshot() function from LED core to configure the blink. This function takes the current configured brightness as blink brightness if not zero, and max brightness otherwise. This also changes the behavior of the TTY LED trigger. Previously if rx/tx stats kept changing, the LED was ON all the time they kept changing. With this patch the LED will blink on TTY activity. Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger") Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20230802090753.13611-1-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always falseMarek Behún1-4/+4
[ Upstream commit c3f853184bed04105682383c2971798c572226b5 ] At the time we call BUG_ON(props.color == LED_COLOR_ID_MULTI); the props variable is still initialized to zero. Call the BUG_ON only after we parse fwnode into props. Fixes: 77dce3a22e89 ("leds: disallow /sys/class/leds/*:multi:* for now") Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20230801151623.30387-1-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13leds: multicolor: Use rounded division when calculating color componentsMarek Behún1-3/+5
[ Upstream commit 065d099f1be58187e6629273c50b948a02b7e1bf ] Given channel intensity, LED brightness and max LED brightness, the multicolor LED framework helper led_mc_calc_color_components() computes the color channel brightness as chan_brightness = brightness * chan_intensity / max_brightness Consider the situation when (brightness, intensity, max_brightness) is for example (16, 15, 255), then chan_brightness is computed to 0 although the fractional divison would give 0.94, which should be rounded to 1. Use DIV_ROUND_CLOSEST here for the division to give more realistic component computation: chan_brightness = DIV_ROUND_CLOSEST(brightness * chan_intensity, max_brightness) Fixes: 55d5d3b46b08 ("leds: multicolor: Introduce a multicolor class definition") Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20230801124931.8661-1-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13leds: pwm: Fix error code in led_pwm_create_fwnode()Dan Carpenter1-1/+1
[ Upstream commit cadb2de2a7fd9e955381307de3eddfcc386c208e ] Negative -EINVAL was intended, not positive EINVAL. Fix it. Fixes: 95138e01275e ("leds: pwm: Make error handling more robust") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/a33b981a-b2c4-4dc2-b00a-626a090d2f11@moroto.mountain Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-23led: qcom-lpg: Fix resource leaks in for_each_available_child_of_node() loopsLu Hongfei1-2/+6
[ Upstream commit 8f38f8fa7261819eb7d4fb369dc3bfab72259033 ] Ensure child node references are decremented properly in the error path. Signed-off-by: Lu Hongfei <luhongfei@vivo.com> Link: https://lore.kernel.org/r/20230525111705.3055-1-luhongfei@vivo.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev renameChristian Marangi1-0/+3
commit cee4bd16c3195a701be683f7da9e88c6e11acb73 upstream. Dev can be renamed also while up for supported device. We currently wrongly clear the NETDEV_LED_MODE_LINKUP flag on NETDEV_CHANGENAME event. Fix this by rechecking if the carrier is ok on NETDEV_CHANGENAME and correctly set the NETDEV_LED_MODE_LINKUP bit. Fixes: 5f820ed52371 ("leds: trigger: netdev: fix handling on interface rename") Cc: stable@vger.kernel.org # v5.5+ Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419210743.3594-2-ansuelsmth@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-11leds: tca6507: Fix error handling of using fwnode_property_read_stringH. Nikolaus Schaller1-2/+3
[ Upstream commit c1087c29e96a48e9080377e168d35dcb52fb068b ] Commit 96f524105b9c ("leds: tca6507: use fwnode API instead of OF") changed to fwnode API but did not take into account that a missing property "linux,default-trigger" now seems to return an error and as a side effect sets value to -1. This seems to be different from of_get_property() which always returned NULL in any case of error. Neglecting this side-effect leads to [ 11.201965] Unable to handle kernel paging request at virtual address ffffffff when read in the strcmp() of led_trigger_set_default() if there is no led-trigger defined in the DTS. I don't know if this was recently introduced somewhere in the fwnode lib or if the effect was missed in initial testing. Anyways it seems to be a bug to ignore the error return value of an optional value here in the driver. Fixes: 96f524105b9c ("leds: tca6507: use fwnode API instead of OF") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Marek Behún <kabel@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/cbae7617db83113de726fcc423a805ebaa1bfca6.1680433978.git.hns@goldelico.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11leds: TI_LMU_COMMON: select REGMAP instead of depending on itRandy Dunlap1-1/+1
[ Upstream commit a61079efc87888587e463afaed82417b162fbd69 ] REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on REGMAP" to "select REGMAP". Fixes: 3fce8e1eb994 ("leds: TI LMU: Add common code for TI LMU devices") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230226053953.4681-5-rdunlap@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-13pwm: Make .get_state() callback return an error codeUwe Kleine-König1-6/+8
[ Upstream commit 6c452cff79f8bf1c0146fda598d32061cfd25443 ] .get_state() might fail in some cases. To make it possible that a driver signals such a failure change the prototype of .get_state() to return an error code. This patch was created using coccinelle and the following semantic patch: @p1@ identifier getstatefunc; identifier driver; @@ struct pwm_ops driver = { ..., .get_state = getstatefunc ,... }; @p2@ identifier p1.getstatefunc; identifier chip, pwm, state; @@ -void +int getstatefunc(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state *state) { ... - return; + return 0; ... } plus the actual change of the prototype in include/linux/pwm.h (plus some manual fixing of indentions and empty lines). So for now all drivers return success unconditionally. They are adapted in the following patches to make the changes easier reviewable. Reviewed-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Acked-by: Douglas Anderson <dianders@chromium.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20221130152148.2769768-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Stable-dep-of: 6f5793798014 ("pwm: hibvt: Explicitly set .polarity in .get_state()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10leds: simatic-ipc-leds-gpio: Make sure we have the GPIO providing driverHenning Schild1-0/+2
[ Upstream commit c64964ebee2a415384385205950ee7a05f78451e ] 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: a6c80bec3c93 ("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: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221007153323.1326-1-henning.schild@siemens.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10leds: is31fl319x: Wrap mutex_destroy() for devm_add_action_or_rest()Andy Shevchenko1-1/+6
[ Upstream commit a82c7cf803d98751cd3ddb35828faad925d71982 ] 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 e1af5c815586 ("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: e1af5c815586 ("leds: is31fl319x: Fix devm vs. non-devm ordering") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221228093238.82713-1-andriy.shevchenko@linux.intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10leds: led-core: Fix refcount leak in of_led_get()Miaoqian Lin1-0/+1
[ Upstream commit da1afe8e6099980fe1e2fd7436dca284af9d3f29 ] 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: 699a8c7c4bd3 ("leds: Add of_led_get() and led_put()") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221220121807.1543790-1-linmq006@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10leds: led-class: Add missing put_device() to led_put()Hans de Goede1-1/+4
[ Upstream commit 445110941eb94709216363f9d807d2508e64abd7 ] led_put() is used to "undo" a successful of_led_get() call, of_led_get() uses class_find_device_by_of_node() which returns a reference to the device which must be free-ed with put_device() when the caller is done with it. Add a put_device() call to led_put() to free the reference returned by class_find_device_by_of_node(). And also add a put_device() in the error-exit case of try_module_get() failing. Fixes: 699a8c7c4bd3 ("leds: Add of_led_get() and led_put()") Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-2-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31leds: is31fl319x: Fix setting current limit for is31fl319{0,1,3}Luca Weiss1-1/+2
[ Upstream commit 135780f1048b3f956f5b10bb23dec9c2d2c4ef6d ] The current setting lives in bits 4:2 (as also defined by the mask) but the current limit defines in the driver use bits 2:0 which should be shifted over so they don't get masked out completely (except for 17.5mA which became 10mA). Now checking /sys/kernel/debug/regmap/1-0068/registers shows that the current limit is applied correctly and doesn't take the default b000 = 42mA. Fixes: fa877cf1abb9 ("leds: is31fl319x: Add support for is31fl319{0,1,3} chips") Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31led: qcom-lpg: Fix sleeping in atomicDmitry Baryshkov1-7/+11
[ Upstream commit 3031993b3474794ecb71b6f969a3e60e4bda9d8a ] lpg_brighness_set() function can sleep, while led's brightness_set() callback must be non-blocking. Change LPG driver to use brightness_set_blocking() instead. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/0 preempt_count: 101, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.1.0-rc1-00014-gbe99b089c6fc-dirty #85 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) Call trace: dump_backtrace.part.0+0xe4/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x88/0xb4 dump_stack+0x18/0x34 __might_resched+0x170/0x254 __might_sleep+0x48/0x9c __mutex_lock+0x4c/0x400 mutex_lock_nested+0x2c/0x40 lpg_brightness_single_set+0x40/0x90 led_set_brightness_nosleep+0x34/0x60 led_heartbeat_function+0x80/0x170 call_timer_fn+0xb8/0x340 __run_timers.part.0+0x20c/0x254 run_timer_softirq+0x3c/0x7c _stext+0x14c/0x578 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x164/0x170 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x64/0x68 cpuidle_enter_state+0xc8/0x380 cpuidle_enter+0x38/0x50 do_idle+0x244/0x2d0 cpu_startup_entry+0x24/0x30 rest_init+0x128/0x1a0 arch_post_acpi_subsys_init+0x0/0x18 start_kernel+0x6f4/0x734 __primary_switched+0xbc/0xc4 Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-24leds: simatic-ipc-leds-gpio: fix incorrect LED to GPIO mappingHenning Schild1-6/+6
For apollolake the mapping between LEDs and GPIO pins was off because of a refactoring when we introduced a new device model. In addition to the reordering the indices in the lookup table need to be updated as well. Fixes: a97126265dfe ("leds: simatic-ipc-leds-gpio: add new model 227G") Signed-off-by: Henning Schild <henning.schild@siemens.com> Link: https://lore.kernel.org/r/20221024092027.4529-1-henning.schild@siemens.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-10-14Merge tag 'leds-6.1-rc1' of ↵Linus Torvalds1-2/+20
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds Pull LED updates from Pavel Machek: "This is very quiet release for LEDs, pca963 got blinking support and that's pretty much it" * tag 'leds-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: leds: pca963: fix misleading indentation dt-bindings: leds: Document mmc trigger leds: pca963x: fix blink with hw acceleration
2022-10-05Merge tag 'platform-drivers-x86-v6.1-1' of ↵Linus Torvalds1-5/+37
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver updates from Hans de Goede: - AMD Platform Management Framework (PMF) driver with AMT and QnQF support - AMD PMC: Improved logging for debugging s2idle issues - Big refactor of the ACPI/x86 backlight handling, ensuring that we only register 1 /sys/class/backlight device per LCD panel - Microsoft Surface: - Surface Laptop Go 2 support - Surface Pro 8 HID sensor support - Asus WMI: - Lots of cleanups - Support for TUF RGB keyboard backlight control - Add support for ROG X13 tablet mode - Siemens Simatic: IPC227G and IPC427G support - Toshiba ACPI laptop driver: Fan hwmon and battery ECO mode support - tools/power/x86/intel-speed-select: Various improvements - Various cleanups - Various small bugfixes * tag 'platform-drivers-x86-v6.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (153 commits) platform/x86: use PLATFORM_DEVID_NONE instead of -1 platform/x86/amd: pmc: Dump idle mask during "check" stage instead platform/x86/intel/wmi: thunderbolt: Use dev_groups callback platform/x86/amd: pmc: remove CONFIG_DEBUG_FS checks platform/surface: Split memcpy() of struct ssam_event flexible array platform/x86: compal-laptop: Get rid of a few forward declarations platform/x86: intel-uncore-freq: Use sysfs_emit() to instead of scnprintf() platform/x86: dell-smbios-base: Use sysfs_emit() platform/x86/amd/pmf: Remove unused power_delta instances platform/x86/amd/pmf: install notify handler after acpi init Documentation/ABI/testing/sysfs-amd-pmf: Add ABI doc for AMD PMF platform/x86/amd/pmf: Add sysfs to toggle CnQF platform/x86/amd/pmf: Add support for CnQF platform/x86/amd: pmc: Fix build without debugfs platform/x86: hp-wmi: Support touchpad on/off platform/x86: int3472/discrete: Drop a forward declaration platform/x86: toshiba_acpi: change turn_on_panel_on_resume to static platform/x86: wmi: Drop forward declaration of static functions platform/x86: toshiba_acpi: Remove duplicate include platform/x86: msi-laptop: Change DMI match / alias strings to fix module autoloading ...
2022-09-27leds: pca963: fix misleading indentationPavel Machek1-1/+1
I'm getting warnings: /tmp/next/build/drivers/leds/leds-pca963x.c: In function 'pca963x_register_leds': /tmp/next/build/drivers/leds/leds-pca963x.c:355:3: error: this 'if' clause does not guard... +[-Werror=misleading-indentation] 355 | if (hw_blink) | ^~ /tmp/next/build/drivers/leds/leds-pca963x.c:357:4: note: ...this statement, but the latter is +misleadingly indented as if it were guarded by the 'if' 357 | led->blinking = false; | ^~~ cc1: all warnings being treated as errors Fix the indentation to make them go away. Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-09-21leds: pca963x: fix blink with hw accelerationBernardo Rodrigues1-2/+20
LEDs would behave differently depending on the blink hardware acceleration configuration. This commit will make LEDs respond exactly the same independently of the hardware acceleration status. In other words, if you had two pca963x, side by side, one with blink hardware acceleration "ON" and the other "OFF; and performed some arbitrary sequence of API calls (e.g. turn on/off, change brightness, change blink mode, etc.) you probably would end with not matching LED states. 'pca963x software blink' and 'leds-gpio' behavior were used as reference. Actual chip used to validate this change: pca9634 Some of the unmatched behaviors being fixed are (when hw blink was "ON") - Leds would stop blinking when the brightness was changed. - Leds would persist their blinking mode even after being turned off (brightness = 0). - Leds would only blink if another led was solid (pca963x will be forced out of low power) Signed-off-by: Bernardo Rodrigues <bernardocrodrigues@live.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-09-10leds: simatic-ipc-leds-gpio: Make simatic_ipc_led_gpio_table staticHans de Goede1-1/+1
simatic_ipc_led_gpio_table is only used inside simatic-ipc-leds-gpio.c, make it static. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220910085836.84962-1-hdegoede@redhat.com
2022-09-01leds: simatic-ipc-leds-gpio: add new model 227GHenning Schild1-5/+37
This adds support of the Siemens Simatic IPC227G. Its LEDs are connected to GPIO pins provided by the gpio-f7188x module. We make sure that gets loaded, if not enabled in the kernel config no LED support will be available. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Henning Schild <henning.schild@siemens.com> Link: https://lore.kernel.org/r/20220825104422.14156-6-henning.schild@siemens.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-08-16i2c: Make remove callback return voidUwe Kleine-König25-72/+26
The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Crt Mori <cmo@melexis.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/* Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5 Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860 Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-16leds: lm3601x: Improve error reporting for problems during .remove()Uwe Kleine-König1-3/+8
Returning an error value in an i2c remove callback results in a generic error message being emitted by the i2c core, but otherwise it doesn't make a difference. The device goes away anyhow and the devm cleanups are called. So instead of triggering the generic i2c error message, emit a more helpful message if a problem occurs and return 0 to suppress the generic message. This patch is a preparation for making i2c remove callbacks return void. Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-16leds: lm3601x: Don't use mutex after it was destroyedUwe Kleine-König1-2/+0
The mutex might still be in use until the devm cleanup callback devm_led_classdev_flash_release() is called. This only happens some time after lm3601x_remove() completed. Fixes: e63a744871a3 ("leds: lm3601x: Convert class registration to device managed") Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-16leds: lm3697: Remove duplicated error reporting in .remove()Uwe Kleine-König1-3/+1
Returning an error value from an i2c remove callback results in an error message being emitted by the i2c core, but otherwise it doesn't make a difference. The device goes away anyhow and the devm cleanups are called. As lm3697_remove() already emits an error message on failure and the additional error message by the i2c core doesn't add any useful information, don't pass the error value up the stack. Instead continue to clean up and return 0. This patch is a preparation for making i2c remove callbacks return void. Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-08Merge tag 'leds-5.20-rc1' of ↵Linus Torvalds7-198/+675
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds Pull LED updates from Pavel Machek: "A new driver for bcm63138, is31fl319x updates, fixups for multicolor. The clevo-mail driver got disabled, it needs an API fix" * tag 'leds-5.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: (23 commits) leds: is31fl319x: use simple i2c probe function leds: is31fl319x: Fix devm vs. non-devm ordering leds: is31fl319x: Make use of dev_err_probe() leds: is31fl319x: Make use of device properties leds: is31fl319x: Cleanup formatting and dev_dbg calls leds: is31fl319x: Add support for is31fl319{0,1,3} chips leds: is31fl319x: Move chipset-specific values in chipdef struct leds: is31fl319x: Use non-wildcard names for vars, structs and defines leds: is31fl319x: Add missing si-en compatibles dt-bindings: leds: pwm-multicolor: document max-brigthness leds: turris-omnia: convert to use dev_groups leds: leds-bcm63138: get rid of LED_OFF leds: add help info about BCM63138 module name dt-bindings: leds: leds-bcm63138: unify full stops in descriptions dt-bindings: leds: lp50xx: fix LED children names dt-bindings: leds: class-multicolor: reference class directly in multi-led node leds: bcm63138: add support for BCM63138 controller dt-bindings: leds: add Broadcom's BCM63138 controller leds: clevo-mail: Mark as broken pending interface fix leds: pwm-multicolor: Support active-low LEDs ...
2022-08-02leds: is31fl319x: use simple i2c probe functionAndy Shevchenko1-3/+2
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-08-02leds: is31fl319x: Fix devm vs. non-devm orderingAndy Shevchenko1-23/+9
When non-devm resources are allocated they mustn't be followed by devm allocations, otherwise it will break the tear down ordering and might lead to crashes or other bugs during ->remove() stage. Fix this by wrapping mutex_destroy() call with devm_add_action_or_reset(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-08-02leds: is31fl319x: Make use of dev_err_probe()Andy Shevchenko1-20/+13
Simplify the error handling in probe function by switching from dev_err() to dev_err_probe(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-08-02leds: is31fl319x: Make use of device propertiesAndy Shevchenko2-25/+21
Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. Add mod_devicetable.h include. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-08-02leds: is31fl319x: Cleanup formatting and dev_dbg callsVincent Knecht1-13/+9
Fix remaining non-standard place for comments. Remove remaining dev_dbg after regmap_read in is31fl3196_brightness_set. Remove __func__ in dev_dbg calls, instead adding "channel" string to describe the first displayed value. Change remaining container_of() call to be on one line, as well as a few others. Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-18 21:06:37 +0300