[PATCH v13] i2c: designware: defer probe if child GpioInt controllers are not bound

[PATCH v13] i2c: designware: defer probe if child GpioInt controllers are not bound

[Hardik Prakash]

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.

Fixes: 3812a9e84265 ("pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11")
Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
Assisted-by: Claude:claude-sonnet-5
Assisted-by: DeepSeek:deepseek-v4-pro
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
---
v12 -> v13:
- v12 was sent as an incomplete diff (generated against v11 rather than
  against current master due to a git format-patch invocation mistake on
  my end), not a real standalone patch (Andy Shevchenko)
- Not carrying forward Bartosz Golaszewski's v12 Acked-by, per Andy's
  request
- Add blank line before guard(device)(gpio_dev) for readability (Andy
  Shevchenko)
- No other functional code changes since v12

v11 -> v12:
- Move gdev declaration to point of use with gpio_device_find_by_fwnode()
  call (Andy Shevchenko)
- Extract acpi_get_handle() return into acpi_status variable rather than
  inline in ACPI_FAILURE() (Andy Shevchenko)
- Use guard(device)(...) instead of scoped_guard(device, ...) {} for a
  single following statement (Andy Shevchenko)
- Use LIST_HEAD(res_list) instead of separate declaration + INIT_LIST_HEAD()
  (Andy Shevchenko)
- Check acpi_dev_get_resources() error before freeing the resource list,
  restoring the check-then-free ordering that had regressed in v11
  (Andy Shevchenko)
- Split ACPI_COMPANION(dev) assignment onto its own line rather than at
  declaration (Andy Shevchenko)

v10 -> v11:
- Replaced custom gpio_controller_ref list and dedup logic with
  gpio_device_find_by_fwnode() (Suggested-by: Andy Shevchenko)
- Moved resource-skip explanation from commit message into a code comment
- Fixed device_is_bound() to check gpio_device_to_device(gdev)->parent
  rather than the gpio_device's own internal class device, which is
  registered on the synthetic "gpio" bus and never has a driver bound to it

v9 -> v10:
- Use acpi_gpio_get_irq_resource() instead of open-coding GPIO resource
  type checks, eliminating duplication with gpiolib-acpi (Andy Shevchenko)
- Simplify string_source guard to a single string_length check, confirmed
  sufficient via ACPICA parser in drivers/acpi/acpica/rsutils.c
  (Andy Shevchenko)
- acpi_dev_get_resources() on single line, free only on success path
  (Andy Shevchenko)
- Reversed xmas tree ordering for variable declarations (Andy Shevchenko)
- Removed useless int ret = 0 assignment (Andy Shevchenko)
- acpi_dev_for_each_child() on single line (Andy Shevchenko)
- Use guard(device)(gpio_dev) pattern to avoid uninitialized variable
  warning and deduplicate the !gpio_dev check (Andy Shevchenko)

v8 -> v9:
- Sent as a 2-patch series: revert of the broken v8 patch, plus a
  corrected resubmission
- Use acpi_gpio_get_irq_resource() instead of open-coding GPIO resource
  type checks, eliminating duplication with gpiolib-acpi (Andy Shevchenko)
- Remove gpio_dep_ctx wrapper struct, pass list_head * directly (Andy Shevchenko)
- Add const to gpio_controller_ref.path (Andy Shevchenko)
- Add NULL check for resource_source.string_ptr to fix a crash on hardware
  where GPIO resources have no named controller (Reported-by: Nathan
  Chancellor, Reported-by: Chaitanya Kumar Borah)
- Use acpi_dev_get_resources() return value properly (Andy Shevchenko)
- Fix all error paths to call free_gpio_controller_list() (Andy Shevchenko)
- Change guard to #if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
- Remove erroneous put_device() calls -- acpi_get_first_physical_node()
  returns a borrowed pointer with no refcount increment
- Use LIST_HEAD() macro, split adev declaration and assignment (Andy Shevchenko)
- scoped_guard single statement without braces (Andy Shevchenko)
- Remove misused Reported-by/Closes tags (Andy Shevchenko)

v7 -> v8:
- Add revert of the earlier pinctrl-amd DMI quirk (patch 1 of the original
  v1-v7 series), confirmed unnecessary once probe ordering is fixed
  (Mario Limonciello)
- Collect Acked-by (Bartosz Golaszewski) and Reviewed-by (Mario Limonciello)

v6 -> v7:
- Fix unused 'ret' variable in check_child_gpioint() (kernel test robot)
- Replace BugLink: with Link: (Bartosz Golaszewski)
- Add Reported-by and Closes tags for kernel test robot warning

v5 -> v6:
- Replace DMI-specific deferral with a generic GpioInt dependency check
  walking ACPI child devices (Suggested-by: Mario Limonciello)

v4 -> v5:
- Add blank line before #include <linux/acpi.h> (Bartosz Golaszewski)
- Use scoped_guard(device, gpio_dev) (Bartosz Golaszewski)

v3 -> v4:
- Rebase onto Linus Walleij's tree (the original patch 1 already there)
- Use --base so series is correctly 1/1 (Andy Shevchenko)

v2 -> v3:
- Fix variable declaration style (Andy Shevchenko)
- Add BugLink tag (Andy Shevchenko)
- CC AMD engineers (Andy Shevchenko)

v1 -> v2:
- Replace custom HID/UID lookup with acpi_dev_get_first_match_dev()
- Use device_is_bound() under device_lock() with explanatory comments
- Add Assisted-by tags per coding-assistants.rst

Note: this patch was originally part of a 2-patch series (v1-v7) whose
first patch was a DMI-specific pinctrl-amd IRQ quirk; that patch was
merged separately into Linus Walleij's tree at v1 and later reverted at
v8 once this patch made the manual IRQ restoration unnecessary.

 drivers/i2c/busses/i2c-designware-platdrv.c | 80 +++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 6d6e81242f74..c8a203fff4d1 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -8,12 +8,14 @@
  * Copyright (C) 2007 MontaVista Software Inc.
  * Copyright (C) 2009 Provigent Ltd.
  */
+#include <linux/acpi.h>
 #include <linux/clk-provider.h>
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/dmi.h>
 #include <linux/err.h>
 #include <linux/errno.h>
+#include <linux/gpio/driver.h>
 #include <linux/i2c.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
@@ -130,6 +132,80 @@ static int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev)
 	return 0;
 }
 
