On Fri, Feb 26, 2021 at 12:57:37PM +0200, Andy Shevchenko wrote:

On Fri, Feb 26, 2021 at 11:39 AM Shawn Guo [off-list ref] wrote:

quoted

On Fri, Feb 26, 2021 at 11:12:07AM +0200, Andy Shevchenko wrote:

quoted

On Fri, Feb 26, 2021 at 5:42 AM Shawn Guo [off-list ref] wrote:

quoted

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.

quoted

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

quoted

And as Mika said once to one of mine patches "since you know the
number ahead there is no need to pollute GPIO ACPI library core with
this quirk". But in any case I would like to see the ACPI tables
first.

Oh, so you had something similar already?  Could you point me to the
patch and discussion?

Similar, but might be not the same:
 - patches in the upstream [1] (v3 applied), discussion [2]
 - new version with some additional fixes [3]

Thanks for all the pointers.  It looks to me that it's the same problem
- the GPIO number in ACPI table is broken and needs an override from
kernel.  So I think what we need is a generic solution to a problem
not uncommon.  Rather than asking all different drivers to resolve the
same problem all over the kernel, I believe GPIO ACPI library is just
the right place.

Looking at your platform and problem, I realise that to be a generic
solution, my patch needs an additional device identification matching,
as one GPIO number that is broken for one device could be correct for
another.  I will improve it, so that your problem can be resolved by
simply adding a new entry to acpi_gpio_pin_override_table[].

Shawn