Hi, On 10/19/20 5:44 PM, Enrico Weigelt, metux IT consult wrote: > 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. Ack and that is how things should be done. > This will be defeated > as soon as the whole thing becomes board/bios specific again. I hear you, but if newer BIOS versions all of a sudden start declaring their own stuff, then we need to come up with some solution here... Not sure what that solution should be though. Regards, Hans