+#if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
+/*
+ * Check whether an ACPI GpioInt resource's referenced GPIO controller
+ * has finished probing. Resources with no named controller (resource
+ * source string) are skipped, since they can't be resolved to a
+ * struct device.
+ */
+static int check_gpioint_resource(struct acpi_resource *ares, void *data)
+{
+	struct acpi_resource_gpio *agpio;
+	struct acpi_device *gpio_adev;
+	struct device *gpio_dev;
+	acpi_handle handle;
+	acpi_status status;
+
+	if (!acpi_gpio_get_irq_resource(ares, &agpio))
+		return 1; /* not a GpioInt resource, skip */
+
+	if (!agpio->resource_source.string_length)
+		return 1; /* no named controller, skip */
+
+	status = acpi_get_handle(NULL, agpio->resource_source.string_ptr, &handle);
+	if (ACPI_FAILURE(status))
+		return 1;
+
+	gpio_adev = acpi_fetch_acpi_dev(handle);
+	if (!gpio_adev)
+		return 1;
+
+	struct gpio_device *gdev __free(gpio_device_put) =
+		gpio_device_find_by_fwnode(acpi_fwnode_handle(gpio_adev));
+	if (!gdev)
+		return -EPROBE_DEFER; /* controller not registered yet: abort walk */
+
+	gpio_dev = gpio_device_to_device(gdev)->parent;
+
+	guard(device)(gpio_dev);
+	if (!device_is_bound(gpio_dev))
+		return -EPROBE_DEFER; /* controller not bound yet: abort walk */
+
+	return 1; /* bound, skip adding to resource list, continue walk */
+}
+
+static int check_child_gpioint(struct acpi_device *adev, void *data)
+{
+	LIST_HEAD(res_list);
+	int ret;
+
+	ret = acpi_dev_get_resources(adev, &res_list, check_gpioint_resource, NULL);
+	if (ret < 0)
+		return ret;
+
+	acpi_dev_free_resource_list(&res_list);
+
+	return 0;
+}
+
+static int i2c_dw_check_gpio_dependencies(struct device *dev)
+{
+	struct acpi_device *adev;
+
+	adev = ACPI_COMPANION(dev);
+	if (!adev)
+		return 0;
+
+	return acpi_dev_for_each_child(adev, check_child_gpioint, NULL);
+}
+#else
+static int i2c_dw_check_gpio_dependencies(struct device *dev)
+{
+	return 0;
+}
+#endif /* CONFIG_ACPI && CONFIG_GPIOLIB */
+
 static int dw_i2c_plat_probe(struct platform_device *pdev)
 {
 	u32 flags = (uintptr_t)device_get_match_data(&pdev->dev);
@@ -138,6 +214,10 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
 	struct dw_i2c_dev *dev;
 	int irq, ret;
 
+	ret = i2c_dw_check_gpio_dependencies(device);
+	if (ret)
+		return ret;
+
 	irq = platform_get_irq_optional(pdev, 0);
 	if (irq == -ENXIO)
 		flags |= ACCESS_POLLING;

base-commit: 58717b2a1365d06c8c64b72aa948541b53fe31eb
-- 
2.54.0

Re: [PATCH v13] i2c: designware: defer probe if child GpioInt controllers are not bound

[Andy Shevchenko]

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.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

One nit-pick below. No need to resend, hopefully Andi can tweak that
whilst applying.

...

> +static int check_gpioint_resource(struct acpi_resource *ares, void *data)
> +{
> +	struct acpi_resource_gpio *agpio;
> +	struct acpi_device *gpio_adev;
> +	struct device *gpio_dev;
> +	acpi_handle handle;
> +	acpi_status status;
> +
> +	if (!acpi_gpio_get_irq_resource(ares, &agpio))
> +		return 1; /* not a GpioInt resource, skip */
> +
> +	if (!agpio->resource_source.string_length)
> +		return 1; /* no named controller, skip */
> +
> +	status = acpi_get_handle(NULL, agpio->resource_source.string_ptr, &handle);
> +	if (ACPI_FAILURE(status))
> +		return 1;
> +
> +	gpio_adev = acpi_fetch_acpi_dev(handle);
> +	if (!gpio_adev)
> +		return 1;
> +
> +	struct gpio_device *gdev __free(gpio_device_put) =
> +		gpio_device_find_by_fwnode(acpi_fwnode_handle(gpio_adev));
> +	if (!gdev)
> +		return -EPROBE_DEFER; /* controller not registered yet: abort walk */
> +
> +	gpio_dev = gpio_device_to_device(gdev)->parent;
> +
> +	guard(device)(gpio_dev);

+ blank line here as well. I asked to add blank lines before and after.

  "...make sure it has a blank lines before and after, so it's visible
   as a separate entity."

> +	if (!device_is_bound(gpio_dev))
> +		return -EPROBE_DEFER; /* controller not bound yet: abort walk */
> +
> +	return 1; /* bound, skip adding to resource list, continue walk */
> +}

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v13] i2c: designware: defer probe if child GpioInt controllers are not bound

[Bartosz Golaszewski]

On Sat, 18 Jul 2026 07:43:31 +0200, Hardik Prakash
<hardikprakash.official@gmail.com> said:
> 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.
>
> Fixes: 3812a9e84265 ("pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11")
> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
> Assisted-by: Claude:claude-sonnet-5
> Assisted-by: DeepSeek:deepseek-v4-pro
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
> ---

Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH v13] i2c: designware: defer probe if child GpioInt controllers are not bound

[Hardik Prakash]

Hi Wolfram, Andi,

This has Reviewed-by from Andy and Acked-by from Bart. Could this be
queued for the next merge window?

Thanks,
Hardik

On Mon, 20 Jul 2026 at 13:37, Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Sat, 18 Jul 2026 07:43:31 +0200, Hardik Prakash
> <hardikprakash.official@gmail.com> said:
> > 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.
> >
> > Fixes: 3812a9e84265 ("pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11")
> > Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> > Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
> > Assisted-by: Claude:claude-sonnet-5
> > Assisted-by: DeepSeek:deepseek-v4-pro
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
> > ---
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Re: [PATCH v13] i2c: designware: defer probe if child GpioInt controllers are not bound

[Andi Shyti]

Hi Hardik,

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.
> 
> Fixes: 3812a9e84265 ("pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11")
> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
> Assisted-by: Claude:claude-sonnet-5
> Assisted-by: DeepSeek:deepseek-v4-pro
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494

This should be "Closes:". "Link:" is referred to the page where
the patch has been discussed.

merged to i2c/i2c-fixes.

Thanks,
Andi

