[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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

Re: i2c designware change broke touchpad of a thinkpad

[Hardik Prakash]

On Wed, 12 Aug 2026, Mario Limonciello wrote:
> This is a fairly similar issue as was seen that led to this commit:
> https://git.kernel.org/torvalds/c/7d62beb102d6f

That fits well -- Thorsten's failure is on i2c_hid_acpi's first Get
Descriptor call specifically, the same transaction that commit ties
to the EC standdown _DSM.

One thing I can't narrow down: my check adds a delay (bound confirmed
at 1.136s), but the actual failure isn't until 2.222s -- over a
second later. A delay landing things later should only cause contention
if crossing some threshold matters, e.g. an EC failsafe that reclaims
the bus if the OS driver hasn't checked in within some window, or
periodic EC polling that our new timing happens to land on top of.
Is either of those a known behavior on this class of hardware? If so
that would explain why earlier (unpatched) timing avoided it and
later (patched) timing doesn't.

If the fix isn't in my dependency check itself, I'm open to hearing
where it should live instead.

Thanks,
Hardik

On Wed, 12 Aug 2026 at 18:05, Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> 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
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>

Re: i2c designware change broke touchpad of a thinkpad

[Thorsten Leemhuis]

On 8/12/26 14:34, Mario Limonciello wrote:
> 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.

Can't see any messages from Andi on lore in the past week and just one
from WSA. Guess well deserved holiday season or something like that.
Happens, no worries, but I guess we thus should try to handle this on
our own.

Hardik, could you submit a revert to the lists? And then I'll provide my
Tested-by and ask Linus to directly pick this up? In a case like this I
guess that is one of the viable options. Or does anyone see a better
path forward here?

Ciao, Thorsten
> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
> 

Re: i2c designware change broke touchpad of a thinkpad

[Hardik Prakash]

On Wed, 13 Aug 2026, Thorsten Leemhuis wrote:
> Hardik, could you submit a revert to the lists? And then I'll provide my
> Tested-by and ask Linus to directly pick this up?

Sent: https://lore.kernel.org/all/20260814100719.9548-1-hardikprakash.official@gmail.com/

Verified on my end that it builds clean, boots clean, and correctly
restores the original Yoga 7 race (expected tradeoff) without
introducing anything else.

Thanks,
Hardik

On Thu, 13 Aug 2026 at 16:26, Thorsten Leemhuis <linux@leemhuis.info> wrote:
>
> On 8/12/26 14:34, Mario Limonciello wrote:
> > 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.
>
> Can't see any messages from Andi on lore in the past week and just one
> from WSA. Guess well deserved holiday season or something like that.
> Happens, no worries, but I guess we thus should try to handle this on
> our own.
>
> Hardik, could you submit a revert to the lists? And then I'll provide my
> Tested-by and ask Linus to directly pick this up? In a case like this I
> guess that is one of the viable options. Or does anyone see a better
> path forward here?
>
> Ciao, Thorsten
> > 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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
>

Re: i2c designware change broke touchpad of a thinkpad

[johannes.goede]

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

Hi Hardik,

On 14-Aug-26 12:09 PM, Hardik Prakash wrote:
> On Wed, 13 Aug 2026, Thorsten Leemhuis wrote:
>> Hardik, could you submit a revert to the lists? And then I'll provide my
>> Tested-by and ask Linus to directly pick this up?
> 
> Sent: https://lore.kernel.org/all/20260814100719.9548-1-hardikprakash.official@gmail.com/
> 
> Verified on my end that it builds clean, boots clean, and correctly
> restores the original Yoga 7 race (expected tradeoff) without
> introducing anything else.

Thank you for submitting a revert for this. Note it looks like Torvalds himself
beat you to it and already reverted this for 7.2 final :)

I hit another problem caused by this now reverted change, where the PMIC
i2c bus would not show up on many Intel BYT/CHT devices. I wrote a fix for
this (attached) on top of the now reverted commit.

I think my fix might also have helped for the broken touchpad issue from this
thread, but I believe there is a better way to fix all this, so IMHO it is
good that this was reverted.

If I understand things correctly the problem the reverted fix was trying
to fix is i2c-transfer errors happening before the GPIO controller driver
is ready.

The i2c-core will not initiate transfers itself, so the problem is that
the i2c-hid driver is initiating transfers before the GPIO controller
is setup.

