Hi, On 11/21/23 10:52, Takashi Iwai wrote: > On Tue, 21 Nov 2023 10:19:03 +0100, > Thorsten Leemhuis wrote: >> >> Takashi, Jean-Jacques Hiblot, Lee, >> >> On 20.11.23 14:53, Takashi Iwai wrote: >>> On Mon, 06 Nov 2023 14:19:08 +0100, >>> Bagas Sanjaya wrote: >>>> On Sat, Nov 04, 2023 at 01:01:56PM +0100, Jean-Jacques Hiblot wrote: >>>>> On 29/10/2023 02:48, Bagas Sanjaya wrote: >>>>>> On Thu, Oct 26, 2023 at 02:55:06PM +0700, Bagas Sanjaya wrote: >>>>>>> The culprit seems to be commit c7d80059b086c4986cd994a1973ec7a5d75f8eea, which introduces a new 'color' attribute for led sysfs class devices. The problem is that the system76-acpi platform driver tries to create the exact same sysfs attribute itself for the system76_acpi::kbd_backlight device, leading to the conflict. For testing purposes, I've just rebuilt the kernel with the system76-apci color attribute renamed to kb_color, and that fixes the issue. >>>>>> >>>>>> Jean-Jacques Hiblot, would you like to take a look on this regression, >>>>>> since you authored the culprit? >>> >>>>> The offending commit stores the color in struct led_classdev and exposes it >>>>> via sysfs. It was part of a series that create a RGB leds from multiple >>>>> single-color LEDs. for this series, we need the color information but we >>>>> don't really need to expose it it via sysfs. In order to fix the issue, we >>>>> can remove the 'color' attribute from the sysfs. >>>> >>>> OK, see you in the patch! >>> >>> Is there a patch available? >> >> Not that I know of. Could not find anything on lore either. >> >>> This bug hits for a few Logitech keyboard models, too, and it makes >>> 6.6 kernel unsable for them, as hid-lg-g15 driver probe fails due to >>> this bug: >>> https://bugzilla.kernel.org/show_bug.cgi?id=218155 >>> >>> We need a quick fix for 6.6.x. >> >> Given that Jean-Jacques Hiblot (the author of the culprit) and Lee (who >> committed it and sent it to Linus) know about this for a while already >> without doing anything about it, I wonder if someone should just send a >> revert to Linus (unless of course that is likely to introduce a >> regression on its own). >> >> Takashi, could you maybe do this, unless a fix shows up real soon? > > I can, but we need to decide which way to go. > There are several options: > > 1. Revert the commit c7d80059b086; > this drops led class color sysfs entries. Also the store of > led_cdev->color from fwnode is dropped, too. > > 2. Drop only led class color sysfs entries; > a partial revert of c7d80059b086 above AFAIK further up in the thread (or a related thread) there already was consensus to do this. Someone just needs to write the patch. > 3. Rename conflicting sysfs entries in drivers; > e.g. color -> kb_color for hid-lg-g15 and system76_acpi > > In either way, we'd break user-space (sysfs). The new color attribute causing the conflict has only been in 6.6 so there likely aren't any users of it yet and since dropping it would be backported to 6.6.y there shouldn't be any future users of it either, since any 6.6 users presumably will use 6.6.y and not 6.6.0 > IMO, 2 would be the least harm, as the class sysfs entry was > introduced since 6.6. Ack. > I guess this is what Jean-Jacques suggested. Right. > But I'm not sure how important this new class sysfs entry is; it has > to be clarified from leds people who actually use / wanted the > feature. If I have read the thread correctly it is not important the value it represents is used internally in the LED subsystem and userspace does not really need it. Regards, Hans