> ---
> v12 -> v13:
> - v12 was sent as an incomplete diff (generated against v11 rather than
>   against current master due to a git format-patch invocation mistake on
>   my end), not a real standalone patch (Andy Shevchenko)
> - Not carrying forward Bartosz Golaszewski's v12 Acked-by, per Andy's
>   request
> - Add blank line before guard(device)(gpio_dev) for readability (Andy
>   Shevchenko)
> - No other functional code changes since v12
> 
> v11 -> v12:
> - Move gdev declaration to point of use with gpio_device_find_by_fwnode()
>   call (Andy Shevchenko)
> - Extract acpi_get_handle() return into acpi_status variable rather than
>   inline in ACPI_FAILURE() (Andy Shevchenko)
> - Use guard(device)(...) instead of scoped_guard(device, ...) {} for a
>   single following statement (Andy Shevchenko)
> - Use LIST_HEAD(res_list) instead of separate declaration + INIT_LIST_HEAD()
>   (Andy Shevchenko)
> - Check acpi_dev_get_resources() error before freeing the resource list,
>   restoring the check-then-free ordering that had regressed in v11
>   (Andy Shevchenko)
> - Split ACPI_COMPANION(dev) assignment onto its own line rather than at
>   declaration (Andy Shevchenko)
> 
> v10 -> v11:
> - Replaced custom gpio_controller_ref list and dedup logic with
>   gpio_device_find_by_fwnode() (Suggested-by: Andy Shevchenko)
> - Moved resource-skip explanation from commit message into a code comment
> - Fixed device_is_bound() to check gpio_device_to_device(gdev)->parent
>   rather than the gpio_device's own internal class device, which is
>   registered on the synthetic "gpio" bus and never has a driver bound to it
> 
> v9 -> v10:
> - Use acpi_gpio_get_irq_resource() instead of open-coding GPIO resource
>   type checks, eliminating duplication with gpiolib-acpi (Andy Shevchenko)
> - Simplify string_source guard to a single string_length check, confirmed
>   sufficient via ACPICA parser in drivers/acpi/acpica/rsutils.c
>   (Andy Shevchenko)
> - acpi_dev_get_resources() on single line, free only on success path
>   (Andy Shevchenko)
> - Reversed xmas tree ordering for variable declarations (Andy Shevchenko)
> - Removed useless int ret = 0 assignment (Andy Shevchenko)
> - acpi_dev_for_each_child() on single line (Andy Shevchenko)
> - Use guard(device)(gpio_dev) pattern to avoid uninitialized variable
>   warning and deduplicate the !gpio_dev check (Andy Shevchenko)
> 
> v8 -> v9:
> - Sent as a 2-patch series: revert of the broken v8 patch, plus a
>   corrected resubmission
> - Use acpi_gpio_get_irq_resource() instead of open-coding GPIO resource
>   type checks, eliminating duplication with gpiolib-acpi (Andy Shevchenko)
> - Remove gpio_dep_ctx wrapper struct, pass list_head * directly (Andy Shevchenko)
> - Add const to gpio_controller_ref.path (Andy Shevchenko)
> - Add NULL check for resource_source.string_ptr to fix a crash on hardware
>   where GPIO resources have no named controller (Reported-by: Nathan
>   Chancellor, Reported-by: Chaitanya Kumar Borah)
> - Use acpi_dev_get_resources() return value properly (Andy Shevchenko)
> - Fix all error paths to call free_gpio_controller_list() (Andy Shevchenko)
> - Change guard to #if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
> - Remove erroneous put_device() calls -- acpi_get_first_physical_node()
>   returns a borrowed pointer with no refcount increment
> - Use LIST_HEAD() macro, split adev declaration and assignment (Andy Shevchenko)
> - scoped_guard single statement without braces (Andy Shevchenko)
> - Remove misused Reported-by/Closes tags (Andy Shevchenko)
> 
> v7 -> v8:
> - Add revert of the earlier pinctrl-amd DMI quirk (patch 1 of the original
>   v1-v7 series), confirmed unnecessary once probe ordering is fixed
>   (Mario Limonciello)
> - Collect Acked-by (Bartosz Golaszewski) and Reviewed-by (Mario Limonciello)
> 
> v6 -> v7:
> - Fix unused 'ret' variable in check_child_gpioint() (kernel test robot)
> - Replace BugLink: with Link: (Bartosz Golaszewski)
> - Add Reported-by and Closes tags for kernel test robot warning
> 
> v5 -> v6:
> - Replace DMI-specific deferral with a generic GpioInt dependency check
>   walking ACPI child devices (Suggested-by: Mario Limonciello)
> 
> v4 -> v5:
> - Add blank line before #include <linux/acpi.h> (Bartosz Golaszewski)
> - Use scoped_guard(device, gpio_dev) (Bartosz Golaszewski)
> 
> v3 -> v4:
> - Rebase onto Linus Walleij's tree (the original patch 1 already there)
> - Use --base so series is correctly 1/1 (Andy Shevchenko)
> 
> v2 -> v3:
> - Fix variable declaration style (Andy Shevchenko)
> - Add BugLink tag (Andy Shevchenko)
> - CC AMD engineers (Andy Shevchenko)
> 
> v1 -> v2:
> - Replace custom HID/UID lookup with acpi_dev_get_first_match_dev()
> - Use device_is_bound() under device_lock() with explanatory comments
> - Add Assisted-by tags per coding-assistants.rst
> 
> Note: this patch was originally part of a 2-patch series (v1-v7) whose
> first patch was a DMI-specific pinctrl-amd IRQ quirk; that patch was
> merged separately into Linus Walleij's tree at v1 and later reverted at
> v8 once this patch made the manual IRQ restoration unnecessary.
> 
>  drivers/i2c/busses/i2c-designware-platdrv.c | 80 +++++++++++++++++++++
>  1 file changed, 80 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 6d6e81242f74..c8a203fff4d1 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -8,12 +8,14 @@
>   * Copyright (C) 2007 MontaVista Software Inc.
>   * Copyright (C) 2009 Provigent Ltd.
>   */
> +#include <linux/acpi.h>
>  #include <linux/clk-provider.h>
>  #include <linux/clk.h>
>  #include <linux/delay.h>
>  #include <linux/dmi.h>
>  #include <linux/err.h>
>  #include <linux/errno.h>
> +#include <linux/gpio/driver.h>
>  #include <linux/i2c.h>
>  #include <linux/interrupt.h>
>  #include <linux/io.h>
> @@ -130,6 +132,80 @@ static int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev)
>  	return 0;
>  }
>  
> +#if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
> +/*
> + * Check whether an ACPI GpioInt resource's referenced GPIO controller
> + * has finished probing. Resources with no named controller (resource
> + * source string) are skipped, since they can't be resolved to a
> + * struct device.
> + */
> +static int check_gpioint_resource(struct acpi_resource *ares, void *data)
> +{
> +	struct acpi_resource_gpio *agpio;
> +	struct acpi_device *gpio_adev;
> +	struct device *gpio_dev;
> +	acpi_handle handle;
> +	acpi_status status;
> +
> +	if (!acpi_gpio_get_irq_resource(ares, &agpio))
> +		return 1; /* not a GpioInt resource, skip */
> +
> +	if (!agpio->resource_source.string_length)
> +		return 1; /* no named controller, skip */
> +
> +	status = acpi_get_handle(NULL, agpio->resource_source.string_ptr, &handle);
> +	if (ACPI_FAILURE(status))
> +		return 1;
> +
> +	gpio_adev = acpi_fetch_acpi_dev(handle);
> +	if (!gpio_adev)
> +		return 1;
> +
> +	struct gpio_device *gdev __free(gpio_device_put) =
> +		gpio_device_find_by_fwnode(acpi_fwnode_handle(gpio_adev));
> +	if (!gdev)
> +		return -EPROBE_DEFER; /* controller not registered yet: abort walk */
> +
> +	gpio_dev = gpio_device_to_device(gdev)->parent;
> +
> +	guard(device)(gpio_dev);
> +	if (!device_is_bound(gpio_dev))
> +		return -EPROBE_DEFER; /* controller not bound yet: abort walk */
> +
> +	return 1; /* bound, skip adding to resource list, continue walk */
> +}
> +
> +static int check_child_gpioint(struct acpi_device *adev, void *data)
> +{
> +	LIST_HEAD(res_list);
> +	int ret;
> +
> +	ret = acpi_dev_get_resources(adev, &res_list, check_gpioint_resource, NULL);
> +	if (ret < 0)
> +		return ret;
> +
> +	acpi_dev_free_resource_list(&res_list);
> +
> +	return 0;
> +}
> +
> +static int i2c_dw_check_gpio_dependencies(struct device *dev)
> +{
> +	struct acpi_device *adev;
> +
> +	adev = ACPI_COMPANION(dev);
> +	if (!adev)
> +		return 0;
> +
> +	return acpi_dev_for_each_child(adev, check_child_gpioint, NULL);
> +}
> +#else
> +static int i2c_dw_check_gpio_dependencies(struct device *dev)
> +{
> +	return 0;
> +}
> +#endif /* CONFIG_ACPI && CONFIG_GPIOLIB */
> +
>  static int dw_i2c_plat_probe(struct platform_device *pdev)
>  {
>  	u32 flags = (uintptr_t)device_get_match_data(&pdev->dev);
> @@ -138,6 +214,10 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
>  	struct dw_i2c_dev *dev;
>  	int irq, ret;
>  
> +	ret = i2c_dw_check_gpio_dependencies(device);
> +	if (ret)
> +		return ret;
> +
>  	irq = platform_get_irq_optional(pdev, 0);
>  	if (irq == -ENXIO)
>  		flags |= ACCESS_POLLING;
> 
> base-commit: 58717b2a1365d06c8c64b72aa948541b53fe31eb
> -- 
> 2.54.0
> 

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

[Thorsten Leemhuis]

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.
>>
>> Fixes: 3812a9e84265 ("pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11")
>> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
>> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> [...]
> merged to i2c/i2c-fixes.
> 
> Thanks,
> Andi

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

Ciao, Thorsten

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

>> ---
>> v12 -> v13:
>> - v12 was sent as an incomplete diff (generated against v11 rather than
>>   against current master due to a git format-patch invocation mistake on
>>   my end), not a real standalone patch (Andy Shevchenko)
>> - Not carrying forward Bartosz Golaszewski's v12 Acked-by, per Andy's
>>   request
>> - Add blank line before guard(device)(gpio_dev) for readability (Andy
>>   Shevchenko)
>> - No other functional code changes since v12
>>
>> v11 -> v12:
>> - Move gdev declaration to point of use with gpio_device_find_by_fwnode()
>>   call (Andy Shevchenko)
>> - Extract acpi_get_handle() return into acpi_status variable rather than
>>   inline in ACPI_FAILURE() (Andy Shevchenko)
>> - Use guard(device)(...) instead of scoped_guard(device, ...) {} for a
>>   single following statement (Andy Shevchenko)
>> - Use LIST_HEAD(res_list) instead of separate declaration + INIT_LIST_HEAD()
>>   (Andy Shevchenko)
>> - Check acpi_dev_get_resources() error before freeing the resource list,
>>   restoring the check-then-free ordering that had regressed in v11
>>   (Andy Shevchenko)
>> - Split ACPI_COMPANION(dev) assignment onto its own line rather than at
>>   declaration (Andy Shevchenko)
>>
>> v10 -> v11:
>> - Replaced custom gpio_controller_ref list and dedup logic with
>>   gpio_device_find_by_fwnode() (Suggested-by: Andy Shevchenko)
>> - Moved resource-skip explanation from commit message into a code comment
>> - Fixed device_is_bound() to check gpio_device_to_device(gdev)->parent
>>   rather than the gpio_device's own internal class device, which is
>>   registered on the synthetic "gpio" bus and never has a driver bound to it
>>
>> v9 -> v10:
>> - Use acpi_gpio_get_irq_resource() instead of open-coding GPIO resource
>>   type checks, eliminating duplication with gpiolib-acpi (Andy Shevchenko)
>> - Simplify string_source guard to a single string_length check, confirmed
>>   sufficient via ACPICA parser in drivers/acpi/acpica/rsutils.c
>>   (Andy Shevchenko)
>> - acpi_dev_get_resources() on single line, free only on success path
>>   (Andy Shevchenko)
>> - Reversed xmas tree ordering for variable declarations (Andy Shevchenko)
>> - Removed useless int ret = 0 assignment (Andy Shevchenko)
>> - acpi_dev_for_each_child() on single line (Andy Shevchenko)
>> - Use guard(device)(gpio_dev) pattern to avoid uninitialized variable
>>   warning and deduplicate the !gpio_dev check (Andy Shevchenko)
>>
>> v8 -> v9:
>> - Sent as a 2-patch series: revert of the broken v8 patch, plus a
>>   corrected resubmission
>> - Use acpi_gpio_get_irq_resource() instead of open-coding GPIO resource
>>   type checks, eliminating duplication with gpiolib-acpi (Andy Shevchenko)
>> - Remove gpio_dep_ctx wrapper struct, pass list_head * directly (Andy Shevchenko)
>> - Add const to gpio_controller_ref.path (Andy Shevchenko)
>> - Add NULL check for resource_source.string_ptr to fix a crash on hardware
>>   where GPIO resources have no named controller (Reported-by: Nathan
>>   Chancellor, Reported-by: Chaitanya Kumar Borah)
>> - Use acpi_dev_get_resources() return value properly (Andy Shevchenko)
>> - Fix all error paths to call free_gpio_controller_list() (Andy Shevchenko)
>> - Change guard to #if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
>> - Remove erroneous put_device() calls -- acpi_get_first_physical_node()
>>   returns a borrowed pointer with no refcount increment
>> - Use LIST_HEAD() macro, split adev declaration and assignment (Andy Shevchenko)
>> - scoped_guard single statement without braces (Andy Shevchenko)
>> - Remove misused Reported-by/Closes tags (Andy Shevchenko)
>>
>> v7 -> v8:
>> - Add revert of the earlier pinctrl-amd DMI quirk (patch 1 of the original
>>   v1-v7 series), confirmed unnecessary once probe ordering is fixed
>>   (Mario Limonciello)
>> - Collect Acked-by (Bartosz Golaszewski) and Reviewed-by (Mario Limonciello)
>>
>> v6 -> v7:
>> - Fix unused 'ret' variable in check_child_gpioint() (kernel test robot)
>> - Replace BugLink: with Link: (Bartosz Golaszewski)
>> - Add Reported-by and Closes tags for kernel test robot warning
>>
>> v5 -> v6:
>> - Replace DMI-specific deferral with a generic GpioInt dependency check
>>   walking ACPI child devices (Suggested-by: Mario Limonciello)
>>
>> v4 -> v5:
>> - Add blank line before #include <linux/acpi.h> (Bartosz Golaszewski)
>> - Use scoped_guard(device, gpio_dev) (Bartosz Golaszewski)
>>
>> v3 -> v4:
>> - Rebase onto Linus Walleij's tree (the original patch 1 already there)
>> - Use --base so series is correctly 1/1 (Andy Shevchenko)
>>
>> v2 -> v3:
>> - Fix variable declaration style (Andy Shevchenko)
>> - Add BugLink tag (Andy Shevchenko)
>> - CC AMD engineers (Andy Shevchenko)
>>
>> v1 -> v2:
>> - Replace custom HID/UID lookup with acpi_dev_get_first_match_dev()
>> - Use device_is_bound() under device_lock() with explanatory comments
>> - Add Assisted-by tags per coding-assistants.rst
>>
>> Note: this patch was originally part of a 2-patch series (v1-v7) whose
>> first patch was a DMI-specific pinctrl-amd IRQ quirk; that patch was
>> merged separately into Linus Walleij's tree at v1 and later reverted at
>> v8 once this patch made the manual IRQ restoration unnecessary.
>>
>>  drivers/i2c/busses/i2c-designware-platdrv.c | 80 +++++++++++++++++++++
>>  1 file changed, 80 insertions(+)
>>
>> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
>> index 6d6e81242f74..c8a203fff4d1 100644
>> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
>> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
>> @@ -8,12 +8,14 @@
>>   * Copyright (C) 2007 MontaVista Software Inc.
>>   * Copyright (C) 2009 Provigent Ltd.
>>   */
>> +#include <linux/acpi.h>
>>  #include <linux/clk-provider.h>
>>  #include <linux/clk.h>
>>  #include <linux/delay.h>
>>  #include <linux/dmi.h>
>>  #include <linux/err.h>
>>  #include <linux/errno.h>
>> +#include <linux/gpio/driver.h>
>>  #include <linux/i2c.h>
>>  #include <linux/interrupt.h>
>>  #include <linux/io.h>
>> @@ -130,6 +132,80 @@ static int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev)
>>  	return 0;
>>  }
>>  
>> +#if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
>> +/*
>> + * Check whether an ACPI GpioInt resource's referenced GPIO controller
>> + * has finished probing. Resources with no named controller (resource
>> + * source string) are skipped, since they can't be resolved to a
>> + * struct device.
>> + */
>> +static int check_gpioint_resource(struct acpi_resource *ares, void *data)
>> +{
>> +	struct acpi_resource_gpio *agpio;
>> +	struct acpi_device *gpio_adev;
>> +	struct device *gpio_dev;
>> +	acpi_handle handle;
>> +	acpi_status status;
>> +
>> +	if (!acpi_gpio_get_irq_resource(ares, &agpio))
>> +		return 1; /* not a GpioInt resource, skip */
>> +
>> +	if (!agpio->resource_source.string_length)
>> +		return 1; /* no named controller, skip */
>> +
>> +	status = acpi_get_handle(NULL, agpio->resource_source.string_ptr, &handle);
>> +	if (ACPI_FAILURE(status))
>> +		return 1;
>> +
>> +	gpio_adev = acpi_fetch_acpi_dev(handle);
>> +	if (!gpio_adev)
>> +		return 1;
>> +
>> +	struct gpio_device *gdev __free(gpio_device_put) =
>> +		gpio_device_find_by_fwnode(acpi_fwnode_handle(gpio_adev));
>> +	if (!gdev)
>> +		return -EPROBE_DEFER; /* controller not registered yet: abort walk */
>> +
>> +	gpio_dev = gpio_device_to_device(gdev)->parent;
>> +
>> +	guard(device)(gpio_dev);
>> +	if (!device_is_bound(gpio_dev))
>> +		return -EPROBE_DEFER; /* controller not bound yet: abort walk */
>> +
>> +	return 1; /* bound, skip adding to resource list, continue walk */
>> +}
>> +
>> +static int check_child_gpioint(struct acpi_device *adev, void *data)
>> +{
>> +	LIST_HEAD(res_list);
>> +	int ret;
>> +
>> +	ret = acpi_dev_get_resources(adev, &res_list, check_gpioint_resource, NULL);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	acpi_dev_free_resource_list(&res_list);
>> +
>> +	return 0;
>> +}
>> +
>> +static int i2c_dw_check_gpio_dependencies(struct device *dev)
>> +{
>> +	struct acpi_device *adev;
>> +
>> +	adev = ACPI_COMPANION(dev);
>> +	if (!adev)
>> +		return 0;
>> +
>> +	return acpi_dev_for_each_child(adev, check_child_gpioint, NULL);
>> +}
>> +#else
>> +static int i2c_dw_check_gpio_dependencies(struct device *dev)
>> +{
>> +	return 0;
>> +}
>> +#endif /* CONFIG_ACPI && CONFIG_GPIOLIB */
>> +
>>  static int dw_i2c_plat_probe(struct platform_device *pdev)
>>  {
>>  	u32 flags = (uintptr_t)device_get_match_data(&pdev->dev);
>> @@ -138,6 +214,10 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
>>  	struct dw_i2c_dev *dev;
>>  	int irq, ret;
>>  
>> +	ret = i2c_dw_check_gpio_dependencies(device);
>> +	if (ret)
>> +		return ret;
>> +
>>  	irq = platform_get_irq_optional(pdev, 0);
>>  	if (irq == -ENXIO)
>>  		flags |= ACCESS_POLLING;
>>
>> base-commit: 58717b2a1365d06c8c64b72aa948541b53fe31eb
>> -- 
>> 2.54.0
>>
> 

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

[Hardik Prakash]

[-- Attachment #1: Type: text/plain, Size: 14028 bytes --]

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

   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.

Thanks,
Hardik

On Fri, 7 Aug 2026 at 19:37, Thorsten Leemhuis <linux@leemhuis.info> 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.
> >>
> >> Fixes: 3812a9e84265 ("pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11")
> >> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> >> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > [...]
> > merged to i2c/i2c-fixes.
> >
> > Thanks,
> > Andi
>
> 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
>
> Ciao, Thorsten
>
> #regzbot introduced: 0a4bb2abc3e56d
> #regzbot title i2c: designware: ThinkPad touchpad broke
>
> >> ---
> >> v12 -> v13:
> >> - v12 was sent as an incomplete diff (generated against v11 rather than
> >>   against current master due to a git format-patch invocation mistake on
> >>   my end), not a real standalone patch (Andy Shevchenko)
> >> - Not carrying forward Bartosz Golaszewski's v12 Acked-by, per Andy's
> >>   request
> >> - Add blank line before guard(device)(gpio_dev) for readability (Andy
> >>   Shevchenko)
> >> - No other functional code changes since v12
> >>
> >> v11 -> v12:
> >> - Move gdev declaration to point of use with gpio_device_find_by_fwnode()
> >>   call (Andy Shevchenko)
> >> - Extract acpi_get_handle() return into acpi_status variable rather than
> >>   inline in ACPI_FAILURE() (Andy Shevchenko)
> >> - Use guard(device)(...) instead of scoped_guard(device, ...) {} for a
> >>   single following statement (Andy Shevchenko)
> >> - Use LIST_HEAD(res_list) instead of separate declaration + INIT_LIST_HEAD()
> >>   (Andy Shevchenko)
> >> - Check acpi_dev_get_resources() error before freeing the resource list,
> >>   restoring the check-then-free ordering that had regressed in v11
> >>   (Andy Shevchenko)
> >> - Split ACPI_COMPANION(dev) assignment onto its own line rather than at
> >>   declaration (Andy Shevchenko)
> >>
> >> v10 -> v11:
> >> - Replaced custom gpio_controller_ref list and dedup logic with
> >>   gpio_device_find_by_fwnode() (Suggested-by: Andy Shevchenko)
> >> - Moved resource-skip explanation from commit message into a code comment
> >> - Fixed device_is_bound() to check gpio_device_to_device(gdev)->parent
> >>   rather than the gpio_device's own internal class device, which is
> >>   registered on the synthetic "gpio" bus and never has a driver bound to it
> >>
> >> v9 -> v10:
> >> - Use acpi_gpio_get_irq_resource() instead of open-coding GPIO resource
> >>   type checks, eliminating duplication with gpiolib-acpi (Andy Shevchenko)
> >> - Simplify string_source guard to a single string_length check, confirmed
> >>   sufficient via ACPICA parser in drivers/acpi/acpica/rsutils.c
> >>   (Andy Shevchenko)
> >> - acpi_dev_get_resources() on single line, free only on success path
> >>   (Andy Shevchenko)
> >> - Reversed xmas tree ordering for variable declarations (Andy Shevchenko)
> >> - Removed useless int ret = 0 assignment (Andy Shevchenko)
> >> - acpi_dev_for_each_child() on single line (Andy Shevchenko)
> >> - Use guard(device)(gpio_dev) pattern to avoid uninitialized variable
> >>   warning and deduplicate the !gpio_dev check (Andy Shevchenko)
> >>
> >> v8 -> v9:
> >> - Sent as a 2-patch series: revert of the broken v8 patch, plus a
> >>   corrected resubmission
> >> - Use acpi_gpio_get_irq_resource() instead of open-coding GPIO resource
> >>   type checks, eliminating duplication with gpiolib-acpi (Andy Shevchenko)
> >> - Remove gpio_dep_ctx wrapper struct, pass list_head * directly (Andy Shevchenko)
> >> - Add const to gpio_controller_ref.path (Andy Shevchenko)
> >> - Add NULL check for resource_source.string_ptr to fix a crash on hardware
> >>   where GPIO resources have no named controller (Reported-by: Nathan
> >>   Chancellor, Reported-by: Chaitanya Kumar Borah)
> >> - Use acpi_dev_get_resources() return value properly (Andy Shevchenko)
> >> - Fix all error paths to call free_gpio_controller_list() (Andy Shevchenko)
> >> - Change guard to #if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
> >> - Remove erroneous put_device() calls -- acpi_get_first_physical_node()
> >>   returns a borrowed pointer with no refcount increment
> >> - Use LIST_HEAD() macro, split adev declaration and assignment (Andy Shevchenko)
> >> - scoped_guard single statement without braces (Andy Shevchenko)
> >> - Remove misused Reported-by/Closes tags (Andy Shevchenko)
> >>
> >> v7 -> v8:
> >> - Add revert of the earlier pinctrl-amd DMI quirk (patch 1 of the original
> >>   v1-v7 series), confirmed unnecessary once probe ordering is fixed
> >>   (Mario Limonciello)
> >> - Collect Acked-by (Bartosz Golaszewski) and Reviewed-by (Mario Limonciello)
> >>
> >> v6 -> v7:
> >> - Fix unused 'ret' variable in check_child_gpioint() (kernel test robot)
> >> - Replace BugLink: with Link: (Bartosz Golaszewski)
> >> - Add Reported-by and Closes tags for kernel test robot warning
> >>
> >> v5 -> v6:
> >> - Replace DMI-specific deferral with a generic GpioInt dependency check
> >>   walking ACPI child devices (Suggested-by: Mario Limonciello)
> >>
> >> v4 -> v5:
> >> - Add blank line before #include <linux/acpi.h> (Bartosz Golaszewski)
> >> - Use scoped_guard(device, gpio_dev) (Bartosz Golaszewski)
> >>
> >> v3 -> v4:
> >> - Rebase onto Linus Walleij's tree (the original patch 1 already there)
> >> - Use --base so series is correctly 1/1 (Andy Shevchenko)
> >>
> >> v2 -> v3:
> >> - Fix variable declaration style (Andy Shevchenko)
> >> - Add BugLink tag (Andy Shevchenko)
> >> - CC AMD engineers (Andy Shevchenko)
> >>
> >> v1 -> v2:
> >> - Replace custom HID/UID lookup with acpi_dev_get_first_match_dev()
> >> - Use device_is_bound() under device_lock() with explanatory comments
> >> - Add Assisted-by tags per coding-assistants.rst
> >>
> >> Note: this patch was originally part of a 2-patch series (v1-v7) whose
> >> first patch was a DMI-specific pinctrl-amd IRQ quirk; that patch was
> >> merged separately into Linus Walleij's tree at v1 and later reverted at
> >> v8 once this patch made the manual IRQ restoration unnecessary.
> >>
> >>  drivers/i2c/busses/i2c-designware-platdrv.c | 80 +++++++++++++++++++++
> >>  1 file changed, 80 insertions(+)
> >>
> >> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
> >> index 6d6e81242f74..c8a203fff4d1 100644
> >> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> >> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> >> @@ -8,12 +8,14 @@
> >>   * Copyright (C) 2007 MontaVista Software Inc.
> >>   * Copyright (C) 2009 Provigent Ltd.
> >>   */
> >> +#include <linux/acpi.h>
> >>  #include <linux/clk-provider.h>
> >>  #include <linux/clk.h>
> >>  #include <linux/delay.h>
> >>  #include <linux/dmi.h>
> >>  #include <linux/err.h>
> >>  #include <linux/errno.h>
> >> +#include <linux/gpio/driver.h>
> >>  #include <linux/i2c.h>
> >>  #include <linux/interrupt.h>
> >>  #include <linux/io.h>
> >> @@ -130,6 +132,80 @@ static int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev)
> >>      return 0;
> >>  }
> >>
> >> +#if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
> >> +/*
> >> + * Check whether an ACPI GpioInt resource's referenced GPIO controller
> >> + * has finished probing. Resources with no named controller (resource
> >> + * source string) are skipped, since they can't be resolved to a
> >> + * struct device.
> >> + */
> >> +static int check_gpioint_resource(struct acpi_resource *ares, void *data)
> >> +{
> >> +    struct acpi_resource_gpio *agpio;
> >> +    struct acpi_device *gpio_adev;
> >> +    struct device *gpio_dev;
> >> +    acpi_handle handle;
> >> +    acpi_status status;
> >> +
> >> +    if (!acpi_gpio_get_irq_resource(ares, &agpio))
> >> +            return 1; /* not a GpioInt resource, skip */
> >> +
> >> +    if (!agpio->resource_source.string_length)
> >> +            return 1; /* no named controller, skip */
> >> +
> >> +    status = acpi_get_handle(NULL, agpio->resource_source.string_ptr, &handle);
> >> +    if (ACPI_FAILURE(status))
> >> +            return 1;
> >> +
> >> +    gpio_adev = acpi_fetch_acpi_dev(handle);
> >> +    if (!gpio_adev)
> >> +            return 1;
> >> +
> >> +    struct gpio_device *gdev __free(gpio_device_put) =
> >> +            gpio_device_find_by_fwnode(acpi_fwnode_handle(gpio_adev));
> >> +    if (!gdev)
> >> +            return -EPROBE_DEFER; /* controller not registered yet: abort walk */
> >> +
> >> +    gpio_dev = gpio_device_to_device(gdev)->parent;
> >> +
> >> +    guard(device)(gpio_dev);
> >> +    if (!device_is_bound(gpio_dev))
> >> +            return -EPROBE_DEFER; /* controller not bound yet: abort walk */
> >> +
> >> +    return 1; /* bound, skip adding to resource list, continue walk */
> >> +}
> >> +
> >> +static int check_child_gpioint(struct acpi_device *adev, void *data)
> >> +{
> >> +    LIST_HEAD(res_list);
> >> +    int ret;
> >> +
> >> +    ret = acpi_dev_get_resources(adev, &res_list, check_gpioint_resource, NULL);
> >> +    if (ret < 0)
> >> +            return ret;
> >> +
> >> +    acpi_dev_free_resource_list(&res_list);
> >> +
> >> +    return 0;
> >> +}
> >> +
> >> +static int i2c_dw_check_gpio_dependencies(struct device *dev)
> >> +{
> >> +    struct acpi_device *adev;
> >> +
> >> +    adev = ACPI_COMPANION(dev);
> >> +    if (!adev)
> >> +            return 0;
> >> +
> >> +    return acpi_dev_for_each_child(adev, check_child_gpioint, NULL);
> >> +}
> >> +#else
> >> +static int i2c_dw_check_gpio_dependencies(struct device *dev)
> >> +{
> >> +    return 0;
> >> +}
> >> +#endif /* CONFIG_ACPI && CONFIG_GPIOLIB */
> >> +
> >>  static int dw_i2c_plat_probe(struct platform_device *pdev)
> >>  {
> >>      u32 flags = (uintptr_t)device_get_match_data(&pdev->dev);
> >> @@ -138,6 +214,10 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
> >>      struct dw_i2c_dev *dev;
> >>      int irq, ret;
> >>
> >> +    ret = i2c_dw_check_gpio_dependencies(device);
> >> +    if (ret)
> >> +            return ret;
> >> +
> >>      irq = platform_get_irq_optional(pdev, 0);
> >>      if (irq == -ENXIO)
> >>              flags |= ACCESS_POLLING;
> >>
> >> base-commit: 58717b2a1365d06c8c64b72aa948541b53fe31eb
> >> --
> >> 2.54.0
> >>
> >

[-- Attachment #2: i2c-designware-gpio-debug.patch --]
[-- Type: text/x-patch, Size: 3815 bytes --]

Subject: [DEBUG ONLY] i2c: designware: trace GpioInt dependency check decisions

Temporary debug instrumentation for diagnosing the regression reported
by Thorsten Leemhuis on ThinkPad T14s Gen 4 (AMD), where AMDI0010:01
hits "lost arbitration" with 0a4bb2abc3e56d applied.

Adds pr_info() tracing to every branch of the dependency check so we
can see exactly what it decides for each ACPI child device and
GpioInt resource on affected hardware. No functional changes.
Compile-verified against current mainline (a7c7074b58d2).

Not for submission -- diagnostic only. Apply with:
  git apply this.patch
or
  patch -p1 < this.patch

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index c8a203fff4d1..b7d323b3c689 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -150,27 +150,46 @@ static int check_gpioint_resource(struct acpi_resource *ares, void *data)
 	if (!acpi_gpio_get_irq_resource(ares, &agpio))
 		return 1; /* not a GpioInt resource, skip */
 
+	pr_info("i2c-dw-gpio-dbg: GpioInt resource_source=%.*s (len=%u)\n",
+		(int)agpio->resource_source.string_length,
+		agpio->resource_source.string_ptr ? agpio->resource_source.string_ptr : "<NULL>",
+		agpio->resource_source.string_length);
+
 	if (!agpio->resource_source.string_length)
 		return 1; /* no named controller, skip */
 
 	status = acpi_get_handle(NULL, agpio->resource_source.string_ptr, &handle);
-	if (ACPI_FAILURE(status))
+	if (ACPI_FAILURE(status)) {
+		pr_info("i2c-dw-gpio-dbg: acpi_get_handle() failed for %.*s\n",
+			(int)agpio->resource_source.string_length,
+			agpio->resource_source.string_ptr ? agpio->resource_source.string_ptr : "<NULL>");
 		return 1;
+	}
 
 	gpio_adev = acpi_fetch_acpi_dev(handle);
-	if (!gpio_adev)
+	if (!gpio_adev) {
+		pr_info("i2c-dw-gpio-dbg: acpi_fetch_acpi_dev() returned NULL\n");
 		return 1;
+	}
+	pr_info("i2c-dw-gpio-dbg: acpi_fetch_acpi_dev() succeeded, device=%s\n", dev_name(&gpio_adev->dev));
 
 	struct gpio_device *gdev __free(gpio_device_put) =
 		gpio_device_find_by_fwnode(acpi_fwnode_handle(gpio_adev));
-	if (!gdev)
+	if (!gdev) {
+		pr_info("i2c-dw-gpio-dbg: gpio_device_find_by_fwnode() returned NULL, deferring\n");
 		return -EPROBE_DEFER; /* controller not registered yet: abort walk */
+	}
+	pr_info("i2c-dw-gpio-dbg: gpio_device_find_by_fwnode() succeeded\n");
 
 	gpio_dev = gpio_device_to_device(gdev)->parent;
 
 	guard(device)(gpio_dev);
-	if (!device_is_bound(gpio_dev))
+	if (!device_is_bound(gpio_dev)) {
+		pr_info("i2c-dw-gpio-dbg: device_is_bound()=false for %s, deferring\n",
+			dev_name(gpio_dev));
 		return -EPROBE_DEFER; /* controller not bound yet: abort walk */
+	}
+	pr_info("i2c-dw-gpio-dbg: device_is_bound()=true for %s\n", dev_name(gpio_dev));
 
 	return 1; /* bound, skip adding to resource list, continue walk */
 }
@@ -180,9 +199,13 @@ static int check_child_gpioint(struct acpi_device *adev, void *data)
 	LIST_HEAD(res_list);
 	int ret;
 
+	pr_info("i2c-dw-gpio-dbg: check_child_gpioint(adev=%s)\n", dev_name(&adev->dev));
+
 	ret = acpi_dev_get_resources(adev, &res_list, check_gpioint_resource, NULL);
-	if (ret < 0)
+	if (ret < 0) {
+		pr_info("i2c-dw-gpio-dbg: check_child_gpioint ret=%d (defer)\n", ret);
 		return ret;
+	}
 
 	acpi_dev_free_resource_list(&res_list);
 
@@ -194,9 +217,13 @@ static int i2c_dw_check_gpio_dependencies(struct device *dev)
 	struct acpi_device *adev;
 
 	adev = ACPI_COMPANION(dev);
-	if (!adev)
+	if (!adev) {
+		pr_info("i2c-dw-gpio-dbg: i2c_dw_check_gpio_dependencies(%s) ACPI_COMPANION=NULL\n",
+			dev_name(dev));
 		return 0;
+	}
 
+	pr_info("i2c-dw-gpio-dbg: i2c_dw_check_gpio_dependencies(%s)\n", dev_name(dev));
 	return acpi_dev_for_each_child(adev, check_child_gpioint, NULL);
 }
 #else