The i2c-hid driver does actually request the interrupt itself, so we can
simply wait for that to succeed inside the i2c-hid code. ATM the i2c-hid
code starts with an i2c-connectivity check because some ACPI tables list
non existing I2C-HID devices.

But we could make the i2c-hid driver start with first requesting its IRQ
and if that fails bail (with -EPROBE_DEFER) before doing any i2c-transfers.

And then do the i2c-connectivity test after requesting the IRQ. So basically
swap the order of i2c-connectivity test vs IRQ requesting.

The IRQ requesting should then use the IRQF_NO_AUTOEN flag to keep the IRQ
disabled at first and explicitly enable it later when the rest of the driver
setup is done.

Hardik, can you take a shot at coding up the suggested i2c-hid(-core) changes
and test to see if this fixes the original Yoga 7 race in a cleaner manner ?

Regards,

Hans


[-- Attachment #2: 0001-i2c-designware-Make-check_child_gpioint-skip-devices.patch --]
[-- Type: text/x-patch, Size: 2339 bytes --]

From e12a71c64b996560d521ea9dda31a8c629b504e4 Mon Sep 17 00:00:00 2001
From: Hans de Goede <johannes.goede@oss.qualcomm.com>
Date: Sun, 16 Aug 2026 23:06:07 +0200
Subject: [PATCH] i2c: designware: Make check_child_gpioint() skip devices
 which are not present

Commit 0a4bb2abc3e5 ("i2c: designware: defer probe if child GpioInt
controllers are not bound") makes i2c-designware-platdrv delay binding
until all GpioInt resources of children of the i2c-controller are
available.

This causes the driver to sometimes never bound in case of bogus, or
not supported by Linux GpioInt resources on some of the i2c-clients of
the controller, which causes *all* of the clients to not work!

ACPI tables typically contain descriptions of many possible i2c-clients
under an i2c-controller (e.g. second sources of devices) but only
a few are actually marked as being present. The kernel will only
instantiate i2c-clients for those which are present, make the GpioInt
"ready" check only check actually present i2c-clients.

Intel BYT/CHT devices have a special INT33FE i2c-client which is
a duplicate of the exisiting PMIC i2c-client, with non supported
GpioInt resources (pointing back to the PMIC). Linux already ignores
these, so make the GpioInt check skip these too.

This fixes i2c-designware-platdrv not binding to the PMIC I2C bus on many
Intel Bay Trail and Cherry Trail devices like e.g. the MPman Convertor9.

Fixes: 0a4bb2abc3e5 ("i2c: designware: defer probe if child GpioInt controllers are not bound")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index c8a203fff4d1..f80817e6221d 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -180,6 +180,13 @@ static int check_child_gpioint(struct acpi_device *adev, void *data)
 	LIST_HEAD(res_list);
 	int ret;
 
+	if (!adev->status.present)
+		return 0;
+
+	/* Skip broken Intel BYT/CHT INT33FE battery devices */
+	if (acpi_dev_hid_match(adev, "INT33FE"))
+		return 0;
+
 	ret = acpi_dev_get_resources(adev, &res_list, check_gpioint_resource, NULL);
 	if (ret < 0)
 		return ret;
-- 
2.55.0

Re: i2c designware change broke touchpad of a thinkpad

[Thorsten Leemhuis]

On 8/17/26 11:51, johannes.goede@oss.qualcomm.com wrote:
> On 14-Aug-26 12:09 PM, Hardik Prakash wrote:
>> On Wed, 13 Aug 2026, Thorsten Leemhuis wrote:
>>> Hardik, could you submit a revert to the lists? And then I'll provide my
>>> Tested-by and ask Linus to directly pick this up?
>>
>> Sent: https://lore.kernel.org/all/20260814100719.9548-1-hardikprakash.official@gmail.com/
>>
>> Verified on my end that it builds clean, boots clean, and correctly
>> restores the original Yoga 7 race (expected tradeoff) without
>> introducing anything else.

Hans, thx for looking into this.
> Thank you for submitting a revert for this. Note it looks like Torvalds himself
> beat you to it and already reverted this for 7.2 final :)

Yeah, I pointed Linus to this and a few others issues and then he
reverted the change directly:
https://lore.kernel.org/all/628bbf10-29f1-4e9e-b23b-4c47657433b9@leemhuis.info/

> I hit another problem caused by this now reverted change, where the PMIC
> i2c bus would not show up on many Intel BYT/CHT devices. I wrote a fix for
> this (attached) on top of the now reverted commit.

FWIW, meanwhile "Tran Tien Dat" (now CCed) with -next ran into a problem
on a MSI Modern 14 H D13MG that the revert seems to have resolved. But
the symptoms were different: the two DesignWare I2C controllers in that
machine apparently deferred probe forever and are never retried:

16.429266 platform i2c_designware.1: deferred probe pending: (reason
unknown)
16.429286 platform i2c_designware.0: deferred probe pending: (reason
unknown)

For details, see: https://bugzilla.kernel.org/show_bug.cgi?id=221889

Ciao, Thorsten

> I think my fix might also have helped for the broken touchpad issue from this
> thread, but I believe there is a better way to fix all this, so IMHO it is
> good that this was reverted.
> 
> If I understand things correctly the problem the reverted fix was trying
> to fix is i2c-transfer errors happening before the GPIO controller driver
> is ready.
> 
> The i2c-core will not initiate transfers itself, so the problem is that
> the i2c-hid driver is initiating transfers before the GPIO controller
> is setup.
> 
> The i2c-hid driver does actually request the interrupt itself, so we can
> simply wait for that to succeed inside the i2c-hid code. ATM the i2c-hid
> code starts with an i2c-connectivity check because some ACPI tables list
> non existing I2C-HID devices.
> 
> But we could make the i2c-hid driver start with first requesting its IRQ
> and if that fails bail (with -EPROBE_DEFER) before doing any i2c-transfers.
> 
> And then do the i2c-connectivity test after requesting the IRQ. So basically
> swap the order of i2c-connectivity test vs IRQ requesting.
> 
> The IRQ requesting should then use the IRQF_NO_AUTOEN flag to keep the IRQ
> disabled at first and explicitly enable it later when the rest of the driver
> setup is done.
> 
> Hardik, can you take a shot at coding up the suggested i2c-hid(-core) changes
> and test to see if this fixes the original Yoga 7 race in a cleaner manner ?
> 
> Regards,
> 
> Hans
> 

Re: i2c designware change broke touchpad of a thinkpad

[Tiến Đạt Trần]

Thanks for the detailed background, Thorsten and Hans.

Confirming I'm now on this thread. For reference, the bug I reported
(deferred probe on both i2c_designware.0 and .1, ELAN0307 touchpad
never coming up) is tracked here:
https://bugzilla.kernel.org/show_bug.cgi?id=221889

With Linus's revert (d5b95e612cde) applied on top of 7.2 final, my
system is working correctly again — both i2c_designware controllers
probe successfully (~2.80s), the touchpad registers via hid-multitouch,
and /sys/kernel/debug/devices_deferred is empty.

Happy to test Hardik's upcoming i2c-hid-core patch (the IRQ-request-
before-connectivity-check approach Hans described) on this hardware
once it's ready, and report back whether it resolves the original
issue without reintroducing the deferred-probe regression.

