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