Re: i2c designware change broke touchpad of a thinkpad

[Thorsten Leemhuis]

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 <linux@leemhuis.info> 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
> 

Re: i2c designware change broke touchpad of a thinkpad

[Hardik Prakash]

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.

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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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
> >
>

Re: i2c designware change broke touchpad of a thinkpad

[Thorsten Leemhuis]

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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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
>>>
>>
> 

Re: i2c designware change broke touchpad of a thinkpad

[Hardik Prakash]

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.

Thanks,
Hardik

On Mon, 10 Aug 2026 at 11:06, Thorsten Leemhuis <linux@leemhuis.info> 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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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
> >>>
> >>
> >
>

Re: i2c designware change broke touchpad of a thinkpad

[Thorsten Leemhuis]

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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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
>>>>>
>>>>
>>>
>>
> 

Re: i2c designware change broke touchpad of a thinkpad

[Hardik Prakash]

On Mon, 10 Aug 2026, Thorsten Leemhuis wrote:
> 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

Thanks. Second boot reproduces the identical pattern: device_is_bound()
=true at 1.132s, lost arbitration at 2.139s -- same ~1s gap as the first
capture, so this is consistent and reproducible, not a one-off.

interrupts rules out simple IRQ-line sharing: AMDI0010:01 has its own
dedicated line (IRQ 11), separate from AMDI0010:00 (IRQ 10) and every
amd_gpio ACPI:Event line. psp-1 exists (IR-PCI-MSIX-0000:c3:00.2) but
shows zero recorded activity on any CPU.