Let me know when there's something to test.

Best regards,
Tran Tien Dat


Vào Thứ 2, 17 thg 8, 2026 vào lúc 18:12 Thorsten Leemhuis
<regressions@leemhuis.info> đã viết:
>
> On 8/17/26 11:51, johannes.goede@oss.qualcomm.com wrote:
> > On 14-Aug-26 12:09 PM, Hardik Prakash wrote:
> >> On Wed, 13 Aug 2026, Thorsten Leemhuis wrote:
> >>> Hardik, could you submit a revert to the lists? And then I'll provide my
> >>> Tested-by and ask Linus to directly pick this up?
> >>
> >> Sent: https://lore.kernel.org/all/20260814100719.9548-1-hardikprakash.official@gmail.com/
> >>
> >> Verified on my end that it builds clean, boots clean, and correctly
> >> restores the original Yoga 7 race (expected tradeoff) without
> >> introducing anything else.
>
> Hans, thx for looking into this.
> > Thank you for submitting a revert for this. Note it looks like Torvalds himself
> > beat you to it and already reverted this for 7.2 final :)
>
> Yeah, I pointed Linus to this and a few others issues and then he
> reverted the change directly:
> https://lore.kernel.org/all/628bbf10-29f1-4e9e-b23b-4c47657433b9@leemhuis.info/
>
> > I hit another problem caused by this now reverted change, where the PMIC
> > i2c bus would not show up on many Intel BYT/CHT devices. I wrote a fix for
> > this (attached) on top of the now reverted commit.
>
> FWIW, meanwhile "Tran Tien Dat" (now CCed) with -next ran into a problem
> on a MSI Modern 14 H D13MG that the revert seems to have resolved. But
> the symptoms were different: the two DesignWare I2C controllers in that
> machine apparently deferred probe forever and are never retried:
>
> 16.429266 platform i2c_designware.1: deferred probe pending: (reason
> unknown)
> 16.429286 platform i2c_designware.0: deferred probe pending: (reason
> unknown)
>
> For details, see: https://bugzilla.kernel.org/show_bug.cgi?id=221889
>
> Ciao, Thorsten
>
> > I think my fix might also have helped for the broken touchpad issue from this
> > thread, but I believe there is a better way to fix all this, so IMHO it is
> > good that this was reverted.
> >
> > If I understand things correctly the problem the reverted fix was trying
> > to fix is i2c-transfer errors happening before the GPIO controller driver
> > is ready.
> >
> > The i2c-core will not initiate transfers itself, so the problem is that
> > the i2c-hid driver is initiating transfers before the GPIO controller
> > is setup.
> >
> > The i2c-hid driver does actually request the interrupt itself, so we can
> > simply wait for that to succeed inside the i2c-hid code. ATM the i2c-hid
> > code starts with an i2c-connectivity check because some ACPI tables list
> > non existing I2C-HID devices.
> >
> > But we could make the i2c-hid driver start with first requesting its IRQ
> > and if that fails bail (with -EPROBE_DEFER) before doing any i2c-transfers.
> >
> > And then do the i2c-connectivity test after requesting the IRQ. So basically
> > swap the order of i2c-connectivity test vs IRQ requesting.
> >
> > The IRQ requesting should then use the IRQF_NO_AUTOEN flag to keep the IRQ
> > disabled at first and explicitly enable it later when the rest of the driver
> > setup is done.
> >
> > Hardik, can you take a shot at coding up the suggested i2c-hid(-core) changes
> > and test to see if this fixes the original Yoga 7 race in a cleaner manner ?
> >
> > Regards,
> >
> > Hans
> >
>

