On Fri, Feb 26, 2021 at 12:57:37PM +0200, Andy Shevchenko wrote: > On Fri, Feb 26, 2021 at 11:39 AM Shawn Guo <shawn.guo@xxxxxxxxxx> wrote: > > On Fri, Feb 26, 2021 at 11:12:07AM +0200, Andy Shevchenko wrote: > > > On Fri, Feb 26, 2021 at 5:42 AM Shawn Guo <shawn.guo@xxxxxxxxxx> 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. > > > > > > Thanks for the report and patch. > > > > > > First of all, have you reported the issue to Lenovo? At least they > > > will know that they did wrong. > > > > Yes, we are reporting this to Lenovo, but to be honest, we are not sure > > how much they will care about it, as they are shipping the laptop with > > Windows only. > > > > > Second, is it possible to have somewhere output of `acpidump -o > > > flex5g.dat` (the flex5g.dat file)? > > > > https://raw.githubusercontent.com/aarch64-laptops/build/master/misc/lenovo-flex-5g/dsdt.dsl Looking into DSDT I think the problem is much worse. First of all there are many cases where pins like 0x140, 0x1c0, etc are being used. On top of that there is no GPIO driver in the upstream (as far as I can see by HID, perhaps there is a driver but for different HID. And I see that GPIO device consumes a lot of Interrupts from GIC as well (it's ARM platfrom as far as I understand). Looking at the Microsoft brain damaged way of understanding GPIOs and hardware [1], I am afraid you really want to have a specific GPIO driver for this. So, for now until we have better picture of what's going on, NAK to this patch. [1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/general-purpose-i-o--gpio- "...All banks have the same number of pins, except for the last bank, which might have fewer." They added completely unnecessary mapping layer and brought a lot of confusion to everybody (developers, users, etc). -- With Best Regards, Andy Shevchenko