Since lost arbitration means an actual SDA/SCL-level collision (not an
IRQ conflict), and there's no shared IRQ or visible PSP activity, if
something else is touching this bus it's happening below what Linux's
interrupt accounting can see -- which is why I wanted your take, Mario.
Does this match a known pattern of firmware (PSP/EC) briefly taking
this bus during boot on AMD platforms?

Thanks,
Hardik

On Mon, 10 Aug 2026 at 12:18, Thorsten Leemhuis <linux@leemhuis.info> wrote:
>
> 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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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
> >>>>>
> >>>>
> >>>
> >>
> >
>

Re: i2c designware change broke touchpad of a thinkpad

[Thorsten Leemhuis]

On 8/12/26 06:59, Hardik Prakash wrote:
> On Mon, 10 Aug 2026, Thorsten Leemhuis wrote:
>> 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
> 
> Thanks. Second boot reproduces the identical pattern: device_is_bound()
> =true at 1.132s, lost arbitration at 2.139s -- same ~1s gap as the first
> capture, so this is consistent and reproducible, not a one-off.
> 
> interrupts rules out simple IRQ-line sharing: AMDI0010:01 has its own
> dedicated line (IRQ 11), separate from AMDI0010:00 (IRQ 10) and every
> amd_gpio ACPI:Event line. psp-1 exists (IR-PCI-MSIX-0000:c3:00.2) but
> shows zero recorded activity on any CPU.
> 
> Since lost arbitration means an actual SDA/SCL-level collision (not an
> IRQ conflict), and there's no shared IRQ or visible PSP activity, if
> something else is touching this bus it's happening below what Linux's
> interrupt accounting can see -- which is why I wanted your take, Mario.
> Does this match a known pattern of firmware (PSP/EC) briefly taking
> this bus during boot on AMD platforms?

