* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 10:08 ` [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound Hardik Prakash
@ 2026-05-29 10:12 ` Mario Limonciello
2026-05-29 14:42 ` Wolfram Sang
2026-06-02 22:41 ` Andy Shevchenko
2026-05-29 14:43 ` Wolfram Sang
` (2 subsequent siblings)
3 siblings, 2 replies; 24+ messages in thread
From: Mario Limonciello @ 2026-05-29 10:12 UTC (permalink / raw)
To: Hardik Prakash, linux-i2c
Cc: linux-gpio, wsa, andriy.shevchenko, brgl, basavaraj.natikar,
linusw, Bartosz Golaszewski, Mario Limonciello (AMD),
kernel test robot
On 5/29/26 12:08, Hardik Prakash wrote:
> 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.
>
> The probe ordering race was confirmed via dynamic debug tracing:
>
> 0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
> 0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
> 0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
> 2.348157 lost arbitration
>
> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Assisted-by: Claude:claude-sonnet-4-6
> Assisted-by: GPT-Codex:gpt-5.2-codex
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202605240959.Kcf1lIg4-lkp@intel.com/
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
Fixes: 3812a9e84265a ("pinctrl-amd: enable IRQ for WACF2200 touchscreen
on Lenovo Yoga 7 14AGP11")
> ---
> drivers/i2c/busses/i2c-designware-platdrv.c | 156 ++++++++++++++++++++
> 1 file changed, 156 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 3351c4a9ef11..1c01b0460385 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>
> @@ -130,6 +132,152 @@ 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(sizeof(*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;
> +
> + INIT_LIST_HEAD(&res_list);
> +
> + 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;
> + bool bound;
> +
> + 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) {
> + bound = device_is_bound(gpio_dev);
> + }
> + if (!bound) {
> + put_device(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 +286,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;
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 10:12 ` Mario Limonciello
@ 2026-05-29 14:42 ` Wolfram Sang
2026-05-29 14:43 ` Mario Limonciello
2026-06-02 22:41 ` Andy Shevchenko
1 sibling, 1 reply; 24+ messages in thread
From: Wolfram Sang @ 2026-05-29 14:42 UTC (permalink / raw)
To: Mario Limonciello
Cc: Hardik Prakash, linux-i2c, linux-gpio, wsa, andriy.shevchenko,
brgl, basavaraj.natikar, linusw, Bartosz Golaszewski,
kernel test robot
[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]
On Fri, May 29, 2026 at 12:12:31PM +0200, Mario Limonciello wrote:
>
>
> On 5/29/26 12:08, Hardik Prakash wrote:
> > 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.
> >
> > The probe ordering race was confirmed via dynamic debug tracing:
> >
> > 0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
> > 0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
> > 0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
> > 2.348157 lost arbitration
> >
> > Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> > Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
> > Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> > Assisted-by: Claude:claude-sonnet-4-6
> > Assisted-by: GPT-Codex:gpt-5.2-codex
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202605240959.Kcf1lIg4-lkp@intel.com/
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
>
> Fixes: 3812a9e84265a ("pinctrl-amd: enable IRQ for WACF2200 touchscreen on
> Lenovo Yoga 7 14AGP11")
No Rev-by from you, Mario?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 14:42 ` Wolfram Sang
@ 2026-05-29 14:43 ` Mario Limonciello
0 siblings, 0 replies; 24+ messages in thread
From: Mario Limonciello @ 2026-05-29 14:43 UTC (permalink / raw)
To: Wolfram Sang
Cc: Hardik Prakash, linux-i2c, linux-gpio, wsa, andriy.shevchenko,
brgl, basavaraj.natikar, linusw, Bartosz Golaszewski,
kernel test robot
On 5/29/26 16:42, Wolfram Sang wrote:
> On Fri, May 29, 2026 at 12:12:31PM +0200, Mario Limonciello wrote:
>>
>>
>> On 5/29/26 12:08, Hardik Prakash wrote:
>>> 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.
>>>
>>> The probe ordering race was confirmed via dynamic debug tracing:
>>>
>>> 0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
>>> 0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
>>> 0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
>>> 2.348157 lost arbitration
>>>
>>> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
>>> Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
>>> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
>>> Assisted-by: Claude:claude-sonnet-4-6
>>> Assisted-by: GPT-Codex:gpt-5.2-codex
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Closes: https://lore.kernel.org/oe-kbuild-all/202605240959.Kcf1lIg4-lkp@intel.com/
>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
>>
>> Fixes: 3812a9e84265a ("pinctrl-amd: enable IRQ for WACF2200 touchscreen on
>> Lenovo Yoga 7 14AGP11")
>
> No Rev-by from you, Mario?
>
I added to the individual patches instead, all LGTM.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 10:12 ` Mario Limonciello
2026-05-29 14:42 ` Wolfram Sang
@ 2026-06-02 22:41 ` Andy Shevchenko
1 sibling, 0 replies; 24+ messages in thread
From: Andy Shevchenko @ 2026-06-02 22:41 UTC (permalink / raw)
To: Mario Limonciello
Cc: Hardik Prakash, linux-i2c, linux-gpio, wsa, brgl,
basavaraj.natikar, linusw, Bartosz Golaszewski, kernel test robot
On Fri, May 29, 2026 at 12:12:31PM +0200, Mario Limonciello wrote:
> On 5/29/26 12:08, Hardik Prakash wrote:
> > 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.
> >
> > The probe ordering race was confirmed via dynamic debug tracing:
> >
> > 0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
> > 0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
> > 0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
> > 2.348157 lost arbitration
> >
> > Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> > Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
> > Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> > Assisted-by: Claude:claude-sonnet-4-6
> > Assisted-by: GPT-Codex:gpt-5.2-codex
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202605240959.Kcf1lIg4-lkp@intel.com/
This patch definitely wasn't the result of the above report. These two tags are
misused.
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
> Fixes: 3812a9e84265a ("pinctrl-amd: enable IRQ for WACF2200 touchscreen on
> Lenovo Yoga 7 14AGP11")
Must be oneline.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 10:08 ` [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound Hardik Prakash
2026-05-29 10:12 ` Mario Limonciello
@ 2026-05-29 14:43 ` Wolfram Sang
2026-05-29 20:46 ` Linus Walleij
2026-06-02 18:53 ` Nathan Chancellor
2026-06-02 22:55 ` Andy Shevchenko
3 siblings, 1 reply; 24+ messages in thread
From: Wolfram Sang @ 2026-05-29 14:43 UTC (permalink / raw)
To: Hardik Prakash
Cc: linux-i2c, linux-gpio, wsa, andriy.shevchenko, mario.limonciello,
brgl, basavaraj.natikar, linusw, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]
On Fri, May 29, 2026 at 03:38:37PM +0530, Hardik Prakash wrote:
> 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.
>
> The probe ordering race was confirmed via dynamic debug tracing:
>
> 0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
> 0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
> 0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
> 2.348157 lost arbitration
>
> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Assisted-by: Claude:claude-sonnet-4-6
> Assisted-by: GPT-Codex:gpt-5.2-codex
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202605240959.Kcf1lIg4-lkp@intel.com/
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
In case this goes in via some other tree:
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 14:43 ` Wolfram Sang
@ 2026-05-29 20:46 ` Linus Walleij
2026-05-29 20:55 ` Wolfram Sang
0 siblings, 1 reply; 24+ messages in thread
From: Linus Walleij @ 2026-05-29 20:46 UTC (permalink / raw)
To: Wolfram Sang
Cc: Hardik Prakash, linux-i2c, linux-gpio, wsa, andriy.shevchenko,
mario.limonciello, brgl, basavaraj.natikar, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
On Fri, May 29, 2026 at 4:43 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> In case this goes in via some other tree:
>
> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
I queued the revert in the pinctrl fixes, you can take this one (2/2).
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 20:46 ` Linus Walleij
@ 2026-05-29 20:55 ` Wolfram Sang
2026-05-29 21:59 ` Linus Walleij
0 siblings, 1 reply; 24+ messages in thread
From: Wolfram Sang @ 2026-05-29 20:55 UTC (permalink / raw)
To: Linus Walleij
Cc: Hardik Prakash, linux-i2c, linux-gpio, wsa, andriy.shevchenko,
mario.limonciello, brgl, basavaraj.natikar, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
> > In case this goes in via some other tree:
> >
> > Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> I queued the revert in the pinctrl fixes, you can take this one (2/2).
Is there really no dependency on patch 1? I'd feel safer if you'd take
this as well...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 20:55 ` Wolfram Sang
@ 2026-05-29 21:59 ` Linus Walleij
2026-05-29 22:46 ` Wolfram Sang
2026-06-02 22:44 ` Andy Shevchenko
0 siblings, 2 replies; 24+ messages in thread
From: Linus Walleij @ 2026-05-29 21:59 UTC (permalink / raw)
To: Wolfram Sang
Cc: Hardik Prakash, linux-i2c, linux-gpio, wsa, andriy.shevchenko,
mario.limonciello, brgl, basavaraj.natikar, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
On Fri, May 29, 2026 at 10:55 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > > In case this goes in via some other tree:
> > >
> > > Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> >
> > I queued the revert in the pinctrl fixes, you can take this one (2/2).
>
> Is there really no dependency on patch 1? I'd feel safer if you'd take
> this as well...
OK then, you're right. Let's keep it together.
Patch applied!
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 21:59 ` Linus Walleij
@ 2026-05-29 22:46 ` Wolfram Sang
2026-06-02 22:44 ` Andy Shevchenko
1 sibling, 0 replies; 24+ messages in thread
From: Wolfram Sang @ 2026-05-29 22:46 UTC (permalink / raw)
To: Linus Walleij
Cc: Hardik Prakash, linux-i2c, linux-gpio, wsa, andriy.shevchenko,
mario.limonciello, brgl, basavaraj.natikar, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
[-- Attachment #1: Type: text/plain, Size: 60 bytes --]
> OK then, you're right. Let's keep it together.
Thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 21:59 ` Linus Walleij
2026-05-29 22:46 ` Wolfram Sang
@ 2026-06-02 22:44 ` Andy Shevchenko
1 sibling, 0 replies; 24+ messages in thread
From: Andy Shevchenko @ 2026-06-02 22:44 UTC (permalink / raw)
To: Linus Walleij
Cc: Wolfram Sang, Hardik Prakash, linux-i2c, linux-gpio, wsa,
mario.limonciello, brgl, basavaraj.natikar, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
On Fri, May 29, 2026 at 11:59:24PM +0200, Linus Walleij wrote:
> On Fri, May 29, 2026 at 10:55 PM Wolfram Sang
> <wsa+renesas@sang-engineering.com> wrote:
> > > > In case this goes in via some other tree:
> > > >
> > > > Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > >
> > > I queued the revert in the pinctrl fixes, you can take this one (2/2).
> >
> > Is there really no dependency on patch 1? I'd feel safer if you'd take
> > this as well...
>
> OK then, you're right. Let's keep it together.
>
> Patch applied!
Can we drop this patch or revert? I would like (as I said earlier) to review it
closer, I just returned from conferences and vacation and got a ~16 hundreds of
new emails to go through.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 10:08 ` [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound Hardik Prakash
2026-05-29 10:12 ` Mario Limonciello
2026-05-29 14:43 ` Wolfram Sang
@ 2026-06-02 18:53 ` Nathan Chancellor
2026-06-02 19:50 ` Hardik Prakash
2026-06-02 22:55 ` Andy Shevchenko
3 siblings, 1 reply; 24+ messages in thread
From: Nathan Chancellor @ 2026-06-02 18:53 UTC (permalink / raw)
To: Hardik Prakash
Cc: linux-i2c, linux-gpio, wsa, andriy.shevchenko, mario.limonciello,
brgl, basavaraj.natikar, linusw, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
Hi Hardik,
On Fri, May 29, 2026 at 03:38:37PM +0530, Hardik Prakash wrote:
> 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.
>
> The probe ordering race was confirmed via dynamic debug tracing:
>
> 0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
> 0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
> 0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
> 2.348157 lost arbitration
>
> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Assisted-by: Claude:claude-sonnet-4-6
> Assisted-by: GPT-Codex:gpt-5.2-codex
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202605240959.Kcf1lIg4-lkp@intel.com/
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
I bisected boot issues with a few of my test machines to this change in -next
as commit ef76a3a28c79 ("i2c: designware: defer probe if child GpioInt
controllers are not bound"). I consistently get no display output and I do not
have serial access to these machines, so I do not have much to go on here at
the moment. Occasionally, the network controller will be initialized so I can
remote in but I have not been able to do it recently to try and gather logs.
What information would be useful for trying to figure out what is going on
here? I seem to recall a crash in strcmp() in one log but I cannot be too sure
since it was late at night when I was doing my initial triage.
# bad: [08484c504b55a98bd100527fbe10a3caf55ff3ff] Add linux-next specific files for 20260601
# good: [e43ffb69e0438cddd72aaa30898b4dc446f664f8] Linux 7.1-rc6
git bisect start '08484c504b55a98bd100527fbe10a3caf55ff3ff' 'e43ffb69e0438cddd72aaa30898b4dc446f664f8'
# good: [57fb910db1b6051476b91a4d4ae18bc027a7f36d] Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
git bisect good 57fb910db1b6051476b91a4d4ae18bc027a7f36d
# good: [18ea7e3ca91e7a9eb9e43c11154350cec160830b] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox.git
git bisect good 18ea7e3ca91e7a9eb9e43c11154350cec160830b
# good: [a5696dd9c080352e25b576acf24450cef255b6eb] Merge branch 'tty-next' of https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
git bisect good a5696dd9c080352e25b576acf24450cef255b6eb
# good: [c158564f40f0d2a68833610ac136f9714fc51b16] Merge branch 'staging-next' of https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
git bisect good c158564f40f0d2a68833610ac136f9714fc51b16
# bad: [4240c928a5edeb13fb3953248dfc45e5d9f42f00] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
git bisect bad 4240c928a5edeb13fb3953248dfc45e5d9f42f00
# good: [2e24f5964b72ef213ecdb959a0b0d60b2dc00a3b] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
git bisect good 2e24f5964b72ef213ecdb959a0b0d60b2dc00a3b
# good: [6a350ccc4dc3f46ed2ee2592e3050956e415ef64] pinctrl: add new generic groups/function creation function for pinmux
git bisect good 6a350ccc4dc3f46ed2ee2592e3050956e415ef64
# good: [b12e12ee4138e30d786eda02223e87044c989bb1] gpiolib: Mark gpio_devt, gpiolib_initialized and gpio_stub_drv as __ro_after_init
git bisect good b12e12ee4138e30d786eda02223e87044c989bb1
# good: [446fa334d186316e76cbdc4e94e42af7d040a79c] pinctrl: qcom: Replace open coded eoi call with irq_chip_eoi_parent()
git bisect good 446fa334d186316e76cbdc4e94e42af7d040a79c
# good: [a8754838f83a9905af516f38dd2633744a94f71a] gpio: max77620: Unify usage of space and comma in platform_device_id array
git bisect good a8754838f83a9905af516f38dd2633744a94f71a
# bad: [ef76a3a28c79b628890431aa344af633e892035b] i2c: designware: defer probe if child GpioInt controllers are not bound
git bisect bad ef76a3a28c79b628890431aa344af633e892035b
# good: [b0c13ec17438577f90b379d448dfed1233e2c0a4] pinctrl: mcp23s08: Read spi-present-mask as u8 not u32
git bisect good b0c13ec17438577f90b379d448dfed1233e2c0a4
# good: [3f786abd23951f3f600a62fef42469d9200d5f52] Revert "pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11"
git bisect good 3f786abd23951f3f600a62fef42469d9200d5f52
# first bad commit: [ef76a3a28c79b628890431aa344af633e892035b] i2c: designware: defer probe if child GpioInt controllers are not bound
--
Cheers,
Nathan
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-06-02 18:53 ` Nathan Chancellor
@ 2026-06-02 19:50 ` Hardik Prakash
2026-06-02 22:56 ` Andy Shevchenko
0 siblings, 1 reply; 24+ messages in thread
From: Hardik Prakash @ 2026-06-02 19:50 UTC (permalink / raw)
To: Nathan Chancellor
Cc: linux-i2c, linux-gpio, wsa, andriy.shevchenko, mario.limonciello,
brgl, basavaraj.natikar, linusw, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
On Wed, Jun 03, 2026 at 00:23, Nathan Chancellor wrote:
> I bisected boot issues with a few of my test machines to this change
> in -next as commit ef76a3a28c79. I seem to recall a crash in strcmp()
> in one log but I cannot be too sure.
Thank you for bisecting this.
The strcmp() crash is likely the issue. In
check_gpioint_resource(), we access agpio->resource_source.string_ptr
without checking whether it is NULL first:
if (!strcmp(tmp->path, agpio->resource_source.string_ptr))
ref->path = kstrdup(agpio->resource_source.string_ptr, ...)
The acpi_resource_source struct has a string_length field -- when it is
0, string_ptr will be NULL. On your machines, likely some GPIO resource
apparently has no resource source string, which we did not account for.
I am preparing a fix that skips GPIO resources with no resource source
string (string_length == 0 || string_ptr == NULL). I will test it on
my hardware first and send a patch shortly.
Sorry for the regression.
Thanks,
Hardik
On Wed, 3 Jun 2026 at 00:23, Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi Hardik,
>
> On Fri, May 29, 2026 at 03:38:37PM +0530, Hardik Prakash wrote:
> > 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.
> >
> > The probe ordering race was confirmed via dynamic debug tracing:
> >
> > 0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
> > 0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
> > 0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
> > 2.348157 lost arbitration
> >
> > Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> > Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
> > Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> > Assisted-by: Claude:claude-sonnet-4-6
> > Assisted-by: GPT-Codex:gpt-5.2-codex
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202605240959.Kcf1lIg4-lkp@intel.com/
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
>
> I bisected boot issues with a few of my test machines to this change in -next
> as commit ef76a3a28c79 ("i2c: designware: defer probe if child GpioInt
> controllers are not bound"). I consistently get no display output and I do not
> have serial access to these machines, so I do not have much to go on here at
> the moment. Occasionally, the network controller will be initialized so I can
> remote in but I have not been able to do it recently to try and gather logs.
> What information would be useful for trying to figure out what is going on
> here? I seem to recall a crash in strcmp() in one log but I cannot be too sure
> since it was late at night when I was doing my initial triage.
>
> # bad: [08484c504b55a98bd100527fbe10a3caf55ff3ff] Add linux-next specific files for 20260601
> # good: [e43ffb69e0438cddd72aaa30898b4dc446f664f8] Linux 7.1-rc6
> git bisect start '08484c504b55a98bd100527fbe10a3caf55ff3ff' 'e43ffb69e0438cddd72aaa30898b4dc446f664f8'
> # good: [57fb910db1b6051476b91a4d4ae18bc027a7f36d] Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
> git bisect good 57fb910db1b6051476b91a4d4ae18bc027a7f36d
> # good: [18ea7e3ca91e7a9eb9e43c11154350cec160830b] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox.git
> git bisect good 18ea7e3ca91e7a9eb9e43c11154350cec160830b
> # good: [a5696dd9c080352e25b576acf24450cef255b6eb] Merge branch 'tty-next' of https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
> git bisect good a5696dd9c080352e25b576acf24450cef255b6eb
> # good: [c158564f40f0d2a68833610ac136f9714fc51b16] Merge branch 'staging-next' of https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> git bisect good c158564f40f0d2a68833610ac136f9714fc51b16
> # bad: [4240c928a5edeb13fb3953248dfc45e5d9f42f00] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
> git bisect bad 4240c928a5edeb13fb3953248dfc45e5d9f42f00
> # good: [2e24f5964b72ef213ecdb959a0b0d60b2dc00a3b] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
> git bisect good 2e24f5964b72ef213ecdb959a0b0d60b2dc00a3b
> # good: [6a350ccc4dc3f46ed2ee2592e3050956e415ef64] pinctrl: add new generic groups/function creation function for pinmux
> git bisect good 6a350ccc4dc3f46ed2ee2592e3050956e415ef64
> # good: [b12e12ee4138e30d786eda02223e87044c989bb1] gpiolib: Mark gpio_devt, gpiolib_initialized and gpio_stub_drv as __ro_after_init
> git bisect good b12e12ee4138e30d786eda02223e87044c989bb1
> # good: [446fa334d186316e76cbdc4e94e42af7d040a79c] pinctrl: qcom: Replace open coded eoi call with irq_chip_eoi_parent()
> git bisect good 446fa334d186316e76cbdc4e94e42af7d040a79c
> # good: [a8754838f83a9905af516f38dd2633744a94f71a] gpio: max77620: Unify usage of space and comma in platform_device_id array
> git bisect good a8754838f83a9905af516f38dd2633744a94f71a
> # bad: [ef76a3a28c79b628890431aa344af633e892035b] i2c: designware: defer probe if child GpioInt controllers are not bound
> git bisect bad ef76a3a28c79b628890431aa344af633e892035b
> # good: [b0c13ec17438577f90b379d448dfed1233e2c0a4] pinctrl: mcp23s08: Read spi-present-mask as u8 not u32
> git bisect good b0c13ec17438577f90b379d448dfed1233e2c0a4
> # good: [3f786abd23951f3f600a62fef42469d9200d5f52] Revert "pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11"
> git bisect good 3f786abd23951f3f600a62fef42469d9200d5f52
> # first bad commit: [ef76a3a28c79b628890431aa344af633e892035b] i2c: designware: defer probe if child GpioInt controllers are not bound
>
> --
> Cheers,
> Nathan
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-06-02 19:50 ` Hardik Prakash
@ 2026-06-02 22:56 ` Andy Shevchenko
2026-06-03 7:04 ` Hardik Prakash
0 siblings, 1 reply; 24+ messages in thread
From: Andy Shevchenko @ 2026-06-02 22:56 UTC (permalink / raw)
To: Hardik Prakash
Cc: Nathan Chancellor, linux-i2c, linux-gpio, wsa, mario.limonciello,
brgl, basavaraj.natikar, linusw, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
On Wed, Jun 03, 2026 at 01:20:24AM +0530, Hardik Prakash wrote:
> On Wed, Jun 03, 2026 at 00:23, Nathan Chancellor wrote:
> > I bisected boot issues with a few of my test machines to this change
> > in -next as commit ef76a3a28c79. I seem to recall a crash in strcmp()
> > in one log but I cannot be too sure.
>
> Thank you for bisecting this.
>
> The strcmp() crash is likely the issue. In
> check_gpioint_resource(), we access agpio->resource_source.string_ptr
> without checking whether it is NULL first:
>
> if (!strcmp(tmp->path, agpio->resource_source.string_ptr))
> ref->path = kstrdup(agpio->resource_source.string_ptr, ...)
>
> The acpi_resource_source struct has a string_length field -- when it is
> 0, string_ptr will be NULL. On your machines, likely some GPIO resource
> apparently has no resource source string, which we did not account for.
>
> I am preparing a fix that skips GPIO resources with no resource source
> string (string_length == 0 || string_ptr == NULL). I will test it on
> my hardware first and send a patch shortly.
>
> Sorry for the regression.
Linus, if you applied this patch, please drop it. There are problems with patch
code wise and functional wise. It needs more love and work.
> On Wed, 3 Jun 2026 at 00:23, Nathan Chancellor <nathan@kernel.org> wrote:
> > On Fri, May 29, 2026 at 03:38:37PM +0530, Hardik Prakash wrote:
> > > 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.
> > >
> > > The probe ordering race was confirmed via dynamic debug tracing:
> > >
> > > 0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
> > > 0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
> > > 0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
> > > 2.348157 lost arbitration
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-06-02 22:56 ` Andy Shevchenko
@ 2026-06-03 7:04 ` Hardik Prakash
2026-06-03 7:23 ` Hardik Prakash
0 siblings, 1 reply; 24+ messages in thread
From: Hardik Prakash @ 2026-06-03 7:04 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Nathan Chancellor, linux-i2c, linux-gpio, wsa, mario.limonciello,
brgl, basavaraj.natikar, linusw, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
On Wed, Jun 03, 2026 at 04:26, Andy Shevchenko wrote:
> Linus, if you applied this patch, please drop it. There are problems
> with patch code wise and functional wise. It needs more love and work.
Understood. I agree that the patch should be dropped. The NULL pointer
dereference reported by Nathan and the code issues you've identified
both need to be addressed properly before resubmission.
I will rework the patch addressing all your feedback and the NULL check
for resource_source.string_ptr. I will send a new version once all of the
issues are rectified.
Thanks,
Hardik
On Wed, 3 Jun 2026 at 04:26, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Wed, Jun 03, 2026 at 01:20:24AM +0530, Hardik Prakash wrote:
> > On Wed, Jun 03, 2026 at 00:23, Nathan Chancellor wrote:
> > > I bisected boot issues with a few of my test machines to this change
> > > in -next as commit ef76a3a28c79. I seem to recall a crash in strcmp()
> > > in one log but I cannot be too sure.
> >
> > Thank you for bisecting this.
> >
> > The strcmp() crash is likely the issue. In
> > check_gpioint_resource(), we access agpio->resource_source.string_ptr
> > without checking whether it is NULL first:
> >
> > if (!strcmp(tmp->path, agpio->resource_source.string_ptr))
> > ref->path = kstrdup(agpio->resource_source.string_ptr, ...)
> >
> > The acpi_resource_source struct has a string_length field -- when it is
> > 0, string_ptr will be NULL. On your machines, likely some GPIO resource
> > apparently has no resource source string, which we did not account for.
> >
> > I am preparing a fix that skips GPIO resources with no resource source
> > string (string_length == 0 || string_ptr == NULL). I will test it on
> > my hardware first and send a patch shortly.
> >
> > Sorry for the regression.
>
> Linus, if you applied this patch, please drop it. There are problems with patch
> code wise and functional wise. It needs more love and work.
>
> > On Wed, 3 Jun 2026 at 00:23, Nathan Chancellor <nathan@kernel.org> wrote:
> > > On Fri, May 29, 2026 at 03:38:37PM +0530, Hardik Prakash wrote:
> > > > 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.
> > > >
> > > > The probe ordering race was confirmed via dynamic debug tracing:
> > > >
> > > > 0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
> > > > 0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
> > > > 0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
> > > > 2.348157 lost arbitration
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-06-03 7:04 ` Hardik Prakash
@ 2026-06-03 7:23 ` Hardik Prakash
2026-06-03 7:45 ` Andy Shevchenko
0 siblings, 1 reply; 24+ messages in thread
From: Hardik Prakash @ 2026-06-03 7:23 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Nathan Chancellor, linux-i2c, linux-gpio, wsa, mario.limonciello,
brgl, basavaraj.natikar, linusw, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
On Wed, Jun 03, 2026 at 04:25, Andy Shevchenko wrote:
> Useless data type. You can use list_head directly as a context.
> ...
> Again, a lot of duplication with gpiolib-acpi-core.c. Please, find a
> way how to reuse the code.
1. Remove gpio_dep_ctx, pass struct list_head * directly as void *data
2. const char *path in gpio_controller_ref
3. Use acpi_gpio_get_irq_resource() instead of open-coding the type
checks -- this removes the duplication with gpiolib-acpi-core.c and
also requires changing #ifdef CONFIG_ACPI to
#if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
4. Add NULL check for resource_source.string_ptr
5. Use return value of acpi_dev_get_resources() in check_child_gpioint()
instead of ctx->ret
6. Ensure cleanup of partially filled list on all error paths
7. Remove Reported-by and Closes tags (carried over from a previous patch)
8. Fixes: tag on one line
9. {} instead of { .ret = 0 } for zero initialisation
10. Split adev declaration and assignment
11. Remove unneeded blank line after acpi_dev_put()
12. For "Redundant parentheses" on scoped_guard -- I believe you mean
the bool bound pattern is unnecessary and we should return/goto
directly from inside the guard instead?
Please correct me if I've misunderstood any point.
Thanks,
Hardik
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-06-03 7:23 ` Hardik Prakash
@ 2026-06-03 7:45 ` Andy Shevchenko
0 siblings, 0 replies; 24+ messages in thread
From: Andy Shevchenko @ 2026-06-03 7:45 UTC (permalink / raw)
To: Hardik Prakash
Cc: Nathan Chancellor, linux-i2c, linux-gpio, wsa, mario.limonciello,
brgl, basavaraj.natikar, linusw, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
On Wed, Jun 03, 2026 at 12:53:26PM +0530, Hardik Prakash wrote:
> On Wed, Jun 03, 2026 at 04:25, Andy Shevchenko wrote:
> > Useless data type. You can use list_head directly as a context.
> > ...
> > Again, a lot of duplication with gpiolib-acpi-core.c. Please, find a
> > way how to reuse the code.
>
> 1. Remove gpio_dep_ctx, pass struct list_head * directly as void *data
> 2. const char *path in gpio_controller_ref
> 3. Use acpi_gpio_get_irq_resource() instead of open-coding the type
> checks -- this removes the duplication with gpiolib-acpi-core.c and
> also requires changing #ifdef CONFIG_ACPI to
> #if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
> 4. Add NULL check for resource_source.string_ptr
> 5. Use return value of acpi_dev_get_resources() in check_child_gpioint()
> instead of ctx->ret
> 6. Ensure cleanup of partially filled list on all error paths
> 7. Remove Reported-by and Closes tags (carried over from a previous patch)
> 8. Fixes: tag on one line
> 9. {} instead of { .ret = 0 } for zero initialisation
> 10. Split adev declaration and assignment
> 11. Remove unneeded blank line after acpi_dev_put()
> 12. For "Redundant parentheses" on scoped_guard -- I believe you mean
> the bool bound pattern is unnecessary and we should return/goto
> directly from inside the guard instead?
Nope, the scoped_guard() for a single statement should be written without {}.
scoped_guard(...)
do_something(...);
> Please correct me if I've misunderstood any point.
Otherwise the rest sounds like a good plan.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound
2026-05-29 10:08 ` [PATCH v8 2/2] i2c: designware: defer probe if child GpioInt controllers are not bound Hardik Prakash
` (2 preceding siblings ...)
2026-06-02 18:53 ` Nathan Chancellor
@ 2026-06-02 22:55 ` Andy Shevchenko
3 siblings, 0 replies; 24+ messages in thread
From: Andy Shevchenko @ 2026-06-02 22:55 UTC (permalink / raw)
To: Hardik Prakash
Cc: linux-i2c, linux-gpio, wsa, mario.limonciello, brgl,
basavaraj.natikar, linusw, Bartosz Golaszewski,
Mario Limonciello (AMD), kernel test robot
On Fri, May 29, 2026 at 03:38:37PM +0530, Hardik Prakash wrote:
> 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.
>
> The probe ordering race was confirmed via dynamic debug tracing:
>
> 0.285952 amd_gpio_probe: registering gpiochip <- GPIO chip visible
> 0.287121 amd_gpio_probe: requesting parent IRQ <- probe still running
> 0.301454 AMDI0010:02 dw_i2c_plat_probe: start <- races here
> 2.348157 lost arbitration
>
> Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Assisted-by: Claude:claude-sonnet-4-6
> Assisted-by: GPT-Codex:gpt-5.2-codex
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202605240959.Kcf1lIg4-lkp@intel.com/
These two tags are misused.
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221494
...
> +#ifdef CONFIG_ACPI
> +struct gpio_dep_ctx {
> + struct list_head gpio_controllers;
> + int ret;
> +};
Useless data type. You can use list_head directly as a context. See below.
> +struct gpio_controller_ref {
> + struct list_head node;
> + char *path;
No const?
> +};
> +
> +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;
The idea is not to use the above outside of the (GPIO) core parts.
> + /* 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(sizeof(*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;
This is a duplication with gpiolib-acpi-core.c.
> +}
> +
> +static int check_child_gpioint(struct acpi_device *adev, void *data)
> +{
> + struct gpio_dep_ctx *ctx = data;
> + struct list_head res_list;
> +
> + INIT_LIST_HEAD(&res_list);
> +
> + acpi_dev_get_resources(adev, &res_list, check_gpioint_resource, ctx);
> + acpi_dev_free_resource_list(&res_list);
> + if (ctx->ret < 0)
How do we clear partially filled gpio_controllers list?
> + return ctx->ret;
Huh?! Use returned value from acpi_dev_get_resources().
> + 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 };
Unneeded assignment, {} will suffice.
> + struct gpio_controller_ref *ref, *tmp;
> + int ret = 0;
Split assignment and move it here
adev = ACPI_COMPANION(...);
> + 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;
> + bool bound;
> +
> + status = acpi_get_handle(NULL, ref->path, &handle);
> + if (ACPI_FAILURE(status))
> + continue;
> +
> + gpio_adev = acpi_fetch_acpi_dev(handle);
> + if (!gpio_adev)
> + continue;
Again, a lot of duplication with gpiolib-acpi-core.c. Please, find a way how to
reuse the code.
> + gpio_dev = acpi_get_first_physical_node(gpio_adev);
> + acpi_dev_put(gpio_adev);
> +
Unneeded blank line.
> + 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) {
> + bound = device_is_bound(gpio_dev);
> + }
Redundant parentheses.
> + if (!bound) {
> + put_device(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);
> + }
Yes, this needs to be present on error path above.
> + return ret;
> +}
> +#else
> +static int i2c_dw_check_gpio_dependencies(struct device *dev)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_ACPI */
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 24+ messages in thread