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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

Please, Cc AMD people on the AMD related stuff.
+Cc: Mario

+Cc: Bart
(the GPIO enumeration and checks, smells like it might be done differently).

On Wed, May 13, 2026 at 11:43:38AM +0530, Hardik Prakash wrote:
> On Lenovo Yoga 7 14AGP11 (83TD), the WACF2200 touchscreen fails with
> lost arbitration errors on AMDI0010:02 at boot. The root cause is a
> probe ordering issue: i2c_designware probes AMDI0010:02 before
> pinctrl-amd has finished initialising, so the GPIO 157 interrupt
> needed by the touchscreen is not yet enabled.
> 
> Add a DMI-matched deferral in dw_i2c_plat_probe() that uses
> device_is_bound() under device_lock() to correctly wait until
> pinctrl-amd's probe has fully completed. Use acpi_dev_get_first_match_dev()
> for robust HID/UID-based GPIO controller lookup instead of string
> name matching.

...

> +static bool dw_i2c_needs_amd_gpio_dep(struct device *device)
> +{
> +	struct acpi_device *adev = ACPI_COMPANION(device);

Split hard-to-maintain definition and assignment that's going to be validated.

> +	if (!dmi_check_system(dw_i2c_amd_gpio_defer_dmi))
> +		return false;
> +	if (!adev)
> +		return false;

	struct acpi_device *adev;

	if (!dmi_check_system(dw_i2c_amd_gpio_defer_dmi))
		return false;

	adev = ACPI_COMPANION(device);
	if (!adev)
		return false;

> +	return acpi_dev_hid_uid_match(adev, "AMDI0010", "2");
> +}

...

> +static int dw_i2c_defer_for_amd_gpio(struct device *device)
> +{
> +	struct acpi_device *gpio_adev;
> +	struct device *gpio_dev;
> +
> +	if (!dw_i2c_needs_amd_gpio_dep(device))
> +		return 0;
> +
> +	/*
> +	 * Find the AMD GPIO controller by HID/UID and get its physical
> +	 * platform device. We need the platform device (not the ACPI device)
> +	 * because that is what gets bound by the amd_gpio driver.
> +	 */
> +	gpio_adev = acpi_dev_get_first_match_dev("AMDI0030", "0", -1);
> +	if (!gpio_adev)
> +		return -EPROBE_DEFER;

Hmm... This is interesting case, smells like something similar to what we had
with x86 Android quirk driver. Cc'ed to Bart to briefly look at this.

> +	gpio_dev = acpi_get_first_physical_node(gpio_adev);
> +	acpi_dev_put(gpio_adev);
> +	if (!gpio_dev)
> +		return -EPROBE_DEFER;
> +
> +	/*
> +	 * Check that amd_gpio probe has fully completed, not just that the
> +	 * driver pointer is set. The driver pointer is assigned before probe
> +	 * finishes, so checking it would allow i2c_designware to probe before
> +	 * the GPIO IRQ quirk in amd_gpio_probe() has run.
> +	 */
> +	device_lock(gpio_dev);
> +	if (!device_is_bound(gpio_dev)) {
> +		device_unlock(gpio_dev);
> +		return -EPROBE_DEFER;
> +	}
> +	device_unlock(gpio_dev);
> +
> +	/*
> +	 * Create a device link so the driver core enforces probe/remove
> +	 * ordering between this I2C controller and the GPIO controller.
> +	 */
> +	if (!device_link_add(device, gpio_dev, DL_FLAG_AUTOREMOVE_CONSUMER))
> +		dev_warn(device, "failed to add device link to %s\n",
> +			 dev_name(gpio_dev));
> +
> +	return 0;
> +}

-- 
With Best Regards,
Andy Shevchenko