Thx again. While we wait for Mario a quick question: Should we revert
the culprit for 7.2 and reapply it later once we sorted this out? Of
course I'll continue to help debugging this.

If it was just me I'd say "don't bother", but these kind of Thinkpads
are what some Linux users frequently buy, so I fear that other people
will run into this if the culprit makes it into 7.2.

Ciao, Thorsten

> On Mon, 10 Aug 2026 at 12:18, Thorsten Leemhuis <linux@leemhuis.info> wrote:
>>
>> 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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

Re: i2c designware change broke touchpad of a thinkpad

[Hardik Prakash]

On Wed, 12 Aug 2026, Thorsten Leemhuis wrote:
> While we wait for Mario a quick question: Should we revert
> the culprit for 7.2 and reapply it later once we sorted this out? Of
> course I'll continue to help debugging this.
>
> If it was just me I'd say "don't bother", but these kind of Thinkpads
> are what some Linux users frequently buy, so I fear that other people
> will run into this if the culprit makes it into 7.2.

I agreed, I'd rather have this reverted than ship a known regression.

Andi, WSA -- given 7.2 is close, could this go out as a revert now? I'll
keep working the AMD bus-timing angle with Thorsten and Mario, and
we can resubmit a corrected fix for a later release once it's actually
understood.

Thanks,
Hardik

