linux-stable.git/drivers/leds, branch v4.19.321 Linux kernel stable tree leds: ss4200: Convert PCIBIOS_* return codes to errnos 2024-08-19T03:32:04+00:00 Ilpo Järvinen ilpo.jarvinen@linux.intel.com 2024-05-27T13:27:00+00:00 db1871789f3018c5b0788318d3b1c685f2decceb 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> 
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>
leds: trigger: Unregister sysfs attributes before calling deactivate() 2024-08-19T03:31:59+00:00 Hans de Goede hdegoede@redhat.com 2024-05-04T16:25:33+00:00 c3b7a650c8717aa89df318364609c86cbc040156 [ 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> 
[ 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>
leds: trigger: panic: Don't register panic notifier if creating the trigger failed 2024-02-23T07:12:50+00:00 Heiner Kallweit hkallweit1@gmail.com 2023-12-16T20:05:33+00:00 6c0a90374357d7bc3fde5fc096ae996699e4eb22 [ 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> 
[ 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>
leds: trigger: ledtrig-cpu:: Fix 'output may be truncated' issue for 'cpu' 2023-11-20T09:29:19+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2023-09-23T07:15:38+00:00 ca26b08cea279e059905a8cacb53ed175ca97457 [ 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> 
[ 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>
ledtrig-cpu: Limit to 8 CPUs 2023-11-20T09:29:19+00:00 Pavel Machek pavel@ucw.cz 2020-09-19T09:34:58+00:00 a45330a18492027033000964021102d843bfd62e [ Upstream commit abcc131292aa8c7de2c5f0ed76a717436c21de63 ] Some machines have thousands of CPUs... and trigger mechanisms was not really meant for thousands of triggers. I doubt anyone uses this trigger on many-CPU machine; but if they do, they'll need to do it properly. Signed-off-by: Pavel Machek <pavel@ucw.cz> Stable-dep-of: ff50f5327613 ("leds: trigger: ledtrig-cpu:: Fix 'output may be truncated' issue for 'cpu'") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit abcc131292aa8c7de2c5f0ed76a717436c21de63 ]

Some machines have thousands of CPUs... and trigger mechanisms was not
really meant for thousands of triggers. I doubt anyone uses this
trigger on many-CPU machine; but if they do, they'll need to do it
properly.

Signed-off-by: Pavel Machek <pavel@ucw.cz>
Stable-dep-of: ff50f5327613 ("leds: trigger: ledtrig-cpu:: Fix 'output may be truncated' issue for 'cpu'")
Signed-off-by: Sasha Levin <sashal@kernel.org>
leds: pwm: Don't disable the PWM when the LED should be off 2023-11-20T09:29:19+00:00 Uwe Kleine-König u.kleine-koenig@pengutronix.de 2023-09-22T19:28:34+00:00 62af7d4d703dc7f89e7e10b3cded5f893351c6cb [ 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> 
[ 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>
leds: pwm: convert to atomic PWM API 2023-11-20T09:29:19+00:00 Uwe Kleine-König uwe@kleine-koenig.org 2020-01-24T16:54:08+00:00 11e92d6b0e50aeeabf8233869e46450e8cc02890 [ Upstream commit dd47a83453e4a5b0d6a91fe702b7fbc1984fb610 ] pwm_config(), pwm_enable() and pwm_disable() should get removed in the long run. So update the driver to use the atomic API that is here to stay. A few side effects: - led_pwm_set() now returns an error when setting the PWM fails. - During .probe() the PWM isn't disabled implicitly by pwm_apply_args() any more. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Tested-by: Jeff LaBundy <jeff@labundy.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> Stable-dep-of: 76fe464c8e64 ("leds: pwm: Don't disable the PWM when the LED should be off") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit dd47a83453e4a5b0d6a91fe702b7fbc1984fb610 ]

pwm_config(), pwm_enable() and pwm_disable() should get removed in the
long run. So update the driver to use the atomic API that is here to
stay.

A few side effects:

 - led_pwm_set() now returns an error when setting the PWM fails.
 - During .probe() the PWM isn't disabled implicitly by pwm_apply_args()
   any more.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Tested-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Stable-dep-of: 76fe464c8e64 ("leds: pwm: Don't disable the PWM when the LED should be off")
Signed-off-by: Sasha Levin <sashal@kernel.org>
leds: pwm: simplify if condition 2023-11-20T09:29:19+00:00 Uwe Kleine-König uwe@kleine-koenig.org 2020-01-24T16:54:07+00:00 088c51a1067753ac74e3f1e1088863adaf99045c [ Upstream commit b43a8f01fccbfdddbc7f9b2bbad11b7db3fda4e1 ] .pwm_period_ns is an unsigned integer. So when led->pwm_period_ns > 0 is false, we now assign 0 to a value that is already 0, so it doesn't hurt and we can skip checking the actual value. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Tested-by: Jeff LaBundy <jeff@labundy.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> Stable-dep-of: 76fe464c8e64 ("leds: pwm: Don't disable the PWM when the LED should be off") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit b43a8f01fccbfdddbc7f9b2bbad11b7db3fda4e1 ]

.pwm_period_ns is an unsigned integer. So when led->pwm_period_ns > 0
is false, we now assign 0 to a value that is already 0, so it doesn't
hurt and we can skip checking the actual value.

Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Tested-by: Jeff LaBundy <jeff@labundy.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Stable-dep-of: 76fe464c8e64 ("leds: pwm: Don't disable the PWM when the LED should be off")
Signed-off-by: Sasha Levin <sashal@kernel.org>
leds: ktd2692: Fix an error handling path 2021-07-20T14:15:57+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2021-05-21T11:21:01+00:00 09f064fcadc7dad2ffc69232d58c8a29b2e5e430 [ Upstream commit ee78b9360e14c276f5ceaa4a0d06f790f04ccdad ] In 'ktd2692_parse_dt()', if an error occurs after a successful 'regulator_enable()' call, we should call 'regulator_enable()'. This is the same in 'ktd2692_probe()', if an error occurs after a successful 'ktd2692_parse_dt()' call. Instead of adding 'regulator_enable()' in several places, implement a resource managed solution and simplify the remove function accordingly. Fixes: b7da8c5c725c ("leds: Add ktd2692 flash LED driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ee78b9360e14c276f5ceaa4a0d06f790f04ccdad ]

In 'ktd2692_parse_dt()', if an error occurs after a successful
'regulator_enable()' call, we should call 'regulator_enable()'.

This is the same in 'ktd2692_probe()', if an error occurs after a
successful 'ktd2692_parse_dt()' call.

Instead of adding 'regulator_enable()' in several places, implement a
resource managed solution and simplify the remove function accordingly.

Fixes: b7da8c5c725c ("leds: Add ktd2692 flash LED driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
leds: as3645a: Fix error return code in as3645a_parse_node() 2021-07-20T14:15:57+00:00 Zhen Lei thunder.leizhen@huawei.com 2021-05-15T03:06:46+00:00 21da01972675769d2908652e7785f5ce20254a7a [ Upstream commit 96a30960a2c5246c8ffebe8a3c9031f9df094d97 ] Return error code -ENODEV rather than '0' when the indicator node can not be found. Fixes: a56ba8fbcb55 ("media: leds: as3645a: Add LED flash class driver") Reported-by: Hulk Robot <hulkci@huawei.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 96a30960a2c5246c8ffebe8a3c9031f9df094d97 ]

Return error code -ENODEV rather than '0' when the indicator node can not
be found.

Fixes: a56ba8fbcb55 ("media: leds: as3645a: Add LED flash class driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>