Re: i2c designware change broke touchpad of a thinkpad

[johannes.goede]

Hi Thorsten,

On 17-Aug-26 1:12 PM, Thorsten Leemhuis wrote:
> On 8/17/26 11:51, johannes.goede@oss.qualcomm.com wrote:
>> On 14-Aug-26 12:09 PM, Hardik Prakash wrote:
>>> On Wed, 13 Aug 2026, Thorsten Leemhuis wrote:
>>>> Hardik, could you submit a revert to the lists? And then I'll provide my
>>>> Tested-by and ask Linus to directly pick this up?
>>>
>>> Sent: https://lore.kernel.org/all/20260814100719.9548-1-hardikprakash.official@gmail.com/
>>>
>>> Verified on my end that it builds clean, boots clean, and correctly
>>> restores the original Yoga 7 race (expected tradeoff) without
>>> introducing anything else.
> 
> Hans, thx for looking into this.
>> Thank you for submitting a revert for this. Note it looks like Torvalds himself
>> beat you to it and already reverted this for 7.2 final :)
> 
> Yeah, I pointed Linus to this and a few others issues and then he
> reverted the change directly:
> https://lore.kernel.org/all/628bbf10-29f1-4e9e-b23b-4c47657433b9@leemhuis.info/
> 
>> I hit another problem caused by this now reverted change, where the PMIC
>> i2c bus would not show up on many Intel BYT/CHT devices. I wrote a fix for
>> this (attached) on top of the now reverted commit.
> 
> FWIW, meanwhile "Tran Tien Dat" (now CCed) with -next ran into a problem
> on a MSI Modern 14 H D13MG that the revert seems to have resolved. But
> the symptoms were different: the two DesignWare I2C controllers in that
> machine apparently deferred probe forever and are never retried:
> 
> 16.429266 platform i2c_designware.1: deferred probe pending: (reason
> unknown)
> 16.429286 platform i2c_designware.0: deferred probe pending: (reason
> unknown)

Right, that is actually the same thing which my patch (on top of the
non-reverted original commit) addresses on BYT / CHT devices.

When I wrote "the PMIC i2c bus would not show up" I meant that
the i2c-controller for that bus would never get registered with
the kernel because of the probe being deferred forever.

Regards,

Hans