On Wed, 12 Aug 2026 at 10:51, Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> On 8/12/26 06:59, Hardik Prakash wrote:
> > On Mon, 10 Aug 2026, Thorsten Leemhuis wrote:
> >> 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
> >
> > Thanks. Second boot reproduces the identical pattern: device_is_bound()
> > =true at 1.132s, lost arbitration at 2.139s -- same ~1s gap as the first
> > capture, so this is consistent and reproducible, not a one-off.
> >
> > interrupts rules out simple IRQ-line sharing: AMDI0010:01 has its own
> > dedicated line (IRQ 11), separate from AMDI0010:00 (IRQ 10) and every
> > amd_gpio ACPI:Event line. psp-1 exists (IR-PCI-MSIX-0000:c3:00.2) but
> > shows zero recorded activity on any CPU.
> >
> > Since lost arbitration means an actual SDA/SCL-level collision (not an
> > IRQ conflict), and there's no shared IRQ or visible PSP activity, if
> > something else is touching this bus it's happening below what Linux's
> > interrupt accounting can see -- which is why I wanted your take, Mario.
> > Does this match a known pattern of firmware (PSP/EC) briefly taking
> > this bus during boot on AMD platforms?
>
> Thx again. While we wait for Mario a quick question: Should we revert
> the culprit for 7.2 and reapply it later once we sorted this out? Of
> course I'll continue to help debugging this.
>
> If it was just me I'd say "don't bother", but these kind of Thinkpads
> are what some Linux users frequently buy, so I fear that other people
> will run into this if the culprit makes it into 7.2.
>
> Ciao, Thorsten
>
> > On Mon, 10 Aug 2026 at 12:18, Thorsten Leemhuis <linux@leemhuis.info> wrote:
> >>
> >> 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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>

