On 14.10.20 10:41, Hans de Goede wrote: Hi, > Keep the current LED/gpio setup code, but make executing it conditional > on the BIOS version and skip the LED/gpio setup when the new BIOS is > present to avoid having duplicate LED entries, etc. in that case. > > I guess this would still break userspace because if I understand things > correctly the new ACPI based setup uses different LED names ? That > seems unfortunate, but I guess that from the kernel pov we can just > blame the BIOS for this, and since we definitely do not want duplicate > LED entries for the same LED, this seems the least bad choice. Sorry, but not fine. When a newer box is taken from storage into production (eg. replacement or new installation), application breaks. LED isn't the only problem, also affects buttons. The whole reaons why I invested all the time for writing general purpose drivers (fch-gpio is separate from board driver) and bringing it to mainline was having clean and generic support for these boards, instead of having to carry around special patch queues forever and in near future just using stock distro kernel. I guess that's the main reason for very most mainlined drivers. This will be defeated as soon as the whole thing becomes board/bios specific again. I purposely slept ofter the naming several times, to make sure it's future proof and tells exactly what these leds are for. Otherwise I could just have picked numbers and fruits. Please don't change the names. Field relies on them. Actually, I've already considered adding another workaround for removing the ACPI gpio/leds. Haven't had the time for a close analysis the acpi bytecode actually does, and what the kernel actually makes out of it. As soon as I encounter an conflict (eg. locks the iomem from gpio-amd fch, messes up gpio states, etc), I'll have to go that route. There already have been bug reports in that direction (eg. simsw and reset issues), which I could not yet reproduce (on the older bios versions). --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
