| Message ID | 20260518122814.8975-1-hardikprakash.official@gmail.com |
|---|---|
| Headers | show |
| Series | i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7 14AGP11 | expand |
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
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 >
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 >>
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
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.
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?
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
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
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
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?
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 > >
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 >> >>
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 > >> > >> >
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 >>>> >>>> >>
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
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.
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. >
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. > >
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. >>>
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. > >>>
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. > > >>>
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. >>>>>>
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