Re: i2c designware change broke touchpad of a thinkpad

[Mario Limonciello]

On 8/12/26 00:45, Hardik Prakash wrote:
> On Wed, 12 Aug 2026, Thorsten Leemhuis wrote:
>> While we wait for Mario a quick question: Should we revert
>> the culprit for 7.2 and reapply it later once we sorted this out? Of
>> course I'll continue to help debugging this.
>>
>> If it was just me I'd say "don't bother", but these kind of Thinkpads
>> are what some Linux users frequently buy, so I fear that other people
>> will run into this if the culprit makes it into 7.2.
> 
> I agreed, I'd rather have this reverted than ship a known regression.
> 
> Andi, WSA -- given 7.2 is close, could this go out as a revert now? I'll
> keep working the AMD bus-timing angle with Thorsten and Mario, and
> we can resubmit a corrected fix for a later release once it's actually
> understood.

Let's please revert for 7.2 final and keep working at this.

I've got a /hunch/ what's going on.

For both Dell and Lenovo I know a lot of designs have these I2C buses 
that have both the EC and the APU connected to them.  "Both" the EC and 
APU "can" operate as master.

The reason that this exists is so that when the system is in pre-boot 
the EC acts as master.  This lets you use the touchpad in the BIOS menus 
for example.  When the OS boots up there is some ASL called which sends 
an EC command that tells the EC to stand down.  At this point the APU 
takes over and acts as master.

So my theory here is that by changing this ordering the _DSM is not 
called at the right timing anymore.

This is a fairly similar issue as was seen that led to this commit:

https://git.kernel.org/torvalds/c/7d62beb102d6f
> 
> Thanks,
> Hardik
> 
> On Wed, 12 Aug 2026 at 10:51, Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
>>
>> On 8/12/26 06:59, Hardik Prakash wrote:
>>> On Mon, 10 Aug 2026, Thorsten Leemhuis wrote:
>>>> 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
>>>
>>> Thanks. Second boot reproduces the identical pattern: device_is_bound()
>>> =true at 1.132s, lost arbitration at 2.139s -- same ~1s gap as the first
>>> capture, so this is consistent and reproducible, not a one-off.
>>>
>>> interrupts rules out simple IRQ-line sharing: AMDI0010:01 has its own
>>> dedicated line (IRQ 11), separate from AMDI0010:00 (IRQ 10) and every
>>> amd_gpio ACPI:Event line. psp-1 exists (IR-PCI-MSIX-0000:c3:00.2) but
>>> shows zero recorded activity on any CPU.
>>>
>>> Since lost arbitration means an actual SDA/SCL-level collision (not an
>>> IRQ conflict), and there's no shared IRQ or visible PSP activity, if
>>> something else is touching this bus it's happening below what Linux's
>>> interrupt accounting can see -- which is why I wanted your take, Mario.
>>> Does this match a known pattern of firmware (PSP/EC) briefly taking
>>> this bus during boot on AMD platforms?
>>
>> Thx again. While we wait for Mario a quick question: Should we revert
>> the culprit for 7.2 and reapply it later once we sorted this out? Of
>> course I'll continue to help debugging this.
>>
>> If it was just me I'd say "don't bother", but these kind of Thinkpads
>> are what some Linux users frequently buy, so I fear that other people
>> will run into this if the culprit makes it into 7.2.
>>
>> Ciao, Thorsten
>>
>>> On Mon, 10 Aug 2026 at 12:18, Thorsten Leemhuis <linux@leemhuis.info> wrote:
>>>>
>>>> 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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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 <linux@leemhuis.info> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>