Re: i2c designware change broke touchpad of a thinkpad (was: i2c: designware: defer probe if child GpioInt controllers are not bound)

On Sat, Aug 08, 2026 at 10:31:28PM +0530, Hardik Prakash wrote:
> On Fri, 7 Aug 2026, Thorsten Leemhuis wrote:
> > This became 0a4bb2abc3e56d ("i2c: designware: defer probe if child
> > GpioInt controllers are not bound") and causes a regression for me: the
> > Touchpad in my ThinkPad T14s Gen 4 (AMD) stopped working. From the
> > kernel log:
> >
> > i2c_designware AMDI0010:01: i2c_dw_handle_tx_abort: lost arbitration
> > i2c_designware AMDI0010:01: controller timed out
> > i2c_hid_acpi i2c-SYNA8018:00: failed to fetch HID descriptor: -110
> > i2c_hid_acpi i2c-SYNA8018:00: Failed to fetch the HID Descriptor
> >
> > Reverting this change in current mainline/master (f9a2394a23482) fixed
> > things for me. Full dmesg of current master and master+revert can be
> > found here:
> >
> > https://www.leemhuis.info/files/misc/dmesg-master
> > https://www.leemhuis.info/files/misc/dmesg-master-plus_revert
> 
> Thanks for the report and both dmesg dumps, that's very helpful. Comparing
> the two: the working log shows SYNA8018:00 probing cleanly around 2.33s
> with no GPIO-related activity, while the broken log hits lost arbitration
> on AMDI0010:01 at almost the same timestamp. Neither log has dynamic debug
> enabled for the relevant code paths, so I can't yet tell what my dependency
> check actually decided for AMDI0010:01's children on your machine.
> 
> Two things that would help narrow this down, whenever you have a moment:
> 
> 1. A DSDT dump, to see what GpioInt resource (if any) AMDI0010:01's
>    children declare, and what it points to:
> 
>    sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat
>    iasl -d dsdt.dat

Side note: It is better to collect with `acpidump -o tables.dat`, then
`acpixtract tables.dat` followed by `iasl -d dsdt.dat`

>    The resulting dsdt.dsl, or just the section under AMDI0010:01, should
>    help.
> 
> 2. A dmesg with dynamic debug from a kernel built with the attached
>    patch on top of current mainline/master (adds pr_info() tracing to
>    the exact decision path, no functional changes):
> 
>    dmesg | grep i2c-dw-gpio-dbg
> 
> Both together should tell us whether the dependency check is finding a
> GpioInt resource on your hardware and mishandling it, or whether
> something else is going on. Appreciate you taking the time.

> On Fri, 7 Aug 2026 at 19:37, Thorsten Leemhuis <[email protected]> wrote:
> > On 7/28/26 10:30, Andi Shyti wrote:
> > > On Sat, Jul 18, 2026 at 11:13:31AM +0530, Hardik Prakash wrote:
> > >> I2C controllers may have child devices with GpioInt resources that
> > >> depend on GPIO controllers being fully initialized. If the I2C
> > >> controller probes and enumerates children before the referenced GPIO
> > >> controller has completed probe, GPIO interrupts may not be properly
> > >> configured, leading to device failures.
> > >>
> > >> On Lenovo Yoga 7 14AGP11, the WACF2200 touchscreen (child of
> > >> AMDI0010:02) has a GpioInt resource pointing to GPIO 157 on the
> > >> pinctrl-amd controller (AMDI0030:00). When i2c-designware probes
> > >> AMDI0010:02 before pinctrl-amd finishes initializing, I2C transactions
> > >> fail with lost arbitration errors:
> > >>
> > >>   0.285952  amd_gpio_probe: registering gpiochip  <- GPIO chip visible
> > >>   0.287121  amd_gpio_probe: requesting parent IRQ <- probe still running
> > >>   0.301454  AMDI0010:02 dw_i2c_plat_probe: start  <- races here
> > >>   2.348157  lost arbitration
> > >>
> > >> Add a dependency check that walks ACPI child devices and defers probe
> > >> until any referenced GPIO controller is bound.

[...]

> > #regzbot introduced: 0a4bb2abc3e56d
> > #regzbot title i2c: designware: ThinkPad touchpad broke

-- 
With Best Regards,
Andy Shevchenko