Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD

[Sébastien Chaumat <euidzero@xxxxxxxxx>]

found the following issue with this similar HW setup :

https://marc.info/?l=linux-gpio&m=150605230614677&w=2

while in bare metal, I wonder if being in dom0 does not lead to the same configuration :

Quoting :
---
"Under the I2C-HID spec, the device interrupt is level-triggered. When
the touchpad has data to report, it will bring the GPIO level low
(this is active-low), which should signal the host to read input
report data. The device will hold the GPIO low until there is no more
data that needs to be delivered.

The user-visible problem is that the touchpad appears to stop
responding after a short period of usage. At the i2c-hid driver level,
no more interrupts are arriving. We have checked with a scope that the
interrupt line is being held low at this point, which should mean that
the interrupt handler should be executed again since there is more
data to be read, but that is not happening here.

An easy way to reproduce this issue is to press multiple fingers on
the touchpad, which will result in a large amount of input data to be
queued up on the device side; however the interrupt handler will soon
stop firing so not all the data will be read, and everything stops
there...

"

^

 in my case the interrupt handler stop after one trigger.

"We observed that at the point where no more interrupts arrive, no
EOI_MASK write was sent at the point when i2c_irq_hid returned for the
last time (and is never called again). We found a potential solution
to this problem: by adding the IRQCHIP_EOI_THREADED flag, an EOI will
be sent at this point, and we are now unable to get the touchpad to

hang."

---

Sébastien