kernel.git/drivers/leds/led-class.c, branch linux-6.10.y

Revert "leds: led-core: Fix refcount leak in of_led_get()"

2024-08-03T07:00:01Z

[ 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 Signed-off-by: Hervé Codina Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240625-led-class-device-leak-v2-1-75fdccf47421@bootlin.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

leds: class: Revert: "If no default trigger is given, make hw_control trigger the default trigger"

2024-06-16T16:33:28Z

Commit 66601a29bb23 ("leds: class: If no default trigger is given, make hw_control trigger the default trigger") causes ledtrig-netdev to get set as default trigger on various network LEDs. This causes users to hit a pre-existing AB-BA deadlock issue in ledtrig-netdev between the LED-trigger locks and the rtnl mutex, resulting in hung tasks in kernels >= 6.9. Solving the deadlock is non trivial, so for now revert the change to set the hw_control trigger as default trigger, so that ledtrig-netdev no longer gets activated automatically for various network LEDs. The netdev trigger is not needed because the network LEDs are usually under hw-control and the netdev trigger tries to leave things that way so setting it as the active trigger for the LED class device is a no-op. Fixes: 66601a29bb23 ("leds: class: If no default trigger is given, make hw_control trigger the default trigger") Reported-by: Genes Lists Closes: https://lore.kernel.org/all/9d189ec329cfe68ed68699f314e191a10d4b5eda.camel@sapience.com/ Reported-by: Johannes Wüller Closes: https://lore.kernel.org/lkml/e441605c-eaf2-4c2d-872b-d8e541f4cf60@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Reviewed-by: Andrew Lunn Acked-by: Lee Jones Signed-off-by: Linus Torvalds

leds: class: If no default trigger is given, make hw_control trigger the default trigger

2024-03-07T08:47:56Z

If a hw_control_trigger is defined, it's usually desirable to make it the default trigger. Therefore make it the default trigger, except the driver explicitly set a default trigger. Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/f33543de-3800-488f-a779-1fa282614462@gmail.com Signed-off-by: Lee Jones

leds: class: Don't expose color sysfs entry

2023-11-22T11:46:03Z

The commit c7d80059b086 ("leds: class: Store the color index in struct led_classdev") introduced a new sysfs entry "color" that is commonly created for the led classdev. Unfortunately, this conflicts with the "color" sysfs entry of already existing drivers such as Logitech HID or System76 ACPI drivers. The driver probe fails due to the conflict, hence it leads to a severe regression with the missing keyboard, for example. This patch reverts partially the change in the commit above for removing the led class color sysfs entries again for addressing the regressions. The newly introduced led_classdev.color field is kept as it's already used by other driver. Fixes: c7d80059b086 ("leds: class: Store the color index in struct led_classdev") Reported-by: Johannes Penßel Closes: https://lore.kernel.org/r/b5646db3-acff-45aa-baef-df3f660486fb@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=218045 Link: https://bugzilla.kernel.org/show_bug.cgi?id=218155 Link: https://bugzilla.suse.com/show_bug.cgi?id=1217172 Signed-off-by: Takashi Iwai Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20231121162359.9332-1-tiwai@suse.de Signed-off-by: Lee Jones

leds: Make leds_class a static const structure

2023-08-18T07:43:11Z

Now that the driver core allows for struct class to be in read-only memory, move the leds_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by: Greg Kroah-Hartman Signed-off-by: Ivan Orlov Link: https://lore.kernel.org/r/20230810174905.7997-1-ivan.orlov0322@gmail.com Signed-off-by: Lee Jones

leds: class: Store the color index in struct led_classdev

2023-08-17T08:00:34Z

Store the color of the LED so that it is not lost after the LED's name has been composed. This color information can then be exposed to the user space or used by the LED consumer. Signed-off-by: Jean-Jacques Hiblot Link: https://lore.kernel.org/r/20230728153731.3742339-3-jjhiblot@traphandler.com Signed-off-by: Lee Jones

leds: Provide devm_of_led_get_optional()

2023-08-17T08:00:06Z

Add an optional variant of devm_of_led_get(). It behaves the same as devm_of_led_get() except where the LED doesn't exist. In this case, instead of returning -ENOENT, the function returns NULL. Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230728153731.3742339-2-jjhiblot@traphandler.com Signed-off-by: Lee Jones

led: led-class: Read max-brightness from devicetree

2023-07-28T08:26:22Z

Normally, the maximum brightness is determined by the hardware, and this property is not required. This property is used to set a software limit. It could happen that an LED is made so bright that it gets damaged or causes damage due to restrictions in a specific system, such as mounting conditions. Note that this flag is mainly used for PWM-LEDs, where it is not possible to map brightness to current. Drivers for other controllers should use led-max-microamp. Reviewed-by: Andy Shevchenko Signed-off-by: Astrid Rost Acked-by: Jacek Anaszewski Link: https://lore.kernel.org/r/20230703130313.548519-3-astrid.rost@axis.com Signed-off-by: Lee Jones

leds: Replace all non-returning strlcpy with strscpy

2023-05-25T11:31:55Z

strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89 Signed-off-by: Azeem Shaikh Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20230523021451.2406362-1-azeemshaikh38@gmail.com Signed-off-by: Lee Jones

driver core: class: remove module * from class_create()

2023-03-17T14:16:33Z

The module pointer in class_create() never actually did anything, and it shouldn't have been requred to be set as a parameter even if it did something. So just remove it and fix up all callers of the function in the kernel tree at the same time. Cc: "Rafael J. Wysocki" Acked-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman