[PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

Patch 1/2 (pinctrl-amd GPIO IRQ fix) is already in Linus Walleij's
tree. This series contains only the i2c-designware probe ordering fix,
based on top of that commit.

The root cause: i2c_designware probes AMDI0010:02 before pinctrl-amd
completes, so GPIO 157 (WACF2200 GpioInt per ACPI _CRS) has its
interrupt bits cleared when the first I2C transaction is attempted,
causing lost arbitration errors.

A higher-level ACPI devlink approach was investigated in response to
Bartosz Golaszewski's suggestion. The DSDT has no _DEP object linking
AMDI0010:02 to AMDI0030:00, so fw_devlink has nothing to act on.
Setting this up at the ACPI layer would require either a firmware
change to add _DEP, or a DMI quirk in the ACPI scan path — equally
quirk-based as the current approach.

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

v4:
 - Rebase onto Linus Walleij's tree (patch 1 already there)
 - Use --base so series is correctly 1/1 (Andy Shevchenko)
 - Add subsys_initcall test results (Mario Limonciello)

v3:
 - Fix variable declaration style in dw_i2c_needs_amd_gpio_dep (Andy Shevchenko)
 - Add BugLink tag (Andy Shevchenko)
 - Add -v3 subject versioning (Andy Shevchenko)
 - CC AMD engineers (Andy Shevchenko)

v2:
 - Replace custom HID/UID lookup with acpi_dev_get_first_match_dev() (Andy Shevchenko)
 - Use acpi_get_first_physical_node() for platform device lookup
 - Use device_is_bound() under device_lock() with explanatory comments
 - Fix dev_warn to use dev_name() instead of hardcoded suffix
 - Fix commit message (removed incorrect "existing" reference)
 - Add Assisted-by tags per coding-assistants.rst

Kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=221494
Related: https://bugzilla.kernel.org/show_bug.cgi?id=221454

Hardik Prakash (1):
  i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7
    14AGP11

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

base-commit: 3812a9e84265a5cdd90d29fe8d97a023e91fb945

[PATCH v5 1/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

On Lenovo Yoga 7 14AGP11 (83TD), the WACF2200 touchscreen fails with
lost arbitration errors on AMDI0010:02 at boot. The root cause is a
probe ordering issue: i2c_designware probes AMDI0010:02 before
pinctrl-amd has finished initialising, so the GPIO 157 interrupt
needed by the touchscreen is not yet enabled.

Add a DMI-matched deferral in dw_i2c_plat_probe() that uses
device_is_bound() under device_lock() to correctly wait until
pinctrl-amd's probe has fully completed. Use acpi_dev_get_first_match_dev()
for robust HID/UID-based GPIO controller lookup instead of string
name matching.

Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
Assisted-by: Claude:claude-sonnet-4-6
Assisted-by: GPT-Codex:gpt-5.2-codex
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=221494
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 76 +++++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 3351c4a9ef118..d09cd47bf4b9b 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -8,6 +8,8 @@
  * 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>
@@ -86,6 +88,76 @@ static const struct dmi_system_id dw_i2c_hwmon_class_dmi[] = {
 	{ } /* terminate list */
 };
 
+static const struct dmi_system_id dw_i2c_amd_gpio_defer_dmi[] = {
+	{
+		.ident = "Lenovo Yoga 7 14AGP11",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "83TD"),
+			DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216"),
+		},
+	},
+	{ } /* terminate list */
+};
+
+static bool dw_i2c_needs_amd_gpio_dep(struct device *device)
+{
+	struct acpi_device *adev;
+
+	if (!dmi_check_system(dw_i2c_amd_gpio_defer_dmi))
+		return false;
+
+	adev = ACPI_COMPANION(device);
+	if (!adev)
+		return false;
+
+	return acpi_dev_hid_uid_match(adev, "AMDI0010", "2");
+}
+
+static int dw_i2c_defer_for_amd_gpio(struct device *device)
+{
+	struct acpi_device *gpio_adev;
+	struct device *gpio_dev;
+
+	if (!dw_i2c_needs_amd_gpio_dep(device))
+		return 0;
+
+	/*
+	 * Find the AMD GPIO controller by HID/UID and get its physical
+	 * platform device. We need the platform device (not the ACPI device)
+	 * because that is what gets bound by the amd_gpio driver.
+	 */
+	gpio_adev = acpi_dev_get_first_match_dev("AMDI0030", "0", -1);
+	if (!gpio_adev)
+		return -EPROBE_DEFER;
+
+	gpio_dev = acpi_get_first_physical_node(gpio_adev);
+	acpi_dev_put(gpio_adev);
+	if (!gpio_dev)
+		return -EPROBE_DEFER;
+
+	/*
+	 * Check that amd_gpio probe has fully completed, not just that the
+	 * driver pointer is set. The driver pointer is assigned before probe
+	 * finishes, so checking it would allow i2c_designware to probe before
+	 * the GPIO IRQ quirk in amd_gpio_probe() has run.
+	 */
+	scoped_guard(device, gpio_dev) {
+		if (!device_is_bound(gpio_dev))
+			return -EPROBE_DEFER;
+	}
+
+	/*
+	 * Create a device link so the driver core enforces probe/remove
+	 * ordering between this I2C controller and the GPIO controller.
+	 */
+	if (!device_link_add(device, gpio_dev, DL_FLAG_AUTOREMOVE_CONSUMER))
+		dev_warn(device, "failed to add device link to %s\n",
+			 dev_name(gpio_dev));
+
+	return 0;
+}
+
 static const struct i2c_dw_semaphore_callbacks i2c_dw_semaphore_cb_table[] = {
 #ifdef CONFIG_I2C_DESIGNWARE_BAYTRAIL
 	{
@@ -138,6 +210,10 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
 	struct dw_i2c_dev *dev;
 	int irq, ret;
 
+	ret = dw_i2c_defer_for_amd_gpio(device);
+	if (ret)
+		return ret;
+
 	irq = platform_get_irq_optional(pdev, 0);
 	if (irq == -ENXIO)
 		flags |= ACCESS_POLLING;
-- 
2.54.0

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Mario Limonciello]

On 5/18/26 07:28, Hardik Prakash wrote:
> Patch 1/2 (pinctrl-amd GPIO IRQ fix) is already in Linus Walleij's
> tree. This series contains only the i2c-designware probe ordering fix,
> based on top of that commit.
> 
> The root cause: i2c_designware probes AMDI0010:02 before pinctrl-amd
> completes, so GPIO 157 (WACF2200 GpioInt per ACPI _CRS) has its
> interrupt bits cleared when the first I2C transaction is attempted,
> causing lost arbitration errors.
> 
> A higher-level ACPI devlink approach was investigated in response to
> Bartosz Golaszewski's suggestion. The DSDT has no _DEP object linking
> AMDI0010:02 to AMDI0030:00, so fw_devlink has nothing to act on.
> Setting this up at the ACPI layer would require either a firmware
> change to add _DEP, or a DMI quirk in the ACPI scan path — equally
> quirk-based as the current approach.

I'd still like to avoid a quirk if we can.

I know my proposed patch to try to probe at an earlier stage didn't 
work, but could you perhaps try pulling pinctrl-amd even earlier?

Maybe fs_initcall()?

> 
> v5:
>   - Add blank line before #include <linux/acpi.h> (Bartosz Golaszewski)
>   - Use scoped_guard(device, gpio_dev) (Bartosz Golaszewski)
> 
> v4:
>   - Rebase onto Linus Walleij's tree (patch 1 already there)
>   - Use --base so series is correctly 1/1 (Andy Shevchenko)
>   - Add subsys_initcall test results (Mario Limonciello)
> 
> v3:
>   - Fix variable declaration style in dw_i2c_needs_amd_gpio_dep (Andy Shevchenko)
>   - Add BugLink tag (Andy Shevchenko)
>   - Add -v3 subject versioning (Andy Shevchenko)
>   - CC AMD engineers (Andy Shevchenko)
> 
> v2:
>   - Replace custom HID/UID lookup with acpi_dev_get_first_match_dev() (Andy Shevchenko)
>   - Use acpi_get_first_physical_node() for platform device lookup
>   - Use device_is_bound() under device_lock() with explanatory comments
>   - Fix dev_warn to use dev_name() instead of hardcoded suffix
>   - Fix commit message (removed incorrect "existing" reference)
>   - Add Assisted-by tags per coding-assistants.rst
> 
> Kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=221494
> Related: https://bugzilla.kernel.org/show_bug.cgi?id=221454
> 
> Hardik Prakash (1):
>    i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7
>      14AGP11
> 
>   drivers/i2c/busses/i2c-designware-platdrv.c | 76 +++++++++++++++++++++
>   1 file changed, 76 insertions(+)
> 
> base-commit: 3812a9e84265a5cdd90d29fe8d97a023e91fb945

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
> I'd still like to avoid a quirk if we can.
>
> I know my proposed patch to try to probe at an earlier stage didn't
> work, but could you perhaps try pulling pinctrl-amd even earlier?
>
> Maybe fs_initcall()?

Tested. fs_initcall + patch 1 still produces the same arbitration
errors:

  subsys_initcall + patch 1:   arbitration errors persist
  fs_initcall + patch 1:       arbitration errors persist
  patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional

The initcall level does not appear to be the determining factor on
this hardware. i2c_designware is still probing AMDI0010:02 before
pinctrl-amd finishes regardless of how early pinctrl-amd registers.
The explicit device_is_bound() deferral in patch 2 is the only
approach that has worked.

Thanks,
Hardik

On Mon, 18 May 2026 at 18:17, Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 5/18/26 07:28, Hardik Prakash wrote:
> > Patch 1/2 (pinctrl-amd GPIO IRQ fix) is already in Linus Walleij's
> > tree. This series contains only the i2c-designware probe ordering fix,
> > based on top of that commit.
> >
> > The root cause: i2c_designware probes AMDI0010:02 before pinctrl-amd
> > completes, so GPIO 157 (WACF2200 GpioInt per ACPI _CRS) has its
> > interrupt bits cleared when the first I2C transaction is attempted,
> > causing lost arbitration errors.
> >
> > A higher-level ACPI devlink approach was investigated in response to
> > Bartosz Golaszewski's suggestion. The DSDT has no _DEP object linking
> > AMDI0010:02 to AMDI0030:00, so fw_devlink has nothing to act on.
> > Setting this up at the ACPI layer would require either a firmware
> > change to add _DEP, or a DMI quirk in the ACPI scan path — equally
> > quirk-based as the current approach.
>
> I'd still like to avoid a quirk if we can.
>
> I know my proposed patch to try to probe at an earlier stage didn't
> work, but could you perhaps try pulling pinctrl-amd even earlier?
>
> Maybe fs_initcall()?
>
> >
> > v5:
> >   - Add blank line before #include <linux/acpi.h> (Bartosz Golaszewski)
> >   - Use scoped_guard(device, gpio_dev) (Bartosz Golaszewski)
> >
> > v4:
> >   - Rebase onto Linus Walleij's tree (patch 1 already there)
> >   - Use --base so series is correctly 1/1 (Andy Shevchenko)
> >   - Add subsys_initcall test results (Mario Limonciello)
> >
> > v3:
> >   - Fix variable declaration style in dw_i2c_needs_amd_gpio_dep (Andy Shevchenko)
> >   - Add BugLink tag (Andy Shevchenko)
> >   - Add -v3 subject versioning (Andy Shevchenko)
> >   - CC AMD engineers (Andy Shevchenko)
> >
> > v2:
> >   - Replace custom HID/UID lookup with acpi_dev_get_first_match_dev() (Andy Shevchenko)
> >   - Use acpi_get_first_physical_node() for platform device lookup
> >   - Use device_is_bound() under device_lock() with explanatory comments
> >   - Fix dev_warn to use dev_name() instead of hardcoded suffix
> >   - Fix commit message (removed incorrect "existing" reference)
> >   - Add Assisted-by tags per coding-assistants.rst
> >
> > Kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=221494
> > Related: https://bugzilla.kernel.org/show_bug.cgi?id=221454
> >
> > Hardik Prakash (1):
> >    i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7
> >      14AGP11
> >
> >   drivers/i2c/busses/i2c-designware-platdrv.c | 76 +++++++++++++++++++++
> >   1 file changed, 76 insertions(+)
> >
> > base-commit: 3812a9e84265a5cdd90d29fe8d97a023e91fb945
>

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Mario Limonciello]

On 5/18/26 08:40, Hardik Prakash wrote:
> On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
>> I'd still like to avoid a quirk if we can.
>>
>> I know my proposed patch to try to probe at an earlier stage didn't
>> work, but could you perhaps try pulling pinctrl-amd even earlier?
>>
>> Maybe fs_initcall()?
> 
> Tested. fs_initcall + patch 1 still produces the same arbitration
> errors:
> 
>    subsys_initcall + patch 1:   arbitration errors persist
>    fs_initcall + patch 1:       arbitration errors persist
>    patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
> 
> The initcall level does not appear to be the determining factor on
> this hardware. i2c_designware is still probing AMDI0010:02 before
> pinctrl-amd finishes regardless of how early pinctrl-amd registers.
> The explicit device_is_bound() deferral in patch 2 is the only
> approach that has worked.

Please try arch_initcall instead.

> 
> Thanks,
> Hardik
> 
> On Mon, 18 May 2026 at 18:17, Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>>
>>
>>
>> On 5/18/26 07:28, Hardik Prakash wrote:
>>> Patch 1/2 (pinctrl-amd GPIO IRQ fix) is already in Linus Walleij's
>>> tree. This series contains only the i2c-designware probe ordering fix,
>>> based on top of that commit.
>>>
>>> The root cause: i2c_designware probes AMDI0010:02 before pinctrl-amd
>>> completes, so GPIO 157 (WACF2200 GpioInt per ACPI _CRS) has its
>>> interrupt bits cleared when the first I2C transaction is attempted,
>>> causing lost arbitration errors.
>>>
>>> A higher-level ACPI devlink approach was investigated in response to
>>> Bartosz Golaszewski's suggestion. The DSDT has no _DEP object linking
>>> AMDI0010:02 to AMDI0030:00, so fw_devlink has nothing to act on.
>>> Setting this up at the ACPI layer would require either a firmware
>>> change to add _DEP, or a DMI quirk in the ACPI scan path — equally
>>> quirk-based as the current approach.
>>
>> I'd still like to avoid a quirk if we can.
>>
>> I know my proposed patch to try to probe at an earlier stage didn't
>> work, but could you perhaps try pulling pinctrl-amd even earlier?
>>
>> Maybe fs_initcall()?
>>
>>>
>>> v5:
>>>    - Add blank line before #include <linux/acpi.h> (Bartosz Golaszewski)
>>>    - Use scoped_guard(device, gpio_dev) (Bartosz Golaszewski)
>>>
>>> v4:
>>>    - Rebase onto Linus Walleij's tree (patch 1 already there)
>>>    - Use --base so series is correctly 1/1 (Andy Shevchenko)
>>>    - Add subsys_initcall test results (Mario Limonciello)
>>>
>>> v3:
>>>    - Fix variable declaration style in dw_i2c_needs_amd_gpio_dep (Andy Shevchenko)
>>>    - Add BugLink tag (Andy Shevchenko)
>>>    - Add -v3 subject versioning (Andy Shevchenko)
>>>    - CC AMD engineers (Andy Shevchenko)
>>>
>>> v2:
>>>    - Replace custom HID/UID lookup with acpi_dev_get_first_match_dev() (Andy Shevchenko)
>>>    - Use acpi_get_first_physical_node() for platform device lookup
>>>    - Use device_is_bound() under device_lock() with explanatory comments
>>>    - Fix dev_warn to use dev_name() instead of hardcoded suffix
>>>    - Fix commit message (removed incorrect "existing" reference)
>>>    - Add Assisted-by tags per coding-assistants.rst
>>>
>>> Kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=221494
>>> Related: https://bugzilla.kernel.org/show_bug.cgi?id=221454
>>>
>>> Hardik Prakash (1):
>>>     i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7
>>>       14AGP11
>>>
>>>    drivers/i2c/busses/i2c-designware-platdrv.c | 76 +++++++++++++++++++++
>>>    1 file changed, 76 insertions(+)
>>>
>>> base-commit: 3812a9e84265a5cdd90d29fe8d97a023e91fb945
>>

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Bartosz Golaszewski]

On Mon, May 18, 2026 at 3:46 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 5/18/26 08:40, Hardik Prakash wrote:
> > On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
> >> I'd still like to avoid a quirk if we can.
> >>
> >> I know my proposed patch to try to probe at an earlier stage didn't
> >> work, but could you perhaps try pulling pinctrl-amd even earlier?
> >>
> >> Maybe fs_initcall()?
> >
> > Tested. fs_initcall + patch 1 still produces the same arbitration
> > errors:
> >
> >    subsys_initcall + patch 1:   arbitration errors persist
> >    fs_initcall + patch 1:       arbitration errors persist
> >    patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
> >
> > The initcall level does not appear to be the determining factor on
> > this hardware. i2c_designware is still probing AMDI0010:02 before
> > pinctrl-amd finishes regardless of how early pinctrl-amd registers.
> > The explicit device_is_bound() deferral in patch 2 is the only
> > approach that has worked.
>
> Please try arch_initcall instead.
>

What is blocking the pinctrl driver from probing? Does it return
-EPROBE_DEFER for some reason? Pin control core is ready at
core_initcall() so it should work in theory.

Bart

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Mario Limonciello]

On 5/18/26 09:05, Bartosz Golaszewski wrote:
> On Mon, May 18, 2026 at 3:46 PM Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>>
>>
>>
>> On 5/18/26 08:40, Hardik Prakash wrote:
>>> On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
>>>> I'd still like to avoid a quirk if we can.
>>>>
>>>> I know my proposed patch to try to probe at an earlier stage didn't
>>>> work, but could you perhaps try pulling pinctrl-amd even earlier?
>>>>
>>>> Maybe fs_initcall()?
>>>
>>> Tested. fs_initcall + patch 1 still produces the same arbitration
>>> errors:
>>>
>>>     subsys_initcall + patch 1:   arbitration errors persist
>>>     fs_initcall + patch 1:       arbitration errors persist
>>>     patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
>>>
>>> The initcall level does not appear to be the determining factor on
>>> this hardware. i2c_designware is still probing AMDI0010:02 before
>>> pinctrl-amd finishes regardless of how early pinctrl-amd registers.
>>> The explicit device_is_bound() deferral in patch 2 is the only
>>> approach that has worked.
>>
>> Please try arch_initcall instead.
>>
> 
> What is blocking the pinctrl driver from probing? Does it return
> -EPROBE_DEFER for some reason? Pin control core is ready at
> core_initcall() so it should work in theory.
> 
> Bart

Currently it's module_platform_driver() IE device_initcall().

That's why I think we "should" be able to move it a lot earlier.

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Bartosz Golaszewski]

On Mon, May 18, 2026 at 4:08 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 5/18/26 09:05, Bartosz Golaszewski wrote:
> > On Mon, May 18, 2026 at 3:46 PM Mario Limonciello
> > <mario.limonciello@amd.com> wrote:
> >>
> >>
> >>
> >> On 5/18/26 08:40, Hardik Prakash wrote:
> >>> On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
> >>>> I'd still like to avoid a quirk if we can.
> >>>>
> >>>> I know my proposed patch to try to probe at an earlier stage didn't
> >>>> work, but could you perhaps try pulling pinctrl-amd even earlier?
> >>>>
> >>>> Maybe fs_initcall()?
> >>>
> >>> Tested. fs_initcall + patch 1 still produces the same arbitration
> >>> errors:
> >>>
> >>>     subsys_initcall + patch 1:   arbitration errors persist
> >>>     fs_initcall + patch 1:       arbitration errors persist
> >>>     patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
> >>>
> >>> The initcall level does not appear to be the determining factor on
> >>> this hardware. i2c_designware is still probing AMDI0010:02 before
> >>> pinctrl-amd finishes regardless of how early pinctrl-amd registers.
> >>> The explicit device_is_bound() deferral in patch 2 is the only
> >>> approach that has worked.
> >>
> >> Please try arch_initcall instead.
> >>
> >
> > What is blocking the pinctrl driver from probing? Does it return
> > -EPROBE_DEFER for some reason? Pin control core is ready at
> > core_initcall() so it should work in theory.
> >
> > Bart
>
> Currently it's module_platform_driver() IE device_initcall().
>
> That's why I think we "should" be able to move it a lot earlier.

I mean with fs_initcall() change - what's blocking it now?

Bart

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

On Mon, May 18, 2026 at 19:35, Bartosz Golaszewski wrote:
> What is blocking the pinctrl driver from probing? Does it return
> -EPROBE_DEFER for some reason? Pin control core is ready at
> core_initcall() so it should work in theory.

On Mon, May 18, 2026 at 19:16, Mario Limonciello wrote:
> Please try arch_initcall instead.

Tested arch_initcall + patch 1. GPIO 157 now fires at 0.255s (earlier
than any previous boot), but arbitration errors still occur at 2.309s:

  subsys_initcall + patch 1:   GPIO 157 at ~0.310s, arbitration errors
  arch_initcall + patch 1:     GPIO 157 at ~0.255s, arbitration errors
  patch 1 + patch 2 (v5):     no arbitration errors, touchscreen works

The driver is not returning -EPROBE_DEFER. The problem is that
amd_gpio_probe() hasn't completed by the time i2c_designware fires,
even with arch_initcall. Promoting the initcall level gets the driver
registered earlier, but probe itself takes time, and i2c_designware
catches it mid-probe regardless of registration timing.

This is why device_is_bound() works where initcall promotion does not
— it waits for probe completion, not just driver registration.

Thanks,
Hardik

On Mon, 18 May 2026 at 19:41, Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Mon, May 18, 2026 at 4:08 PM Mario Limonciello
> <mario.limonciello@amd.com> wrote:
> >
> >
> >
> > On 5/18/26 09:05, Bartosz Golaszewski wrote:
> > > On Mon, May 18, 2026 at 3:46 PM Mario Limonciello
> > > <mario.limonciello@amd.com> wrote:
> > >>
> > >>
> > >>
> > >> On 5/18/26 08:40, Hardik Prakash wrote:
> > >>> On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
> > >>>> I'd still like to avoid a quirk if we can.
> > >>>>
> > >>>> I know my proposed patch to try to probe at an earlier stage didn't
> > >>>> work, but could you perhaps try pulling pinctrl-amd even earlier?
> > >>>>
> > >>>> Maybe fs_initcall()?
> > >>>
> > >>> Tested. fs_initcall + patch 1 still produces the same arbitration
> > >>> errors:
> > >>>
> > >>>     subsys_initcall + patch 1:   arbitration errors persist
> > >>>     fs_initcall + patch 1:       arbitration errors persist
> > >>>     patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
> > >>>
> > >>> The initcall level does not appear to be the determining factor on
> > >>> this hardware. i2c_designware is still probing AMDI0010:02 before
> > >>> pinctrl-amd finishes regardless of how early pinctrl-amd registers.
> > >>> The explicit device_is_bound() deferral in patch 2 is the only
> > >>> approach that has worked.
> > >>
> > >> Please try arch_initcall instead.
> > >>
> > >
> > > What is blocking the pinctrl driver from probing? Does it return
> > > -EPROBE_DEFER for some reason? Pin control core is ready at
> > > core_initcall() so it should work in theory.
> > >
> > > Bart
> >
> > Currently it's module_platform_driver() IE device_initcall().
> >
> > That's why I think we "should" be able to move it a lot earlier.
>
> I mean with fs_initcall() change - what's blocking it now?
>
> Bart

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Bartosz Golaszewski]

On Mon, May 18, 2026 at 4:23 PM Hardik Prakash
<hardikprakash.official@gmail.com> wrote:
>
> On Mon, May 18, 2026 at 19:35, Bartosz Golaszewski wrote:
> > What is blocking the pinctrl driver from probing? Does it return
> > -EPROBE_DEFER for some reason? Pin control core is ready at
> > core_initcall() so it should work in theory.
>
> On Mon, May 18, 2026 at 19:16, Mario Limonciello wrote:
> > Please try arch_initcall instead.
>
> Tested arch_initcall + patch 1. GPIO 157 now fires at 0.255s (earlier
> than any previous boot), but arbitration errors still occur at 2.309s:
>
>   subsys_initcall + patch 1:   GPIO 157 at ~0.310s, arbitration errors
>   arch_initcall + patch 1:     GPIO 157 at ~0.255s, arbitration errors
>   patch 1 + patch 2 (v5):     no arbitration errors, touchscreen works
>
> The driver is not returning -EPROBE_DEFER. The problem is that
> amd_gpio_probe() hasn't completed by the time i2c_designware fires,
> even with arch_initcall. Promoting the initcall level gets the driver
> registered earlier, but probe itself takes time, and i2c_designware
> catches it mid-probe regardless of registration timing.
>
> This is why device_is_bound() works where initcall promotion does not
> — it waits for probe completion, not just driver registration.
>

If you added wait_for_device_probe() right before requesting the
interrupt, does it help?

Bartosz

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Andy Shevchenko]

On Mon, May 18, 2026 at 07:53:28PM +0530, Hardik Prakash wrote:
> On Mon, May 18, 2026 at 19:35, Bartosz Golaszewski wrote:
> > What is blocking the pinctrl driver from probing? Does it return
> > -EPROBE_DEFER for some reason? Pin control core is ready at
> > core_initcall() so it should work in theory.
> 
> On Mon, May 18, 2026 at 19:16, Mario Limonciello wrote:
> > Please try arch_initcall instead.
> 
> Tested arch_initcall + patch 1. GPIO 157 now fires at 0.255s (earlier
> than any previous boot), but arbitration errors still occur at 2.309s:
> 
>   subsys_initcall + patch 1:   GPIO 157 at ~0.310s, arbitration errors
>   arch_initcall + patch 1:     GPIO 157 at ~0.255s, arbitration errors
>   patch 1 + patch 2 (v5):     no arbitration errors, touchscreen works
> 
> The driver is not returning -EPROBE_DEFER. The problem is that
> amd_gpio_probe() hasn't completed by the time i2c_designware fires,
> even with arch_initcall. Promoting the initcall level gets the driver
> registered earlier, but probe itself takes time, and i2c_designware
> catches it mid-probe regardless of registration timing.
> 
> This is why device_is_bound() works where initcall promotion does not
> — it waits for probe completion, not just driver registration.

The alternative solution is to have a registered notifier for the device in
question. But not sure if it will be less-invasive than given solution.

> On Mon, 18 May 2026 at 19:41, Bartosz Golaszewski <brgl@kernel.org> wrote:
> > On Mon, May 18, 2026 at 4:08 PM Mario Limonciello
> > <mario.limonciello@amd.com> wrote:
> > > On 5/18/26 09:05, Bartosz Golaszewski wrote:
> > > > On Mon, May 18, 2026 at 3:46 PM Mario Limonciello
> > > > <mario.limonciello@amd.com> wrote:
> > > >> On 5/18/26 08:40, Hardik Prakash wrote:
> > > >>> On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
> > > >>>> I'd still like to avoid a quirk if we can.
> > > >>>>
> > > >>>> I know my proposed patch to try to probe at an earlier stage didn't
> > > >>>> work, but could you perhaps try pulling pinctrl-amd even earlier?
> > > >>>>
> > > >>>> Maybe fs_initcall()?
> > > >>>
> > > >>> Tested. fs_initcall + patch 1 still produces the same arbitration
> > > >>> errors:
> > > >>>
> > > >>>     subsys_initcall + patch 1:   arbitration errors persist
> > > >>>     fs_initcall + patch 1:       arbitration errors persist
> > > >>>     patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
> > > >>>
> > > >>> The initcall level does not appear to be the determining factor on
> > > >>> this hardware. i2c_designware is still probing AMDI0010:02 before
> > > >>> pinctrl-amd finishes regardless of how early pinctrl-amd registers.
> > > >>> The explicit device_is_bound() deferral in patch 2 is the only
> > > >>> approach that has worked.
> > > >>
> > > >> Please try arch_initcall instead.
> > > >
> > > > What is blocking the pinctrl driver from probing? Does it return
> > > > -EPROBE_DEFER for some reason? Pin control core is ready at
> > > > core_initcall() so it should work in theory.
> > >
> > > Currently it's module_platform_driver() IE device_initcall().
> > >
> > > That's why I think we "should" be able to move it a lot earlier.
> >
> > I mean with fs_initcall() change - what's blocking it now?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

On Mon, May 18, 2026 at 19:57, Bartosz Golaszewski wrote:
> If you added wait_for_device_probe() right before requesting the
> interrupt, does it help?

I'll test this. One concern: wait_for_device_probe() waits for all
pending probes to complete, not just pinctrl-amd. Calling it
unconditionally in dw_i2c_plat_probe() would affect every machine
running i2c-designware, potentially adding boot latency broadly.

Would it make sense to guard it with the same DMI check, or is the
intention to make this unconditional?

Thanks,
Hardik

On Mon, 18 May 2026 at 19:58, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Mon, May 18, 2026 at 07:53:28PM +0530, Hardik Prakash wrote:
> > On Mon, May 18, 2026 at 19:35, Bartosz Golaszewski wrote:
> > > What is blocking the pinctrl driver from probing? Does it return
> > > -EPROBE_DEFER for some reason? Pin control core is ready at
> > > core_initcall() so it should work in theory.
> >
> > On Mon, May 18, 2026 at 19:16, Mario Limonciello wrote:
> > > Please try arch_initcall instead.
> >
> > Tested arch_initcall + patch 1. GPIO 157 now fires at 0.255s (earlier
> > than any previous boot), but arbitration errors still occur at 2.309s:
> >
> >   subsys_initcall + patch 1:   GPIO 157 at ~0.310s, arbitration errors
> >   arch_initcall + patch 1:     GPIO 157 at ~0.255s, arbitration errors
> >   patch 1 + patch 2 (v5):     no arbitration errors, touchscreen works
> >
> > The driver is not returning -EPROBE_DEFER. The problem is that
> > amd_gpio_probe() hasn't completed by the time i2c_designware fires,
> > even with arch_initcall. Promoting the initcall level gets the driver
> > registered earlier, but probe itself takes time, and i2c_designware
> > catches it mid-probe regardless of registration timing.
> >
> > This is why device_is_bound() works where initcall promotion does not
> > — it waits for probe completion, not just driver registration.
>
> The alternative solution is to have a registered notifier for the device in
> question. But not sure if it will be less-invasive than given solution.
>
> > On Mon, 18 May 2026 at 19:41, Bartosz Golaszewski <brgl@kernel.org> wrote:
> > > On Mon, May 18, 2026 at 4:08 PM Mario Limonciello
> > > <mario.limonciello@amd.com> wrote:
> > > > On 5/18/26 09:05, Bartosz Golaszewski wrote:
> > > > > On Mon, May 18, 2026 at 3:46 PM Mario Limonciello
> > > > > <mario.limonciello@amd.com> wrote:
> > > > >> On 5/18/26 08:40, Hardik Prakash wrote:
> > > > >>> On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
> > > > >>>> I'd still like to avoid a quirk if we can.
> > > > >>>>
> > > > >>>> I know my proposed patch to try to probe at an earlier stage didn't
> > > > >>>> work, but could you perhaps try pulling pinctrl-amd even earlier?
> > > > >>>>
> > > > >>>> Maybe fs_initcall()?
> > > > >>>
> > > > >>> Tested. fs_initcall + patch 1 still produces the same arbitration
> > > > >>> errors:
> > > > >>>
> > > > >>>     subsys_initcall + patch 1:   arbitration errors persist
> > > > >>>     fs_initcall + patch 1:       arbitration errors persist
> > > > >>>     patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
> > > > >>>
> > > > >>> The initcall level does not appear to be the determining factor on
> > > > >>> this hardware. i2c_designware is still probing AMDI0010:02 before
> > > > >>> pinctrl-amd finishes regardless of how early pinctrl-amd registers.
> > > > >>> The explicit device_is_bound() deferral in patch 2 is the only
> > > > >>> approach that has worked.
> > > > >>
> > > > >> Please try arch_initcall instead.
> > > > >
> > > > > What is blocking the pinctrl driver from probing? Does it return
> > > > > -EPROBE_DEFER for some reason? Pin control core is ready at
> > > > > core_initcall() so it should work in theory.
> > > >
> > > > Currently it's module_platform_driver() IE device_initcall().
> > > >
> > > > That's why I think we "should" be able to move it a lot earlier.
> > >
> > > I mean with fs_initcall() change - what's blocking it now?
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Mario Limonciello]

On 5/18/26 12:22, Hardik Prakash wrote:
> On Mon, May 18, 2026 at 19:57, Bartosz Golaszewski wrote:
>> If you added wait_for_device_probe() right before requesting the
>> interrupt, does it help?
> 
> I'll test this. One concern: wait_for_device_probe() waits for all
> pending probes to complete, not just pinctrl-amd. Calling it
> unconditionally in dw_i2c_plat_probe() would affect every machine
> running i2c-designware, potentially adding boot latency broadly.
> 
> Would it make sense to guard it with the same DMI check, or is the
> intention to make this unconditional?

Our general aim should be to avoid DMI checks where possible.  If you're 
finding a timing problem on your system there can very likely be a 
timing problem on another system from someone not as willing or able to 
report it.

So let's leave DMI hacks for fallback if we really can't figure this out.

In an ideal world we would have a _DEP in the ACPI entries, but I don't 
think I've ever seen that for the GPIO controller.

I'm still confused though.  Are you saying we're actually racing with 
amd_gpio_probe()?  Like the GPIO chip gets set up before the interrupt 
is ready?

There is a dynamic debug statement already in amd_gpio_probe() for when 
it finishes, maybe you can sprinkle a few more around the start of probe 
and amd_gpio_irq_enable() to confirm?

> 
> Thanks,
> Hardik
> 
> On Mon, 18 May 2026 at 19:58, Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
>>
>> On Mon, May 18, 2026 at 07:53:28PM +0530, Hardik Prakash wrote:
>>> On Mon, May 18, 2026 at 19:35, Bartosz Golaszewski wrote:
>>>> What is blocking the pinctrl driver from probing? Does it return
>>>> -EPROBE_DEFER for some reason? Pin control core is ready at
>>>> core_initcall() so it should work in theory.
>>>
>>> On Mon, May 18, 2026 at 19:16, Mario Limonciello wrote:
>>>> Please try arch_initcall instead.
>>>
>>> Tested arch_initcall + patch 1. GPIO 157 now fires at 0.255s (earlier
>>> than any previous boot), but arbitration errors still occur at 2.309s:
>>>
>>>    subsys_initcall + patch 1:   GPIO 157 at ~0.310s, arbitration errors
>>>    arch_initcall + patch 1:     GPIO 157 at ~0.255s, arbitration errors
>>>    patch 1 + patch 2 (v5):     no arbitration errors, touchscreen works
>>>
>>> The driver is not returning -EPROBE_DEFER. The problem is that
>>> amd_gpio_probe() hasn't completed by the time i2c_designware fires,
>>> even with arch_initcall. Promoting the initcall level gets the driver
>>> registered earlier, but probe itself takes time, and i2c_designware
>>> catches it mid-probe regardless of registration timing.
>>>
>>> This is why device_is_bound() works where initcall promotion does not
>>> — it waits for probe completion, not just driver registration.
>>
>> The alternative solution is to have a registered notifier for the device in
>> question. But not sure if it will be less-invasive than given solution.
>>
>>> On Mon, 18 May 2026 at 19:41, Bartosz Golaszewski <brgl@kernel.org> wrote:
>>>> On Mon, May 18, 2026 at 4:08 PM Mario Limonciello
>>>> <mario.limonciello@amd.com> wrote:
>>>>> On 5/18/26 09:05, Bartosz Golaszewski wrote:
>>>>>> On Mon, May 18, 2026 at 3:46 PM Mario Limonciello
>>>>>> <mario.limonciello@amd.com> wrote:
>>>>>>> On 5/18/26 08:40, Hardik Prakash wrote:
>>>>>>>> On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
>>>>>>>>> I'd still like to avoid a quirk if we can.
>>>>>>>>>
>>>>>>>>> I know my proposed patch to try to probe at an earlier stage didn't
>>>>>>>>> work, but could you perhaps try pulling pinctrl-amd even earlier?
>>>>>>>>>
>>>>>>>>> Maybe fs_initcall()?
>>>>>>>>
>>>>>>>> Tested. fs_initcall + patch 1 still produces the same arbitration
>>>>>>>> errors:
>>>>>>>>
>>>>>>>>      subsys_initcall + patch 1:   arbitration errors persist
>>>>>>>>      fs_initcall + patch 1:       arbitration errors persist
>>>>>>>>      patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
>>>>>>>>
>>>>>>>> The initcall level does not appear to be the determining factor on
>>>>>>>> this hardware. i2c_designware is still probing AMDI0010:02 before
>>>>>>>> pinctrl-amd finishes regardless of how early pinctrl-amd registers.
>>>>>>>> The explicit device_is_bound() deferral in patch 2 is the only
>>>>>>>> approach that has worked.
>>>>>>>
>>>>>>> Please try arch_initcall instead.
>>>>>>
>>>>>> What is blocking the pinctrl driver from probing? Does it return
>>>>>> -EPROBE_DEFER for some reason? Pin control core is ready at
>>>>>> core_initcall() so it should work in theory.
>>>>>
>>>>> Currently it's module_platform_driver() IE device_initcall().
>>>>>
>>>>> That's why I think we "should" be able to move it a lot earlier.
>>>>
>>>> I mean with fs_initcall() change - what's blocking it now?
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
>>
>>

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

On Mon, May 18, 2026 at 23:14, Mario Limonciello wrote:
> I'm still confused though.  Are you saying we're actually racing with
> amd_gpio_probe()?  Like the GPIO chip gets set up before the interrupt
> is ready?
>
> There is a dynamic debug statement already in amd_gpio_probe() for when
> it finishes, maybe you can sprinkle a few more around the start of probe
> and amd_gpio_irq_enable() to confirm?

Added debug statements and enabled dyndbg at boot. The trace confirms
the race:

  0.285415  amd_gpio_probe: start
  0.285496  amd_gpio_probe: calling irq_init
  0.285947  GPIO 157 enabled (quirk fires)
  0.285950  amd_gpio_probe: quirks applied
  0.285952  amd_gpio_probe: registering gpiochip  <- GPIO chip visible
  0.287121  amd_gpio_probe: requesting parent IRQ <- probe still running
  0.290248  AMDI0010:00 dw_i2c_plat_probe: start
  0.295928  AMDI0010:01 dw_i2c_plat_probe: start
  0.301454  AMDI0010:02 dw_i2c_plat_probe: start <- races here
  0.306905  AMDI0010:03 dw_i2c_plat_probe: start
  2.348157  lost arbitration

gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
at 0.301454 while amd_gpio_probe() is still completing. This is why
device_is_bound() works and initcall promotion does not -- it waits for
probe completion, not just gpiochip registration.

Thanks,
Hardik

On Mon, 18 May 2026 at 23:14, Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 5/18/26 12:22, Hardik Prakash wrote:
> > On Mon, May 18, 2026 at 19:57, Bartosz Golaszewski wrote:
> >> If you added wait_for_device_probe() right before requesting the
> >> interrupt, does it help?
> >
> > I'll test this. One concern: wait_for_device_probe() waits for all
> > pending probes to complete, not just pinctrl-amd. Calling it
> > unconditionally in dw_i2c_plat_probe() would affect every machine
> > running i2c-designware, potentially adding boot latency broadly.
> >
> > Would it make sense to guard it with the same DMI check, or is the
> > intention to make this unconditional?
>
> Our general aim should be to avoid DMI checks where possible.  If you're
> finding a timing problem on your system there can very likely be a
> timing problem on another system from someone not as willing or able to
> report it.
>
> So let's leave DMI hacks for fallback if we really can't figure this out.
>
> In an ideal world we would have a _DEP in the ACPI entries, but I don't
> think I've ever seen that for the GPIO controller.
>
> I'm still confused though.  Are you saying we're actually racing with
> amd_gpio_probe()?  Like the GPIO chip gets set up before the interrupt
> is ready?
>
> There is a dynamic debug statement already in amd_gpio_probe() for when
> it finishes, maybe you can sprinkle a few more around the start of probe
> and amd_gpio_irq_enable() to confirm?
>
> >
> > Thanks,
> > Hardik
> >
> > On Mon, 18 May 2026 at 19:58, Andy Shevchenko
> > <andriy.shevchenko@intel.com> wrote:
> >>
> >> On Mon, May 18, 2026 at 07:53:28PM +0530, Hardik Prakash wrote:
> >>> On Mon, May 18, 2026 at 19:35, Bartosz Golaszewski wrote:
> >>>> What is blocking the pinctrl driver from probing? Does it return
> >>>> -EPROBE_DEFER for some reason? Pin control core is ready at
> >>>> core_initcall() so it should work in theory.
> >>>
> >>> On Mon, May 18, 2026 at 19:16, Mario Limonciello wrote:
> >>>> Please try arch_initcall instead.
> >>>
> >>> Tested arch_initcall + patch 1. GPIO 157 now fires at 0.255s (earlier
> >>> than any previous boot), but arbitration errors still occur at 2.309s:
> >>>
> >>>    subsys_initcall + patch 1:   GPIO 157 at ~0.310s, arbitration errors
> >>>    arch_initcall + patch 1:     GPIO 157 at ~0.255s, arbitration errors
> >>>    patch 1 + patch 2 (v5):     no arbitration errors, touchscreen works
> >>>
> >>> The driver is not returning -EPROBE_DEFER. The problem is that
> >>> amd_gpio_probe() hasn't completed by the time i2c_designware fires,
> >>> even with arch_initcall. Promoting the initcall level gets the driver
> >>> registered earlier, but probe itself takes time, and i2c_designware
> >>> catches it mid-probe regardless of registration timing.
> >>>
> >>> This is why device_is_bound() works where initcall promotion does not
> >>> — it waits for probe completion, not just driver registration.
> >>
> >> The alternative solution is to have a registered notifier for the device in
> >> question. But not sure if it will be less-invasive than given solution.
> >>
> >>> On Mon, 18 May 2026 at 19:41, Bartosz Golaszewski <brgl@kernel.org> wrote:
> >>>> On Mon, May 18, 2026 at 4:08 PM Mario Limonciello
> >>>> <mario.limonciello@amd.com> wrote:
> >>>>> On 5/18/26 09:05, Bartosz Golaszewski wrote:
> >>>>>> On Mon, May 18, 2026 at 3:46 PM Mario Limonciello
> >>>>>> <mario.limonciello@amd.com> wrote:
> >>>>>>> On 5/18/26 08:40, Hardik Prakash wrote:
> >>>>>>>> On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
> >>>>>>>>> I'd still like to avoid a quirk if we can.
> >>>>>>>>>
> >>>>>>>>> I know my proposed patch to try to probe at an earlier stage didn't
> >>>>>>>>> work, but could you perhaps try pulling pinctrl-amd even earlier?
> >>>>>>>>>
> >>>>>>>>> Maybe fs_initcall()?
> >>>>>>>>
> >>>>>>>> Tested. fs_initcall + patch 1 still produces the same arbitration
> >>>>>>>> errors:
> >>>>>>>>
> >>>>>>>>      subsys_initcall + patch 1:   arbitration errors persist
> >>>>>>>>      fs_initcall + patch 1:       arbitration errors persist
> >>>>>>>>      patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
> >>>>>>>>
> >>>>>>>> The initcall level does not appear to be the determining factor on
> >>>>>>>> this hardware. i2c_designware is still probing AMDI0010:02 before
> >>>>>>>> pinctrl-amd finishes regardless of how early pinctrl-amd registers.
> >>>>>>>> The explicit device_is_bound() deferral in patch 2 is the only
> >>>>>>>> approach that has worked.
> >>>>>>>
> >>>>>>> Please try arch_initcall instead.
> >>>>>>
> >>>>>> What is blocking the pinctrl driver from probing? Does it return
> >>>>>> -EPROBE_DEFER for some reason? Pin control core is ready at
> >>>>>> core_initcall() so it should work in theory.
> >>>>>
> >>>>> Currently it's module_platform_driver() IE device_initcall().
> >>>>>
> >>>>> That's why I think we "should" be able to move it a lot earlier.
> >>>>
> >>>> I mean with fs_initcall() change - what's blocking it now?
> >>
> >> --
> >> With Best Regards,
> >> Andy Shevchenko
> >>
> >>
>

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Mario Limonciello]

On 5/19/26 02:21, Hardik Prakash wrote:
> On Mon, May 18, 2026 at 23:14, Mario Limonciello wrote:
>> I'm still confused though.  Are you saying we're actually racing with
>> amd_gpio_probe()?  Like the GPIO chip gets set up before the interrupt
>> is ready?
>>
>> There is a dynamic debug statement already in amd_gpio_probe() for when
>> it finishes, maybe you can sprinkle a few more around the start of probe
>> and amd_gpio_irq_enable() to confirm?
> 
> Added debug statements and enabled dyndbg at boot. The trace confirms
> the race:
> 
>    0.285415  amd_gpio_probe: start
>    0.285496  amd_gpio_probe: calling irq_init
>    0.285947  GPIO 157 enabled (quirk fires)
>    0.285950  amd_gpio_probe: quirks applied
>    0.285952  amd_gpio_probe: registering gpiochip  <- GPIO chip visible
>    0.287121  amd_gpio_probe: requesting parent IRQ <- probe still running
>    0.290248  AMDI0010:00 dw_i2c_plat_probe: start
>    0.295928  AMDI0010:01 dw_i2c_plat_probe: start
>    0.301454  AMDI0010:02 dw_i2c_plat_probe: start <- races here
>    0.306905  AMDI0010:03 dw_i2c_plat_probe: start
>    2.348157  lost arbitration

You add a debug statement to amd_gpio_irq_enable() too right?  Can you 
please share your debugging messages patch and full log?

I had expected that the interrupt should be enabled before it starts 
getting used.

> 
> gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
> system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
> at 0.301454 while amd_gpio_probe() is still completing. This is why
> device_is_bound() works and initcall promotion does not -- it waits for
> probe completion, not just gpiochip registration.

What is the boot time impact to adding device_is_bound() check?

Bartosz, thoughts?

> 
> Thanks,
> Hardik
> 
> On Mon, 18 May 2026 at 23:14, Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>>
>>
>>
>> On 5/18/26 12:22, Hardik Prakash wrote:
>>> On Mon, May 18, 2026 at 19:57, Bartosz Golaszewski wrote:
>>>> If you added wait_for_device_probe() right before requesting the
>>>> interrupt, does it help?
>>>
>>> I'll test this. One concern: wait_for_device_probe() waits for all
>>> pending probes to complete, not just pinctrl-amd. Calling it
>>> unconditionally in dw_i2c_plat_probe() would affect every machine
>>> running i2c-designware, potentially adding boot latency broadly.
>>>
>>> Would it make sense to guard it with the same DMI check, or is the
>>> intention to make this unconditional?
>>
>> Our general aim should be to avoid DMI checks where possible.  If you're
>> finding a timing problem on your system there can very likely be a
>> timing problem on another system from someone not as willing or able to
>> report it.
>>
>> So let's leave DMI hacks for fallback if we really can't figure this out.
>>
>> In an ideal world we would have a _DEP in the ACPI entries, but I don't
>> think I've ever seen that for the GPIO controller.
>>
>> I'm still confused though.  Are you saying we're actually racing with
>> amd_gpio_probe()?  Like the GPIO chip gets set up before the interrupt
>> is ready?
>>
>> There is a dynamic debug statement already in amd_gpio_probe() for when
>> it finishes, maybe you can sprinkle a few more around the start of probe
>> and amd_gpio_irq_enable() to confirm?
>>
>>>
>>> Thanks,
>>> Hardik
>>>
>>> On Mon, 18 May 2026 at 19:58, Andy Shevchenko
>>> <andriy.shevchenko@intel.com> wrote:
>>>>
>>>> On Mon, May 18, 2026 at 07:53:28PM +0530, Hardik Prakash wrote:
>>>>> On Mon, May 18, 2026 at 19:35, Bartosz Golaszewski wrote:
>>>>>> What is blocking the pinctrl driver from probing? Does it return
>>>>>> -EPROBE_DEFER for some reason? Pin control core is ready at
>>>>>> core_initcall() so it should work in theory.
>>>>>
>>>>> On Mon, May 18, 2026 at 19:16, Mario Limonciello wrote:
>>>>>> Please try arch_initcall instead.
>>>>>
>>>>> Tested arch_initcall + patch 1. GPIO 157 now fires at 0.255s (earlier
>>>>> than any previous boot), but arbitration errors still occur at 2.309s:
>>>>>
>>>>>     subsys_initcall + patch 1:   GPIO 157 at ~0.310s, arbitration errors
>>>>>     arch_initcall + patch 1:     GPIO 157 at ~0.255s, arbitration errors
>>>>>     patch 1 + patch 2 (v5):     no arbitration errors, touchscreen works
>>>>>
>>>>> The driver is not returning -EPROBE_DEFER. The problem is that
>>>>> amd_gpio_probe() hasn't completed by the time i2c_designware fires,
>>>>> even with arch_initcall. Promoting the initcall level gets the driver
>>>>> registered earlier, but probe itself takes time, and i2c_designware
>>>>> catches it mid-probe regardless of registration timing.
>>>>>
>>>>> This is why device_is_bound() works where initcall promotion does not
>>>>> — it waits for probe completion, not just driver registration.
>>>>
>>>> The alternative solution is to have a registered notifier for the device in
>>>> question. But not sure if it will be less-invasive than given solution.
>>>>
>>>>> On Mon, 18 May 2026 at 19:41, Bartosz Golaszewski <brgl@kernel.org> wrote:
>>>>>> On Mon, May 18, 2026 at 4:08 PM Mario Limonciello
>>>>>> <mario.limonciello@amd.com> wrote:
>>>>>>> On 5/18/26 09:05, Bartosz Golaszewski wrote:
>>>>>>>> On Mon, May 18, 2026 at 3:46 PM Mario Limonciello
>>>>>>>> <mario.limonciello@amd.com> wrote:
>>>>>>>>> On 5/18/26 08:40, Hardik Prakash wrote:
>>>>>>>>>> On Mon, May 18, 2026 at 18:17, Mario Limonciello wrote:
>>>>>>>>>>> I'd still like to avoid a quirk if we can.
>>>>>>>>>>>
>>>>>>>>>>> I know my proposed patch to try to probe at an earlier stage didn't
>>>>>>>>>>> work, but could you perhaps try pulling pinctrl-amd even earlier?
>>>>>>>>>>>
>>>>>>>>>>> Maybe fs_initcall()?
>>>>>>>>>>
>>>>>>>>>> Tested. fs_initcall + patch 1 still produces the same arbitration
>>>>>>>>>> errors:
>>>>>>>>>>
>>>>>>>>>>       subsys_initcall + patch 1:   arbitration errors persist
>>>>>>>>>>       fs_initcall + patch 1:       arbitration errors persist
>>>>>>>>>>       patch 1 + patch 2 (v5):     clean boot, touchscreen fully functional
>>>>>>>>>>
>>>>>>>>>> The initcall level does not appear to be the determining factor on
>>>>>>>>>> this hardware. i2c_designware is still probing AMDI0010:02 before
>>>>>>>>>> pinctrl-amd finishes regardless of how early pinctrl-amd registers.
>>>>>>>>>> The explicit device_is_bound() deferral in patch 2 is the only
>>>>>>>>>> approach that has worked.
>>>>>>>>>
>>>>>>>>> Please try arch_initcall instead.
>>>>>>>>
>>>>>>>> What is blocking the pinctrl driver from probing? Does it return
>>>>>>>> -EPROBE_DEFER for some reason? Pin control core is ready at
>>>>>>>> core_initcall() so it should work in theory.
>>>>>>>
>>>>>>> Currently it's module_platform_driver() IE device_initcall().
>>>>>>>
>>>>>>> That's why I think we "should" be able to move it a lot earlier.
>>>>>>
>>>>>> I mean with fs_initcall() change - what's blocking it now?
>>>>
>>>> --
>>>> With Best Regards,
>>>> Andy Shevchenko
>>>>
>>>>
>>

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Bartosz Golaszewski]

On Tue, May 19, 2026 at 4:28 PM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
> >
> > gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
> > system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
> > at 0.301454 while amd_gpio_probe() is still completing. This is why
> > device_is_bound() works and initcall promotion does not -- it waits for
> > probe completion, not just gpiochip registration.
>
> What is the boot time impact to adding device_is_bound() check?
>
> Bartosz, thoughts?
>

My thoughts are that ACPI could use some fw_devlink. :) It's not a new
problem, we've fixed it for OF systems.

Could we modify gpiolib-acpi.c to return -EPROBE_DEFER if the parent
device of the GPIO chip is not bound yet instead? When resolving the
reference to the remote GPIO controller we have an address of the
struct acpi_device. I suppose there's a platform device that is its
child and then the logical GPIO controller device, is that correct?
Can we check if the platform device in question is bound at the
subsystem level?

Bart

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Mario Limonciello]

On 5/19/26 09:39, Bartosz Golaszewski wrote:
> On Tue, May 19, 2026 at 4:28 PM Mario Limonciello
> <mario.limonciello@amd.com> wrote:
>>
>>>
>>> gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
>>> system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
>>> at 0.301454 while amd_gpio_probe() is still completing. This is why
>>> device_is_bound() works and initcall promotion does not -- it waits for
>>> probe completion, not just gpiochip registration.
>>
>> What is the boot time impact to adding device_is_bound() check?
>>
>> Bartosz, thoughts?
>>
> 
> My thoughts are that ACPI could use some fw_devlink. :) It's not a new
> problem, we've fixed it for OF systems.
> 
> Could we modify gpiolib-acpi.c to return -EPROBE_DEFER if the parent
> device of the GPIO chip is not bound yet instead? When resolving the
> reference to the remote GPIO controller we have an address of the
> struct acpi_device. I suppose there's a platform device that is its
> child and then the logical GPIO controller device, is that correct?
> Can we check if the platform device in question is bound at the
> subsystem level?
> 
> Bart

I like this idea.  I guess something like this:

diff --git a/drivers/gpio/gpiolib-acpi-core.c 
b/drivers/gpio/gpiolib-acpi-core.c
index eb8a40cfb7a98..e3511398b1f84 100644
--- a/drivers/gpio/gpiolib-acpi-core.c
+++ b/drivers/gpio/gpiolib-acpi-core.c
@@ -142,6 +142,13 @@ static struct gpio_desc *acpi_get_gpiod(char *path, 
unsigned int pin)
         if (!gdev)
                 return ERR_PTR(-EPROBE_DEFER);

+       if (gdev->dev.parent) {
+               scoped_guard(device, gdev->dev.parent) {
+                       if (!device_is_bound(gdev->dev.parent))
+                               return ERR_PTR(-EPROBE_DEFER);
+               }
+       }
+
         /*
          * FIXME: keep track of the reference to the GPIO device somehow
          * instead of putting it here.

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

On Tue, May 19, 2026 at 19:58, Mario Limonciello wrote:
> You add a debug statement to amd_gpio_irq_enable() too right? Can you
> please share your debugging messages patch and full log?

I did not add debug to amd_gpio_irq_enable() - the statements were
only in amd_gpio_probe() and dw_i2c_plat_probe(). I can add one there
if useful, but given Bart's suggestion below I'll hold off unless
needed.

> What is the boot time impact to adding device_is_bound() check?

I haven't measured this explicitly. The deferral only fires on DMI-
matched hardware (Lenovo 83TD), so on other machines dw_i2c_defer_for_
amd_gpio() returns 0 immediately with no overhead.

On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
> I like this idea.

I'll test this patch, and let you know how it goes.

Thanks,
Hardik

On Tue, 19 May 2026 at 20:18, Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 5/19/26 09:39, Bartosz Golaszewski wrote:
> > On Tue, May 19, 2026 at 4:28 PM Mario Limonciello
> > <mario.limonciello@amd.com> wrote:
> >>
> >>>
> >>> gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
> >>> system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
> >>> at 0.301454 while amd_gpio_probe() is still completing. This is why
> >>> device_is_bound() works and initcall promotion does not -- it waits for
> >>> probe completion, not just gpiochip registration.
> >>
> >> What is the boot time impact to adding device_is_bound() check?
> >>
> >> Bartosz, thoughts?
> >>
> >
> > My thoughts are that ACPI could use some fw_devlink. :) It's not a new
> > problem, we've fixed it for OF systems.
> >
> > Could we modify gpiolib-acpi.c to return -EPROBE_DEFER if the parent
> > device of the GPIO chip is not bound yet instead? When resolving the
> > reference to the remote GPIO controller we have an address of the
> > struct acpi_device. I suppose there's a platform device that is its
> > child and then the logical GPIO controller device, is that correct?
> > Can we check if the platform device in question is bound at the
> > subsystem level?
> >
> > Bart
>
> I like this idea.  I guess something like this:
>
> diff --git a/drivers/gpio/gpiolib-acpi-core.c
> b/drivers/gpio/gpiolib-acpi-core.c
> index eb8a40cfb7a98..e3511398b1f84 100644
> --- a/drivers/gpio/gpiolib-acpi-core.c
> +++ b/drivers/gpio/gpiolib-acpi-core.c
> @@ -142,6 +142,13 @@ static struct gpio_desc *acpi_get_gpiod(char *path,
> unsigned int pin)
>          if (!gdev)
>                  return ERR_PTR(-EPROBE_DEFER);
>
> +       if (gdev->dev.parent) {
> +               scoped_guard(device, gdev->dev.parent) {
> +                       if (!device_is_bound(gdev->dev.parent))
> +                               return ERR_PTR(-EPROBE_DEFER);
> +               }
> +       }
> +
>          /*
>           * FIXME: keep track of the reference to the GPIO device somehow
>           * instead of putting it here.
>

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
> I like this idea. I guess something like this:
> [gpiolib-acpi-core.c patch]

Tested patch 1 + gpiolib-acpi deferral, without patch 2. Arbitration
errors persist:

  patch 1 + gpiolib-acpi deferral:   arbitration errors, WACF2200 does not probe
  patch 1 + patch 2 (v5):           clean boot, touchscreen fully functional

I think the reason is that i2c-designware does not call acpi_get_gpiod()
during its probe. The GpioInt resource is on the WACF2200 touchscreen
device (TPNL), not on the I2C controller itself. So the deferral in
acpi_get_gpiod() never triggers for AMDI0010:02 -- nothing in that probe
path requests a GPIO descriptor.

The race is between amd_gpio_probe() completing and dw_i2c_plat_probe()
starting for AMDI0010:02. Without something that explicitly checks
whether the GPIO controller is fully bound before the I2C controller
probes, the race remains.

Thanks,
Hardik

On Wed, 20 May 2026 at 00:37, Hardik Prakash
<hardikprakash.official@gmail.com> wrote:
>
> On Tue, May 19, 2026 at 19:58, Mario Limonciello wrote:
> > You add a debug statement to amd_gpio_irq_enable() too right? Can you
> > please share your debugging messages patch and full log?
>
> I did not add debug to amd_gpio_irq_enable() - the statements were
> only in amd_gpio_probe() and dw_i2c_plat_probe(). I can add one there
> if useful, but given Bart's suggestion below I'll hold off unless
> needed.
>
> > What is the boot time impact to adding device_is_bound() check?
>
> I haven't measured this explicitly. The deferral only fires on DMI-
> matched hardware (Lenovo 83TD), so on other machines dw_i2c_defer_for_
> amd_gpio() returns 0 immediately with no overhead.
>
> On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
> > I like this idea.
>
> I'll test this patch, and let you know how it goes.
>
> Thanks,
> Hardik
>
> On Tue, 19 May 2026 at 20:18, Mario Limonciello
> <mario.limonciello@amd.com> wrote:
> >
> >
> >
> > On 5/19/26 09:39, Bartosz Golaszewski wrote:
> > > On Tue, May 19, 2026 at 4:28 PM Mario Limonciello
> > > <mario.limonciello@amd.com> wrote:
> > >>
> > >>>
> > >>> gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
> > >>> system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
> > >>> at 0.301454 while amd_gpio_probe() is still completing. This is why
> > >>> device_is_bound() works and initcall promotion does not -- it waits for
> > >>> probe completion, not just gpiochip registration.
> > >>
> > >> What is the boot time impact to adding device_is_bound() check?
> > >>
> > >> Bartosz, thoughts?
> > >>
> > >
> > > My thoughts are that ACPI could use some fw_devlink. :) It's not a new
> > > problem, we've fixed it for OF systems.
> > >
> > > Could we modify gpiolib-acpi.c to return -EPROBE_DEFER if the parent
> > > device of the GPIO chip is not bound yet instead? When resolving the
> > > reference to the remote GPIO controller we have an address of the
> > > struct acpi_device. I suppose there's a platform device that is its
> > > child and then the logical GPIO controller device, is that correct?
> > > Can we check if the platform device in question is bound at the
> > > subsystem level?
> > >
> > > Bart
> >
> > I like this idea.  I guess something like this:
> >
> > diff --git a/drivers/gpio/gpiolib-acpi-core.c
> > b/drivers/gpio/gpiolib-acpi-core.c
> > index eb8a40cfb7a98..e3511398b1f84 100644
> > --- a/drivers/gpio/gpiolib-acpi-core.c
> > +++ b/drivers/gpio/gpiolib-acpi-core.c
> > @@ -142,6 +142,13 @@ static struct gpio_desc *acpi_get_gpiod(char *path,
> > unsigned int pin)
> >          if (!gdev)
> >                  return ERR_PTR(-EPROBE_DEFER);
> >
> > +       if (gdev->dev.parent) {
> > +               scoped_guard(device, gdev->dev.parent) {
> > +                       if (!device_is_bound(gdev->dev.parent))
> > +                               return ERR_PTR(-EPROBE_DEFER);
> > +               }
> > +       }
> > +
> >          /*
> >           * FIXME: keep track of the reference to the GPIO device somehow
> >           * instead of putting it here.
> >

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Mario Limonciello]

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



On 5/19/26 14:49, Hardik Prakash wrote:
> On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
>> I like this idea. I guess something like this:
>> [gpiolib-acpi-core.c patch]
> 
> Tested patch 1 + gpiolib-acpi deferral, without patch 2. Arbitration
> errors persist:
> 
>    patch 1 + gpiolib-acpi deferral:   arbitration errors, WACF2200 does not probe
>    patch 1 + patch 2 (v5):           clean boot, touchscreen fully functional
> 
> I think the reason is that i2c-designware does not call acpi_get_gpiod()
> during its probe. The GpioInt resource is on the WACF2200 touchscreen
> device (TPNL), not on the I2C controller itself. So the deferral in
> acpi_get_gpiod() never triggers for AMDI0010:02 -- nothing in that probe
> path requests a GPIO descriptor.
> 
> The race is between amd_gpio_probe() completing and dw_i2c_plat_probe()
> starting for AMDI0010:02. Without something that explicitly checks
> whether the GPIO controller is fully bound before the I2C controller
> probes, the race remains.
> 

In the same linke of thinking - how about something like this instead 
(AI generated and attached).

Basically walk through the resources at probe time and make sure they're 
all bound.

> Thanks,
> Hardik
> 
> On Wed, 20 May 2026 at 00:37, Hardik Prakash
> <hardikprakash.official@gmail.com> wrote:
>>
>> On Tue, May 19, 2026 at 19:58, Mario Limonciello wrote:
>>> You add a debug statement to amd_gpio_irq_enable() too right? Can you
>>> please share your debugging messages patch and full log?
>>
>> I did not add debug to amd_gpio_irq_enable() - the statements were
>> only in amd_gpio_probe() and dw_i2c_plat_probe(). I can add one there
>> if useful, but given Bart's suggestion below I'll hold off unless
>> needed.
>>
>>> What is the boot time impact to adding device_is_bound() check?
>>
>> I haven't measured this explicitly. The deferral only fires on DMI-
>> matched hardware (Lenovo 83TD), so on other machines dw_i2c_defer_for_
>> amd_gpio() returns 0 immediately with no overhead.
>>
>> On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
>>> I like this idea.
>>
>> I'll test this patch, and let you know how it goes.
>>
>> Thanks,
>> Hardik
>>
>> On Tue, 19 May 2026 at 20:18, Mario Limonciello
>> <mario.limonciello@amd.com> wrote:
>>>
>>>
>>>
>>> On 5/19/26 09:39, Bartosz Golaszewski wrote:
>>>> On Tue, May 19, 2026 at 4:28 PM Mario Limonciello
>>>> <mario.limonciello@amd.com> wrote:
>>>>>
>>>>>>
>>>>>> gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
>>>>>> system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
>>>>>> at 0.301454 while amd_gpio_probe() is still completing. This is why
>>>>>> device_is_bound() works and initcall promotion does not -- it waits for
>>>>>> probe completion, not just gpiochip registration.
>>>>>
>>>>> What is the boot time impact to adding device_is_bound() check?
>>>>>
>>>>> Bartosz, thoughts?
>>>>>
>>>>
>>>> My thoughts are that ACPI could use some fw_devlink. :) It's not a new
>>>> problem, we've fixed it for OF systems.
>>>>
>>>> Could we modify gpiolib-acpi.c to return -EPROBE_DEFER if the parent
>>>> device of the GPIO chip is not bound yet instead? When resolving the
>>>> reference to the remote GPIO controller we have an address of the
>>>> struct acpi_device. I suppose there's a platform device that is its
>>>> child and then the logical GPIO controller device, is that correct?
>>>> Can we check if the platform device in question is bound at the
>>>> subsystem level?
>>>>
>>>> Bart
>>>
>>> I like this idea.  I guess something like this:
>>>
>>> diff --git a/drivers/gpio/gpiolib-acpi-core.c
>>> b/drivers/gpio/gpiolib-acpi-core.c
>>> index eb8a40cfb7a98..e3511398b1f84 100644
>>> --- a/drivers/gpio/gpiolib-acpi-core.c
>>> +++ b/drivers/gpio/gpiolib-acpi-core.c
>>> @@ -142,6 +142,13 @@ static struct gpio_desc *acpi_get_gpiod(char *path,
>>> unsigned int pin)
>>>           if (!gdev)
>>>                   return ERR_PTR(-EPROBE_DEFER);
>>>
>>> +       if (gdev->dev.parent) {
>>> +               scoped_guard(device, gdev->dev.parent) {
>>> +                       if (!device_is_bound(gdev->dev.parent))
>>> +                               return ERR_PTR(-EPROBE_DEFER);
>>> +               }
>>> +       }
>>> +
>>>           /*
>>>            * FIXME: keep track of the reference to the GPIO device somehow
>>>            * instead of putting it here.
>>>

[-- Attachment #2: 0001-i2c-designware-Defer-probe-if-child-GpioInt-controll.patch --]
[-- Type: text/x-patch, Size: 5992 bytes --]

From 87778c8ed29f1cdab505d6a74505213e1e8bef21 Mon Sep 17 00:00:00 2001
From: Mario Limonciello <mario.limonciello@amd.com>
Date: Tue, 19 May 2026 15:00:31 -0500
Subject: [TEST PATCH] i2c: designware: Defer probe if child GpioInt controllers are
 not bound

I2C controllers may have child devices with GpioInt resources that
depend on GPIO controllers to be 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
occur before the GPIO IRQ quirk in amd_gpio_probe() has run, causing:

  i2c_designware AMDI0010:02: i2c_dw_handle_tx_abort: lost arbitration

Add a generic dependency check in i2c-designware that walks ACPI child
devices, identifies any GpioInt resources, resolves the referenced GPIO
controllers, and defers probe if those controllers are not yet bound.

This ensures GPIO controllers complete initialization (including IRQ
setup and quirks) before I2C child enumeration begins, fixing the race
without device-specific quirks or DMI matching.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
Not-Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Assisted-by: Claude:claude-sonnet-4-6
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 153 ++++++++++++++++++++
 1 file changed, 153 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 3351c4a9ef118..856bf679406b9 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -8,6 +8,7 @@
  * 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>
@@ -130,6 +131,150 @@ static int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev)
 	return 0;
 }
 
+#ifdef CONFIG_ACPI
+struct gpio_dep_ctx {
+	struct list_head gpio_controllers;
+	int ret;
+};
+
+struct gpio_controller_ref {
+	struct list_head node;
+	char *path;
+};
+
+static int check_gpioint_resource(struct acpi_resource *ares, void *data)
+{
+	struct gpio_dep_ctx *ctx = data;
+	struct acpi_resource_gpio *agpio;
+	struct gpio_controller_ref *ref, *tmp;
+	bool found = false;
+
+	if (ares->type != ACPI_RESOURCE_TYPE_GPIO)
+		return 1;
+
+	agpio = &ares->data.gpio;
+	if (agpio->connection_type != ACPI_RESOURCE_GPIO_TYPE_INT)
+		return 1;
+
+	/* Check if we've already tracked this GPIO controller */
+	list_for_each_entry(tmp, &ctx->gpio_controllers, node) {
+		if (!strcmp(tmp->path, agpio->resource_source.string_ptr)) {
+			found = true;
+			break;
+		}
+	}
+
+	if (!found) {
+		ref = kzalloc_obj(*ref, GFP_KERNEL);
+		if (!ref) {
+			ctx->ret = -ENOMEM;
+			return 0;
+		}
+
+		ref->path = kstrdup(agpio->resource_source.string_ptr, GFP_KERNEL);
+		if (!ref->path) {
+			kfree(ref);
+			ctx->ret = -ENOMEM;
+			return 0;
+		}
+
+		list_add_tail(&ref->node, &ctx->gpio_controllers);
+	}
+
+	return 1;
+}
+
+static int check_child_gpioint(struct acpi_device *adev, void *data)
+{
+	struct gpio_dep_ctx *ctx = data;
+	struct list_head res_list;
+	int ret;
+
+	INIT_LIST_HEAD(&res_list);
+
+	ret = acpi_dev_get_resources(adev, &res_list, check_gpioint_resource, ctx);
+	acpi_dev_free_resource_list(&res_list);
+
+	if (ctx->ret < 0)
+		return ctx->ret;
+
+	return 0;
+}
+
+static int i2c_dw_check_gpio_dependencies(struct device *dev)
+{
+	struct acpi_device *adev = ACPI_COMPANION(dev);
+	struct gpio_dep_ctx ctx = { .ret = 0 };
+	struct gpio_controller_ref *ref, *tmp;
+	int ret = 0;
+
+	if (!adev)
+		return 0;
+
+	INIT_LIST_HEAD(&ctx.gpio_controllers);
+
+	/* Walk all child devices and collect GpioInt controller references */
+	ret = acpi_dev_for_each_child(adev, check_child_gpioint, &ctx);
+	if (ret < 0 || ctx.ret < 0) {
+		ret = ctx.ret ?: ret;
+		goto cleanup;
+	}
+
+	/* For each GPIO controller, check if its parent device is bound */
+	list_for_each_entry(ref, &ctx.gpio_controllers, node) {
+		acpi_handle handle;
+		acpi_status status;
+		struct acpi_device *gpio_adev;
+		struct device *gpio_dev;
+
+		status = acpi_get_handle(NULL, ref->path, &handle);
+		if (ACPI_FAILURE(status))
+			continue;
+
+		gpio_adev = acpi_fetch_acpi_dev(handle);
+		if (!gpio_adev)
+			continue;
+
+		gpio_dev = acpi_get_first_physical_node(gpio_adev);
+		acpi_dev_put(gpio_adev);
+
+		if (!gpio_dev) {
+			ret = -EPROBE_DEFER;
+			goto cleanup;
+		}
+
+		/*
+		 * Check if the GPIO controller's device is bound. If not,
+		 * defer probe to ensure GPIO initialization (including IRQ
+		 * setup and quirks) is complete before we enumerate I2C
+		 * child devices.
+		 */
+		scoped_guard(device, gpio_dev) {
+			if (!device_is_bound(gpio_dev)) {
+				ret = -EPROBE_DEFER;
+				goto cleanup;
+			}
+		}
+
+		put_device(gpio_dev);
+	}
+
+cleanup:
+	list_for_each_entry_safe(ref, tmp, &ctx.gpio_controllers, node) {
+		list_del(&ref->node);
+		kfree(ref->path);
+		kfree(ref);
+	}
+
+	return ret;
+}
+#else
+static int i2c_dw_check_gpio_dependencies(struct device *dev)
+{
+	return 0;
+}
+#endif /* CONFIG_ACPI */
+
 static int dw_i2c_plat_probe(struct platform_device *pdev)
 {
 	u32 flags = (uintptr_t)device_get_match_data(&pdev->dev);
@@ -138,6 +283,14 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
 	struct dw_i2c_dev *dev;
 	int irq, ret;
 
+	/*
+	 * Check if any child devices have GpioInt resources, and if so,
+	 * defer probe until those GPIO controllers are fully bound.
+	 */
+	ret = i2c_dw_check_gpio_dependencies(device);
+	if (ret)
+		return ret;
+
 	irq = platform_get_irq_optional(pdev, 0);
 	if (irq == -ENXIO)
 		flags |= ACCESS_POLLING;
-- 
2.43.0

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

On Tue, May 19, 2026 at 02:23, Mario Limonciello wrote:
> In the same line of thinking - how about something like this instead
> (AI generated and attached).
>
> Basically walk through the resources at probe time and make sure they're
> all bound.

Tested. Works perfectly — clean boot, no arbitration errors, touchscreen
and stylus fully functional:

  patch 1 + generic GPIO dependency check:   clean boot, touchscreen works

The generic approach is better. With this patch, patch 2 (the
DMI-specific i2c-designware deferral) is no longer needed.

Note: I applied kzalloc(sizeof(*ref), GFP_KERNEL) in place of
kzalloc_obj(*ref, GFP_KERNEL), and moved the goto outside the
scoped_guard using a local bool. Happy to share the exact diff I tested
if useful.

Thanks,
Hardik

On Wed, 20 May 2026 at 02:23, Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 5/19/26 14:49, Hardik Prakash wrote:
> > On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
> >> I like this idea. I guess something like this:
> >> [gpiolib-acpi-core.c patch]
> >
> > Tested patch 1 + gpiolib-acpi deferral, without patch 2. Arbitration
> > errors persist:
> >
> >    patch 1 + gpiolib-acpi deferral:   arbitration errors, WACF2200 does not probe
> >    patch 1 + patch 2 (v5):           clean boot, touchscreen fully functional
> >
> > I think the reason is that i2c-designware does not call acpi_get_gpiod()
> > during its probe. The GpioInt resource is on the WACF2200 touchscreen
> > device (TPNL), not on the I2C controller itself. So the deferral in
> > acpi_get_gpiod() never triggers for AMDI0010:02 -- nothing in that probe
> > path requests a GPIO descriptor.
> >
> > The race is between amd_gpio_probe() completing and dw_i2c_plat_probe()
> > starting for AMDI0010:02. Without something that explicitly checks
> > whether the GPIO controller is fully bound before the I2C controller
> > probes, the race remains.
> >
>
> In the same linke of thinking - how about something like this instead
> (AI generated and attached).
>
> Basically walk through the resources at probe time and make sure they're
> all bound.
>
> > Thanks,
> > Hardik
> >
> > On Wed, 20 May 2026 at 00:37, Hardik Prakash
> > <hardikprakash.official@gmail.com> wrote:
> >>
> >> On Tue, May 19, 2026 at 19:58, Mario Limonciello wrote:
> >>> You add a debug statement to amd_gpio_irq_enable() too right? Can you
> >>> please share your debugging messages patch and full log?
> >>
> >> I did not add debug to amd_gpio_irq_enable() - the statements were
> >> only in amd_gpio_probe() and dw_i2c_plat_probe(). I can add one there
> >> if useful, but given Bart's suggestion below I'll hold off unless
> >> needed.
> >>
> >>> What is the boot time impact to adding device_is_bound() check?
> >>
> >> I haven't measured this explicitly. The deferral only fires on DMI-
> >> matched hardware (Lenovo 83TD), so on other machines dw_i2c_defer_for_
> >> amd_gpio() returns 0 immediately with no overhead.
> >>
> >> On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
> >>> I like this idea.
> >>
> >> I'll test this patch, and let you know how it goes.
> >>
> >> Thanks,
> >> Hardik
> >>
> >> On Tue, 19 May 2026 at 20:18, Mario Limonciello
> >> <mario.limonciello@amd.com> wrote:
> >>>
> >>>
> >>>
> >>> On 5/19/26 09:39, Bartosz Golaszewski wrote:
> >>>> On Tue, May 19, 2026 at 4:28 PM Mario Limonciello
> >>>> <mario.limonciello@amd.com> wrote:
> >>>>>
> >>>>>>
> >>>>>> gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
> >>>>>> system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
> >>>>>> at 0.301454 while amd_gpio_probe() is still completing. This is why
> >>>>>> device_is_bound() works and initcall promotion does not -- it waits for
> >>>>>> probe completion, not just gpiochip registration.
> >>>>>
> >>>>> What is the boot time impact to adding device_is_bound() check?
> >>>>>
> >>>>> Bartosz, thoughts?
> >>>>>
> >>>>
> >>>> My thoughts are that ACPI could use some fw_devlink. :) It's not a new
> >>>> problem, we've fixed it for OF systems.
> >>>>
> >>>> Could we modify gpiolib-acpi.c to return -EPROBE_DEFER if the parent
> >>>> device of the GPIO chip is not bound yet instead? When resolving the
> >>>> reference to the remote GPIO controller we have an address of the
> >>>> struct acpi_device. I suppose there's a platform device that is its
> >>>> child and then the logical GPIO controller device, is that correct?
> >>>> Can we check if the platform device in question is bound at the
> >>>> subsystem level?
> >>>>
> >>>> Bart
> >>>
> >>> I like this idea.  I guess something like this:
> >>>
> >>> diff --git a/drivers/gpio/gpiolib-acpi-core.c
> >>> b/drivers/gpio/gpiolib-acpi-core.c
> >>> index eb8a40cfb7a98..e3511398b1f84 100644
> >>> --- a/drivers/gpio/gpiolib-acpi-core.c
> >>> +++ b/drivers/gpio/gpiolib-acpi-core.c
> >>> @@ -142,6 +142,13 @@ static struct gpio_desc *acpi_get_gpiod(char *path,
> >>> unsigned int pin)
> >>>           if (!gdev)
> >>>                   return ERR_PTR(-EPROBE_DEFER);
> >>>
> >>> +       if (gdev->dev.parent) {
> >>> +               scoped_guard(device, gdev->dev.parent) {
> >>> +                       if (!device_is_bound(gdev->dev.parent))
> >>> +                               return ERR_PTR(-EPROBE_DEFER);
> >>> +               }
> >>> +       }
> >>> +
> >>>           /*
> >>>            * FIXME: keep track of the reference to the GPIO device somehow
> >>>            * instead of putting it here.
> >>>

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

On Tue, May 19, 2026 at 02:23, Mario Limonciello wrote:
> In the same line of thinking - how about something like this instead
> (AI generated and attached).

I've cleaned up your patch (fixed kzalloc_obj, moved goto outside
scoped_guard, wrote a proper commit message) and am planning to submit
it as v6 with Co-developed-by and Signed-off-by carrying your name.

Please let me know if you're happy with that, or if you'd prefer to
submit it yourself.

Thanks,
Hardik

On Wed, 20 May 2026 at 10:32, Hardik Prakash
<hardikprakash.official@gmail.com> wrote:
>
> On Tue, May 19, 2026 at 02:23, Mario Limonciello wrote:
> > In the same line of thinking - how about something like this instead
> > (AI generated and attached).
> >
> > Basically walk through the resources at probe time and make sure they're
> > all bound.
>
> Tested. Works perfectly — clean boot, no arbitration errors, touchscreen
> and stylus fully functional:
>
>   patch 1 + generic GPIO dependency check:   clean boot, touchscreen works
>
> The generic approach is better. With this patch, patch 2 (the
> DMI-specific i2c-designware deferral) is no longer needed.
>
> Note: I applied kzalloc(sizeof(*ref), GFP_KERNEL) in place of
> kzalloc_obj(*ref, GFP_KERNEL), and moved the goto outside the
> scoped_guard using a local bool. Happy to share the exact diff I tested
> if useful.
>
> Thanks,
> Hardik
>
> On Wed, 20 May 2026 at 02:23, Mario Limonciello
> <mario.limonciello@amd.com> wrote:
> >
> >
> >
> > On 5/19/26 14:49, Hardik Prakash wrote:
> > > On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
> > >> I like this idea. I guess something like this:
> > >> [gpiolib-acpi-core.c patch]
> > >
> > > Tested patch 1 + gpiolib-acpi deferral, without patch 2. Arbitration
> > > errors persist:
> > >
> > >    patch 1 + gpiolib-acpi deferral:   arbitration errors, WACF2200 does not probe
> > >    patch 1 + patch 2 (v5):           clean boot, touchscreen fully functional
> > >
> > > I think the reason is that i2c-designware does not call acpi_get_gpiod()
> > > during its probe. The GpioInt resource is on the WACF2200 touchscreen
> > > device (TPNL), not on the I2C controller itself. So the deferral in
> > > acpi_get_gpiod() never triggers for AMDI0010:02 -- nothing in that probe
> > > path requests a GPIO descriptor.
> > >
> > > The race is between amd_gpio_probe() completing and dw_i2c_plat_probe()
> > > starting for AMDI0010:02. Without something that explicitly checks
> > > whether the GPIO controller is fully bound before the I2C controller
> > > probes, the race remains.
> > >
> >
> > In the same linke of thinking - how about something like this instead
> > (AI generated and attached).
> >
> > Basically walk through the resources at probe time and make sure they're
> > all bound.
> >
> > > Thanks,
> > > Hardik
> > >
> > > On Wed, 20 May 2026 at 00:37, Hardik Prakash
> > > <hardikprakash.official@gmail.com> wrote:
> > >>
> > >> On Tue, May 19, 2026 at 19:58, Mario Limonciello wrote:
> > >>> You add a debug statement to amd_gpio_irq_enable() too right? Can you
> > >>> please share your debugging messages patch and full log?
> > >>
> > >> I did not add debug to amd_gpio_irq_enable() - the statements were
> > >> only in amd_gpio_probe() and dw_i2c_plat_probe(). I can add one there
> > >> if useful, but given Bart's suggestion below I'll hold off unless
> > >> needed.
> > >>
> > >>> What is the boot time impact to adding device_is_bound() check?
> > >>
> > >> I haven't measured this explicitly. The deferral only fires on DMI-
> > >> matched hardware (Lenovo 83TD), so on other machines dw_i2c_defer_for_
> > >> amd_gpio() returns 0 immediately with no overhead.
> > >>
> > >> On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
> > >>> I like this idea.
> > >>
> > >> I'll test this patch, and let you know how it goes.
> > >>
> > >> Thanks,
> > >> Hardik
> > >>
> > >> On Tue, 19 May 2026 at 20:18, Mario Limonciello
> > >> <mario.limonciello@amd.com> wrote:
> > >>>
> > >>>
> > >>>
> > >>> On 5/19/26 09:39, Bartosz Golaszewski wrote:
> > >>>> On Tue, May 19, 2026 at 4:28 PM Mario Limonciello
> > >>>> <mario.limonciello@amd.com> wrote:
> > >>>>>
> > >>>>>>
> > >>>>>> gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
> > >>>>>> system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
> > >>>>>> at 0.301454 while amd_gpio_probe() is still completing. This is why
> > >>>>>> device_is_bound() works and initcall promotion does not -- it waits for
> > >>>>>> probe completion, not just gpiochip registration.
> > >>>>>
> > >>>>> What is the boot time impact to adding device_is_bound() check?
> > >>>>>
> > >>>>> Bartosz, thoughts?
> > >>>>>
> > >>>>
> > >>>> My thoughts are that ACPI could use some fw_devlink. :) It's not a new
> > >>>> problem, we've fixed it for OF systems.
> > >>>>
> > >>>> Could we modify gpiolib-acpi.c to return -EPROBE_DEFER if the parent
> > >>>> device of the GPIO chip is not bound yet instead? When resolving the
> > >>>> reference to the remote GPIO controller we have an address of the
> > >>>> struct acpi_device. I suppose there's a platform device that is its
> > >>>> child and then the logical GPIO controller device, is that correct?
> > >>>> Can we check if the platform device in question is bound at the
> > >>>> subsystem level?
> > >>>>
> > >>>> Bart
> > >>>
> > >>> I like this idea.  I guess something like this:
> > >>>
> > >>> diff --git a/drivers/gpio/gpiolib-acpi-core.c
> > >>> b/drivers/gpio/gpiolib-acpi-core.c
> > >>> index eb8a40cfb7a98..e3511398b1f84 100644
> > >>> --- a/drivers/gpio/gpiolib-acpi-core.c
> > >>> +++ b/drivers/gpio/gpiolib-acpi-core.c
> > >>> @@ -142,6 +142,13 @@ static struct gpio_desc *acpi_get_gpiod(char *path,
> > >>> unsigned int pin)
> > >>>           if (!gdev)
> > >>>                   return ERR_PTR(-EPROBE_DEFER);
> > >>>
> > >>> +       if (gdev->dev.parent) {
> > >>> +               scoped_guard(device, gdev->dev.parent) {
> > >>> +                       if (!device_is_bound(gdev->dev.parent))
> > >>> +                               return ERR_PTR(-EPROBE_DEFER);
> > >>> +               }
> > >>> +       }
> > >>> +
> > >>>           /*
> > >>>            * FIXME: keep track of the reference to the GPIO device somehow
> > >>>            * instead of putting it here.
> > >>>

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Mario Limonciello]

On 5/23/26 02:51, Hardik Prakash wrote:
> On Tue, May 19, 2026 at 02:23, Mario Limonciello wrote:
>> In the same line of thinking - how about something like this instead
>> (AI generated and attached).
> 
> I've cleaned up your patch (fixed kzalloc_obj, moved goto outside
> scoped_guard, wrote a proper commit message) and am planning to submit
> it as v6 with Co-developed-by and Signed-off-by carrying your name.
> 
> Please let me know if you're happy with that, or if you'd prefer to
> submit it yourself.

It was 100% written by the robot, just shared by me for a reference.
I don't think it needs a S-o-b, you can leave a Suggested by for me at most.

Go ahead and drive it forward for discussion.

> 
> Thanks,
> Hardik
> 
> On Wed, 20 May 2026 at 10:32, Hardik Prakash
> <hardikprakash.official@gmail.com> wrote:
>>
>> On Tue, May 19, 2026 at 02:23, Mario Limonciello wrote:
>>> In the same line of thinking - how about something like this instead
>>> (AI generated and attached).
>>>
>>> Basically walk through the resources at probe time and make sure they're
>>> all bound.
>>
>> Tested. Works perfectly — clean boot, no arbitration errors, touchscreen
>> and stylus fully functional:
>>
>>    patch 1 + generic GPIO dependency check:   clean boot, touchscreen works
>>
>> The generic approach is better. With this patch, patch 2 (the
>> DMI-specific i2c-designware deferral) is no longer needed.
>>
>> Note: I applied kzalloc(sizeof(*ref), GFP_KERNEL) in place of
>> kzalloc_obj(*ref, GFP_KERNEL), and moved the goto outside the
>> scoped_guard using a local bool. Happy to share the exact diff I tested
>> if useful.
>>
>> Thanks,
>> Hardik
>>
>> On Wed, 20 May 2026 at 02:23, Mario Limonciello
>> <mario.limonciello@amd.com> wrote:
>>>
>>>
>>>
>>> On 5/19/26 14:49, Hardik Prakash wrote:
>>>> On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
>>>>> I like this idea. I guess something like this:
>>>>> [gpiolib-acpi-core.c patch]
>>>>
>>>> Tested patch 1 + gpiolib-acpi deferral, without patch 2. Arbitration
>>>> errors persist:
>>>>
>>>>     patch 1 + gpiolib-acpi deferral:   arbitration errors, WACF2200 does not probe
>>>>     patch 1 + patch 2 (v5):           clean boot, touchscreen fully functional
>>>>
>>>> I think the reason is that i2c-designware does not call acpi_get_gpiod()
>>>> during its probe. The GpioInt resource is on the WACF2200 touchscreen
>>>> device (TPNL), not on the I2C controller itself. So the deferral in
>>>> acpi_get_gpiod() never triggers for AMDI0010:02 -- nothing in that probe
>>>> path requests a GPIO descriptor.
>>>>
>>>> The race is between amd_gpio_probe() completing and dw_i2c_plat_probe()
>>>> starting for AMDI0010:02. Without something that explicitly checks
>>>> whether the GPIO controller is fully bound before the I2C controller
>>>> probes, the race remains.
>>>>
>>>
>>> In the same linke of thinking - how about something like this instead
>>> (AI generated and attached).
>>>
>>> Basically walk through the resources at probe time and make sure they're
>>> all bound.
>>>
>>>> Thanks,
>>>> Hardik
>>>>
>>>> On Wed, 20 May 2026 at 00:37, Hardik Prakash
>>>> <hardikprakash.official@gmail.com> wrote:
>>>>>
>>>>> On Tue, May 19, 2026 at 19:58, Mario Limonciello wrote:
>>>>>> You add a debug statement to amd_gpio_irq_enable() too right? Can you
>>>>>> please share your debugging messages patch and full log?
>>>>>
>>>>> I did not add debug to amd_gpio_irq_enable() - the statements were
>>>>> only in amd_gpio_probe() and dw_i2c_plat_probe(). I can add one there
>>>>> if useful, but given Bart's suggestion below I'll hold off unless
>>>>> needed.
>>>>>
>>>>>> What is the boot time impact to adding device_is_bound() check?
>>>>>
>>>>> I haven't measured this explicitly. The deferral only fires on DMI-
>>>>> matched hardware (Lenovo 83TD), so on other machines dw_i2c_defer_for_
>>>>> amd_gpio() returns 0 immediately with no overhead.
>>>>>
>>>>> On Tue, May 19, 2026 at 20:18, Mario Limonciello wrote:
>>>>>> I like this idea.
>>>>>
>>>>> I'll test this patch, and let you know how it goes.
>>>>>
>>>>> Thanks,
>>>>> Hardik
>>>>>
>>>>> On Tue, 19 May 2026 at 20:18, Mario Limonciello
>>>>> <mario.limonciello@amd.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/19/26 09:39, Bartosz Golaszewski wrote:
>>>>>>> On Tue, May 19, 2026 at 4:28 PM Mario Limonciello
>>>>>>> <mario.limonciello@amd.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> gpiochip_add_data() at 0.285952 makes the GPIO chip visible to the
>>>>>>>>> system before amd_gpio_probe() has finished. AMDI0010:02 starts probing
>>>>>>>>> at 0.301454 while amd_gpio_probe() is still completing. This is why
>>>>>>>>> device_is_bound() works and initcall promotion does not -- it waits for
>>>>>>>>> probe completion, not just gpiochip registration.
>>>>>>>>
>>>>>>>> What is the boot time impact to adding device_is_bound() check?
>>>>>>>>
>>>>>>>> Bartosz, thoughts?
>>>>>>>>
>>>>>>>
>>>>>>> My thoughts are that ACPI could use some fw_devlink. :) It's not a new
>>>>>>> problem, we've fixed it for OF systems.
>>>>>>>
>>>>>>> Could we modify gpiolib-acpi.c to return -EPROBE_DEFER if the parent
>>>>>>> device of the GPIO chip is not bound yet instead? When resolving the
>>>>>>> reference to the remote GPIO controller we have an address of the
>>>>>>> struct acpi_device. I suppose there's a platform device that is its
>>>>>>> child and then the logical GPIO controller device, is that correct?
>>>>>>> Can we check if the platform device in question is bound at the
>>>>>>> subsystem level?
>>>>>>>
>>>>>>> Bart
>>>>>>
>>>>>> I like this idea.  I guess something like this:
>>>>>>
>>>>>> diff --git a/drivers/gpio/gpiolib-acpi-core.c
>>>>>> b/drivers/gpio/gpiolib-acpi-core.c
>>>>>> index eb8a40cfb7a98..e3511398b1f84 100644
>>>>>> --- a/drivers/gpio/gpiolib-acpi-core.c
>>>>>> +++ b/drivers/gpio/gpiolib-acpi-core.c
>>>>>> @@ -142,6 +142,13 @@ static struct gpio_desc *acpi_get_gpiod(char *path,
>>>>>> unsigned int pin)
>>>>>>            if (!gdev)
>>>>>>                    return ERR_PTR(-EPROBE_DEFER);
>>>>>>
>>>>>> +       if (gdev->dev.parent) {
>>>>>> +               scoped_guard(device, gdev->dev.parent) {
>>>>>> +                       if (!device_is_bound(gdev->dev.parent))
>>>>>> +                               return ERR_PTR(-EPROBE_DEFER);
>>>>>> +               }
>>>>>> +       }
>>>>>> +
>>>>>>            /*
>>>>>>             * FIXME: keep track of the reference to the GPIO device somehow
>>>>>>             * instead of putting it here.
>>>>>>

Re: [PATCH v5 0/1] i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11

[Andy Shevchenko]

On Mon, May 18, 2026 at 05:58:12PM +0530, Hardik Prakash wrote:
> Patch 1/2 (pinctrl-amd GPIO IRQ fix) is already in Linus Walleij's
> tree. This series contains only the i2c-designware probe ordering fix,
> based on top of that commit.
> 
> The root cause: i2c_designware probes AMDI0010:02 before pinctrl-amd
> completes, so GPIO 157 (WACF2200 GpioInt per ACPI _CRS) has its
> interrupt bits cleared when the first I2C transaction is attempted,
> causing lost arbitration errors.
> 
> A higher-level ACPI devlink approach was investigated in response to
> Bartosz Golaszewski's suggestion. The DSDT has no _DEP object linking
> AMDI0010:02 to AMDI0030:00, so fw_devlink has nothing to act on.
> Setting this up at the ACPI layer would require either a firmware
> change to add _DEP, or a DMI quirk in the ACPI scan path — equally
> quirk-based as the current approach.
> 
> v5:
>  - Add blank line before #include <linux/acpi.h> (Bartosz Golaszewski)
>  - Use scoped_guard(device, gpio_dev) (Bartosz Golaszewski)

Too fast, I have a comment in v4, do you have a chance to read it?

-- 
With Best Regards,
Andy Shevchenko