On Thu, Mar 04, 2021 at 08:32:14PM +0100, Hans de Goede wrote: > Hi, > > On 3/3/21 10:47 AM, Andy Shevchenko wrote: > > On Fri, Feb 26, 2021 at 11:39:19AM +0800, Shawn Guo wrote: > >> Running kernel with ACPI on Lenovo Flex 5G laptop, touchpad is just > >> not working. That's because the GpioInt number of TSC2 node in ACPI > >> table is simply wrong, and the number even exceeds the maximum GPIO > >> lines. As the touchpad works fine with Windows on the same machine, > >> presumably this is something Windows-ism. Although it's obviously > >> a specification violation, believe of that Microsoft will fix this in > >> the near future is not really realistic. > >> > >> It adds the support of overriding broken GPIO number in ACPI table > >> on particular machines, which are matched using DMI info. Such > >> mechanism for fixing up broken firmware and ACPI table is not uncommon > >> in kernel. And hopefully it can be useful for other machines that get > >> broken GPIO number coded in ACPI table. > > > > > > +Cc: Hans. > > > > Hans, would appreciate your opinion on this thread. Maybe I'm mistaken in my > > conclusions. > > So I've read the entire thread here: > https://lore.kernel.org/linux-gpio/20210226033919.8871-1-shawn.guo@xxxxxxxxxx/T/#u > > And I agree wih Andy, this is not something which should be fixed up in the > generic gpiolib-acpi code. > > Note that we have similar things going on on x86 platforms. There are cases > there where there are e.g. holes in the GPIO ranges advertised by the Intel > pinctrl drivers. And in the beginning as i2c (and thus GpioIRQ) HID devices > started to become more common there were also several rounds of work to make > sure that the GPIO numbering (per ACPI-device / island) exported to the rest > of the kernel (and thus to gpiolib-acpi) matched with the numbering which > the ACPI tables expected (so the numbering which the Windows driver use). > > It seems to me, esp. in the light that there are a lot of "crazy high" GPIO > indexes in the DSDT of the Lenovo Flex 5G, that the right thing to do here > is to fix the qualcom pinctrl/GPIO driver to number its GPIOs in the way > expected by these ACPI tables. This will break use of existing devicetrees, > so it will likely need to detect if the main firmware of the system is ACPI > or DT based and then use 2 different numbering schemes depending on the > outcome of that check. > > Please also do not try ti fix this with some quirks in e.g. the i2c-hid driver, > I will definitely NACK such attempts. From what we can see now any fix clearly > should be done inside the qualcom GPIO driver. Hans, thank you very much! -- With Best Regards, Andy Shevchenko
