Re: i2c designware change broke touchpad of a thinkpad

On 8/10/26 07:54, Hardik Prakash wrote:
> On Sun, 9 Aug 2026, Thorsten Leemhuis wrote:
>> Sorry, picked the wrong file while preparing the mail, it's here:
>> https://www.leemhuis.info/files/misc/dmesg_patch_dyndbg
> 
> Thanks, that's the one. Full timeline from that boot:
> 
>   0.619s  AMDI0010:00 and AMDI0010:01 defer (AMDI0030:00 not registered)
>   1.136s  Retry succeeds: device_is_bound()=true for AMDI0030:00,
>           confirmed for all three children (XXXX0000:00, SYNA8018:00,
>           NXP1001:00)
>   2.222s  lost arbitration on AMDI0010:01 (x3)
>   3.260s  controller timed out, HID descriptor fetch fails
> 
> The dependency check itself is behaving correctly here -- it defers,
> then correctly confirms AMDI0030:00 is bound before letting probe
> continue. The arbitration failure happens over a second *after* that,
> when the touchpad attempts its actual first transaction.
> 
> So this doesn't look like a logic bug in the check itself. My read: by
> delaying dw_i2c_plat_probe() by ~500ms (correctly, for GPIO's sake),
> something else ends up contending for the AMDI0010:01 bus by the time
> the touchpad's first transaction actually happens -- a window that
> the original (undeferred, earlier) probe attempt apparently avoided.
> 
> Mario -- does this look like a known AMD I2C/PSP semaphore contention
> pattern to you? Wondering if there's a shared bus/firmware consumer
> that could explain a ~1s-later collision like this, independent of
> the GPIO controller itself being ready.
> 
> Thorsten, if you have it handy: /proc/interrupts and lsmod from this
> boot would help narrow down what else might be touching that bus
> around the 2.2s mark.

Did a fresh boot and uploaded the dmesg again as well just in case:

https://www.leemhuis.info/files/misc/dmesg_patch_dyndbg2
https://www.leemhuis.info/files/misc/lsmod
https://www.leemhuis.info/files/misc/interrupts

Ciao, Thorsten
> On Mon, 10 Aug 2026 at 11:06, Thorsten Leemhuis <[email protected]> wrote:
>>
>> On 8/10/26 07:23, Hardik Prakash wrote:
>>> On Sat, 8 Aug 2026, Thorsten Leemhuis wrote:
>>>> https://www.leemhuis.info/files/misc/dmesg-master-plus_revert
>>>>
>>>> [    0.619018] i2c-dw-gpio-dbg: i2c_dw_check_gpio_dependencies(AMDI0010:00)
>>>> [...]
>>>> [    1.136010] i2c-dw-gpio-dbg: device_is_bound()=true for AMDI0030:00
>>>
>>> Thanks, this trace looks correct on its face (defer at 0.619s, retry
>>> succeeds at 1.122-1.136s), but the link above points to the same file
>>> you sent last round (the master+revert baseline, no debug patch, no
>>> i2c-dw-gpio-dbg lines in it at all) rather than this new capture.
>>>> Could you share the full, unfiltered dmesg from this exact boot (the
>>> one with the debug patch applied)? I need to see where
>>> "lost arbitration" falls relative to the trace above.
>>
>> Sorry, picked the wrong file while preparing the mail, it's here:
>> https://www.leemhuis.info/files/misc/dmesg_patch_dyndbg
>>
>> Ciao, Thorsten
>>
>>> Separately, from your DSDT: NFC1 (NXP1001), which shows up as a child
>>> of AMDI0010:01 in your trace, declares its _CRS as a raw resource
>>> buffer containing three GPIO resources referencing \_SB.GPIO -- one
>>> GpioIo and two separate GpioInt entries. Not sure yet if that's
>>> relevant, but it's a pattern I haven't seen on my hardware
>>> which I've tested against.
>>>
>>> Thanks,
>>> Hardik
>>>
>>> On Sun, 9 Aug 2026 at 21:49, Thorsten Leemhuis <[email protected]> wrote:
>>>>
>>>> On 8/8/26 22:25, Andy Shevchenko wrote:
>>>>> 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
>>>>>> [...]
>>>>>> Two things that would help narrow this down, whenever you have a moment:
>>>>
>>>> Thx for looking into this. Here we go:
>>>>
>>>>>> 1. A DSDT dump
>>>>
>>>> https://www.leemhuis.info/files/misc/dsdt.dsl
>>>>
>>>>>> 2. A dmesg with dynamic debug from a kernel built with the attached
>>>>>>    patch on top of current mainline/master
>>>>
>>>> https://www.leemhuis.info/files/misc/dmesg-master-plus_revert
>>>>
>>>> [    0.619018] i2c-dw-gpio-dbg: i2c_dw_check_gpio_dependencies(AMDI0010:00)
>>>> [    0.619018] i2c-dw-gpio-dbg: check_child_gpioint(adev=XXXX0000:00)
>>>> [    0.619076] i2c-dw-gpio-dbg: GpioInt resource_source=\_SB.GPIO (len=10)
>>>> [    0.619079] i2c-dw-gpio-dbg: acpi_fetch_acpi_dev() succeeded,
>>>> device=AMDI0030:00
>>>> [    0.619080] i2c-dw-gpio-dbg: gpio_device_find_by_fwnode() returned
>>>> NULL, deferring
>>>> [    0.619082] i2c-dw-gpio-dbg: check_child_gpioint ret=-517 (defer)
>>>> [    0.619102] i2c-dw-gpio-dbg: i2c_dw_check_gpio_dependencies(AMDI0010:01)
>>>> [    0.619104] i2c-dw-gpio-dbg: check_child_gpioint(adev=SYNA8018:00)
>>>> [    0.619159] i2c-dw-gpio-dbg: GpioInt resource_source=\_SB.GPIO (len=10)
>>>> [    0.619162] i2c-dw-gpio-dbg: acpi_fetch_acpi_dev() succeeded,
>>>> device=AMDI0030:00
>>>> [    0.619162] i2c-dw-gpio-dbg: gpio_device_find_by_fwnode() returned
>>>> NULL, deferring
>>>> [    0.619164] i2c-dw-gpio-dbg: check_child_gpioint ret=-517 (defer)
>>>> [    1.122517] i2c-dw-gpio-dbg: i2c_dw_check_gpio_dependencies(AMDI0010:00)
>>>> [    1.122523] i2c-dw-gpio-dbg: check_child_gpioint(adev=XXXX0000:00)
>>>> [    1.122625] i2c-dw-gpio-dbg: GpioInt resource_source=\_SB.GPIO (len=10)
>>>> [    1.122636] i2c-dw-gpio-dbg: acpi_fetch_acpi_dev() succeeded,
>>>> device=AMDI0030:00
>>>> [    1.122639] i2c-dw-gpio-dbg: gpio_device_find_by_fwnode() succeeded
>>>> [    1.122642] i2c-dw-gpio-dbg: device_is_bound()=true for AMDI0030:00
>>>> [    1.135894] i2c-dw-gpio-dbg: i2c_dw_check_gpio_dependencies(AMDI0010:01)
>>>> [    1.135898] i2c-dw-gpio-dbg: check_child_gpioint(adev=SYNA8018:00)
>>>> [    1.135976] i2c-dw-gpio-dbg: GpioInt resource_source=\_SB.GPIO (len=10)
>>>> [    1.135980] i2c-dw-gpio-dbg: acpi_fetch_acpi_dev() succeeded,
>>>> device=AMDI0030:00
>>>> [    1.135983] i2c-dw-gpio-dbg: gpio_device_find_by_fwnode() succeeded
>>>> [    1.135985] i2c-dw-gpio-dbg: device_is_bound()=true for AMDI0030:00
>>>> [    1.135987] i2c-dw-gpio-dbg: check_child_gpioint(adev=NXP1001:00)
>>>> [    1.136005] i2c-dw-gpio-dbg: GpioInt resource_source=\_SB.GPIO (len=10)
>>>> [    1.136008] i2c-dw-gpio-dbg: acpi_fetch_acpi_dev() succeeded,
>>>> device=AMDI0030:00
>>>> [    1.136009] i2c-dw-gpio-dbg: gpio_device_find_by_fwnode() succeeded
>>>> [    1.136010] i2c-dw-gpio-dbg: device_is_bound()=true for AMDI0030:00
>>>>
>>>> HTH, Ciao, Thorsten
>>>>
>>>>>> 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
>>>>>
>>>>
>>>
>>
>