[PATCH 0/2] Fix WACF2200 touchscreen on Lenovo Yoga 7 14AGP11

[PATCH 0/2] Fix WACF2200 touchscreen on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

The Wacom WACF2200 touchscreen on the Lenovo Yoga 7 14AGP11 (83TD) is
completely non-functional on Linux. The I2C bus (AMDI0010:02) fails with
repeated lost arbitration errors at boot before any driver can probe the
device. The touchscreen works correctly in UEFI and Windows.

Investigation using ACPI _CRS decode and Windows/Linux GPIO register
comparison identified two bugs:

1. GPIO 157 (WACF2200 GpioInt per ACPI _CRS) has INTERRUPT_ENABLE and
   INTERRUPT_MASK cleared by amd_gpio_irq_init() and never restored,
   preventing the device from signalling the driver. Windows keeps both
   bits set after initialisation.

2. i2c_designware probes AMDI0010:02 before pinctrl-amd's probe
   completes. The existing dw_i2c_amd_gpio_defer_dmi quirk for this
   hardware checks gpio_dev->driver which is set before probe finishes,
   so the deferral does not actually enforce ordering.

Patch 1 adds a DMI quirk in pinctrl-amd to restore GPIO 157 interrupt
bits after amd_gpio_irq_init().

Patch 2 fixes the existing broken deferral in i2c-designware-platdrv to
use device_is_bound() under device_lock(), which correctly waits for
pinctrl-amd probe to complete before AMDI0010:02 is probed.

Both patches tested on Lenovo Yoga 7 14AGP11 (83TD), Fedora 44, kernel
7.1.0-rc2+. Touch and stylus fully functional after applying both patches.

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

Hardik Prakash (2):
  pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7
    14AGP11
  i2c: designware: fix probe ordering for AMD GPIO on Lenovo Yoga 7
    14AGP11

 drivers/i2c/busses/i2c-designware-platdrv.c | 81 +++++++++++++++++++++
 drivers/pinctrl/pinctrl-amd.c               | 35 +++++++++
 2 files changed, 116 insertions(+)

-- 
2.54.0

[PATCH 1/2] pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11

[Hardik Prakash]

On Lenovo Yoga 7 14AGP11 (83TD), the WACF2200 touchscreen controller
is wired via I2C2 (AMDI0010:02) with its interrupt on GPIO pin 157
(confirmed via ACPI _CRS GpioInt decode). After amd_gpio_irq_init()
clears all GPIO interrupts at boot, pin 157 is never re-enabled,
preventing the touchscreen from signalling the driver.

Windows keeps GPIO 157 INTERRUPT_ENABLE (bit 11) and INTERRUPT_MASK
(bit 12) set after initialisation. Add a DMI quirk to restore these
bits after amd_gpio_irq_init() on this hardware.

Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
---
 drivers/pinctrl/pinctrl-amd.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index e3128b0045d22..64315b0edf2a6 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -26,6 +26,7 @@
 #include <linux/interrupt.h>
 #include <linux/bitops.h>
 #include <linux/pinctrl/pinconf.h>
+#include <linux/dmi.h>
 #include <linux/pinctrl/pinconf-generic.h>
 #include <linux/pinctrl/pinmux.h>
 #include <linux/string_choices.h>
@@ -39,6 +40,39 @@
 static struct amd_gpio *pinctrl_dev;
 #endif
 
+static const struct dmi_system_id amd_gpio_quirk_yoga7_14agp11[] = {
+	{
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "83TD"),
+			DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216"),
+		},
+	},
+	{ }
+};
+
+static void amd_gpio_apply_quirks(struct amd_gpio *gpio_dev)
+{
+	const unsigned int pin = 157; /* WACF2200 GpioInt per ACPI _CRS */
+	unsigned long flags;
+	u32 reg;
+
+	if (!dmi_check_system(amd_gpio_quirk_yoga7_14agp11))
+		return;
+	if (pin >= gpio_dev->gc.ngpio)
+		return;
+
+	raw_spin_lock_irqsave(&gpio_dev->lock, flags);
+	reg = readl(gpio_dev->base + pin * 4);
+	reg |= BIT(INTERRUPT_ENABLE_OFF) | BIT(INTERRUPT_MASK_OFF);
+	writel(reg, gpio_dev->base + pin * 4);
+	raw_spin_unlock_irqrestore(&gpio_dev->lock, flags);
+
+	dev_info(&gpio_dev->pdev->dev,
+		 "Enabled IRQ for GPIO %u (Yoga 7 14AGP11 touchscreen)\n",
+		 pin);
+}
+
 static int amd_gpio_get_direction(struct gpio_chip *gc, unsigned offset)
 {
 	unsigned long flags;
@@ -1219,6 +1253,7 @@ static int amd_gpio_probe(struct platform_device *pdev)
 
 	/* Disable and mask interrupts */
 	amd_gpio_irq_init(gpio_dev);
+	amd_gpio_apply_quirks(gpio_dev);
 
 	girq = &gpio_dev->gc.irq;
 	gpio_irq_chip_set_chip(girq, &amd_gpio_irqchip);
-- 
2.54.0

Re: [PATCH 1/2] pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11

[Linus Walleij]

On Tue, May 12, 2026 at 9:32 AM Hardik Prakash
<hardikprakash.official@gmail.com> wrote:

> On Lenovo Yoga 7 14AGP11 (83TD), the WACF2200 touchscreen controller
> is wired via I2C2 (AMDI0010:02) with its interrupt on GPIO pin 157
> (confirmed via ACPI _CRS GpioInt decode). After amd_gpio_irq_init()
> clears all GPIO interrupts at boot, pin 157 is never re-enabled,
> preventing the touchscreen from signalling the driver.
>
> Windows keeps GPIO 157 INTERRUPT_ENABLE (bit 11) and INTERRUPT_MASK
> (bit 12) set after initialisation. Add a DMI quirk to restore these
> bits after amd_gpio_irq_init() on this hardware.
>
> Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>

I don't understand DMI quirks.

Andy, Rafael or Mika has to ACK this if I should merge it, otherwise it
looks superficially good.

Yours,
Linus Walleij

Re: [PATCH 1/2] pinctrl-amd: enable IRQ for WACF2200 touchscreen on Lenovo Yoga 7 14AGP11

[Andy Shevchenko]

On Tue, May 12, 2026 at 01:01:38PM +0530, Hardik Prakash wrote:
> On Lenovo Yoga 7 14AGP11 (83TD), the WACF2200 touchscreen controller
> is wired via I2C2 (AMDI0010:02) with its interrupt on GPIO pin 157
> (confirmed via ACPI _CRS GpioInt decode). After amd_gpio_irq_init()
> clears all GPIO interrupts at boot, pin 157 is never re-enabled,
> preventing the touchscreen from signalling the driver.
> 
> Windows keeps GPIO 157 INTERRUPT_ENABLE (bit 11) and INTERRUPT_MASK
> (bit 12) set after initialisation. Add a DMI quirk to restore these
> bits after amd_gpio_irq_init() on this hardware.

Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>

...

>  	/* Disable and mask interrupts */
>  	amd_gpio_irq_init(gpio_dev);

Ideally this should be done as a GPIO driver callback (we have something
like .init_hw() IIRC). But since it's an original code, it may be an exercise
for another day.

> +	amd_gpio_apply_quirks(gpio_dev);


-- 
With Best Regards,
Andy Shevchenko

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

[Hardik Prakash]

The existing dw_i2c_amd_gpio_defer_dmi quirk for Lenovo 83TD checks
gpio_dev->driver to determine if the GPIO controller is ready, but
this pointer is set before pinctrl-amd's probe completes, causing
i2c_designware to probe AMDI0010:02 before the GPIO IRQ quirk runs.

Switch to device_is_bound() under device_lock() to correctly defer
until GPIO probe has fully completed. Also replace the string-based
device lookup with ACPI HID/UID matching for robustness, and add
DMI_BOARD_NAME to the DMI match to reduce false positives.

Fixes: the lost arbitration on AMDI0010:02 at boot on Lenovo 83TD.

Signed-off-by: Hardik Prakash <hardikprakash.official@gmail.com>
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 81 +++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 3351c4a9ef118..ccf4433a1d4fa 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -8,6 +8,7 @@
  * Copyright (C) 2007 MontaVista Software Inc.
  * Copyright (C) 2009 Provigent Ltd.
  */
+#include <linux/acpi.h>
 #include <linux/clk-provider.h>
 #include <linux/clk.h>
 #include <linux/delay.h>
@@ -86,6 +87,82 @@ static const struct dmi_system_id dw_i2c_hwmon_class_dmi[] = {
 	{ } /* terminate list */
 };
 
+static const struct dmi_system_id dw_i2c_amd_gpio_defer_dmi[] = {
+	{
+		.ident = "Lenovo Yoga 7 14AGP11",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "83TD"),
+			DMI_MATCH(DMI_BOARD_NAME, "LNVNB161216"),
+		},
+	},
+	{ } /* terminate list */
+};
+
+struct dw_i2c_hid_uid {
+	const char *hid;
+	u64 uid;
+};
+
+static int dw_i2c_match_hid_uid(struct device *dev, const void *data)
+{
+	struct acpi_device *adev = ACPI_COMPANION(dev);
+	const struct dw_i2c_hid_uid *id = data;
+
+	if (!adev)
+		return 0;
+
+	return acpi_dev_hid_uid_match(adev, id->hid, id->uid);
+}
+
+static struct device *dw_i2c_find_platform_hid_uid(const char *hid, u64 uid)
+{
+	struct dw_i2c_hid_uid data = {
+		.hid = hid,
+		.uid = uid,
+	};
+
+	return bus_find_device(&platform_bus_type, NULL, &data, dw_i2c_match_hid_uid);
+}
+
+static bool dw_i2c_needs_amd_gpio_dep(struct device *device)
+{
+	struct acpi_device *adev = ACPI_COMPANION(device);
+
+	if (!dmi_check_system(dw_i2c_amd_gpio_defer_dmi))
+		return false;
+	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 device *gpio_dev;
+
+	if (!dw_i2c_needs_amd_gpio_dep(device))
+		return 0;
+
+	gpio_dev = dw_i2c_find_platform_hid_uid("AMDI0030", 0);
+	if (!gpio_dev)
+		return -EPROBE_DEFER;
+
+	device_lock(gpio_dev);
+	if (!device_is_bound(gpio_dev)) {
+		device_unlock(gpio_dev);
+		put_device(gpio_dev);
+		return -EPROBE_DEFER;
+	}
+	device_unlock(gpio_dev);
+
+	if (!device_link_add(device, gpio_dev, DL_FLAG_AUTOREMOVE_CONSUMER))
+		dev_warn(device, "failed to add device link to AMDI0030:00\n");
+
+	put_device(gpio_dev);
+	return 0;
+}
+
 static const struct i2c_dw_semaphore_callbacks i2c_dw_semaphore_cb_table[] = {
 #ifdef CONFIG_I2C_DESIGNWARE_BAYTRAIL
 	{
@@ -138,6 +215,10 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
 	struct dw_i2c_dev *dev;
 	int irq, ret;
 
+	ret = dw_i2c_defer_for_amd_gpio(device);
+	if (ret)
+		return ret;
+
 	irq = platform_get_irq_optional(pdev, 0);
 	if (irq == -ENXIO)
 		flags |= ACCESS_POLLING;
-- 
2.54.0

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

[Andy Shevchenko]

On Tue, May 12, 2026 at 01:01:39PM +0530, Hardik Prakash wrote:
> The existing dw_i2c_amd_gpio_defer_dmi quirk for Lenovo 83TD checks

Existing? Is this message and the whole stuff is somehow AI-assisted?

> gpio_dev->driver to determine if the GPIO controller is ready, but
> this pointer is set before pinctrl-amd's probe completes, causing
> i2c_designware to probe AMDI0010:02 before the GPIO IRQ quirk runs.
> 
> Switch to device_is_bound() under device_lock() to correctly defer
> until GPIO probe has fully completed. Also replace the string-based
> device lookup with ACPI HID/UID matching for robustness, and add
> DMI_BOARD_NAME to the DMI match to reduce false positives.

> Fixes: the lost arbitration on AMDI0010:02 at boot on Lenovo 83TD.

This is incorrect way of providing a Fixes tag.

...

> +struct dw_i2c_hid_uid {
> +	const char *hid;
> +	u64 uid;
> +};

Useless as duplicates the existing strictures. See also below.

...

> +static int dw_i2c_match_hid_uid(struct device *dev, const void *data)
> +{
> +	struct acpi_device *adev = ACPI_COMPANION(dev);
> +	const struct dw_i2c_hid_uid *id = data;
> +
> +	if (!adev)
> +		return 0;
> +
> +	return acpi_dev_hid_uid_match(adev, id->hid, id->uid);
> +}
> +
> +static struct device *dw_i2c_find_platform_hid_uid(const char *hid, u64 uid)
> +{
> +	struct dw_i2c_hid_uid data = {
> +		.hid = hid,
> +		.uid = uid,
> +	};
> +
> +	return bus_find_device(&platform_bus_type, NULL, &data, dw_i2c_match_hid_uid);
> +}
> +
> +static bool dw_i2c_needs_amd_gpio_dep(struct device *device)
> +{
> +	struct acpi_device *adev = ACPI_COMPANION(device);
> +
> +	if (!dmi_check_system(dw_i2c_amd_gpio_defer_dmi))
> +		return false;
> +	if (!adev)
> +		return false;
> +
> +	return acpi_dev_hid_uid_match(adev, "AMDI0010", 2);
> +}

The whole flow is just a repetition of acpi_dev_get_first_match_dev().

...

> +static int dw_i2c_defer_for_amd_gpio(struct device *device)
> +{
> +	struct device *gpio_dev;
> +
> +	if (!dw_i2c_needs_amd_gpio_dep(device))
> +		return 0;
> +
> +	gpio_dev = dw_i2c_find_platform_hid_uid("AMDI0030", 0);
> +	if (!gpio_dev)
> +		return -EPROBE_DEFER;
> +
> +	device_lock(gpio_dev);
> +	if (!device_is_bound(gpio_dev)) {
> +		device_unlock(gpio_dev);
> +		put_device(gpio_dev);
> +		return -EPROBE_DEFER;
> +	}
> +	device_unlock(gpio_dev);

Interesting dance. Needs a comment explaining what's going on here and why this
deferral probe won't be a problem in other scenarios.

> +	if (!device_link_add(device, gpio_dev, DL_FLAG_AUTOREMOVE_CONSUMER))

This needs a good comment explaining what's going on.

> +		dev_warn(device, "failed to add device link to AMDI0030:00\n");

Why :00? Is it guaranteed that this is going to be with :00? Note, this suffix
is instance number in Linux and strictly speaking might differ even from boot
to boot on the same machine.

> +	put_device(gpio_dev);
> +	return 0;
> +}

-- 
With Best Regards,
Andy Shevchenko

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

[Hardik Prakash]

Thanks for taking the time to review, Andy.

To answer your question directly: yes, this patch series was indeed
written with significant AI assistance (Claude, GPT-Codex). I used it
to navigate ACPI analysis, interpret GPIO register diffs, and draft
code I don't yet have the kernel experience to write from scratch. I
performed the investigation, testing, and hardware debugging, but I
want to be transparent about the process.

On the technical points:

1. "Existing?": My bad, the commit message is indeed wrong. The
dw_i2c_amd_gpio_defer_dmi table and dw_i2c_add_amd_gpio_link function
are added by patch 2 and do not pre-exist. I'll fix the commit message
in v2.
2. Fixes tag: Noted. I will use the correct format with a commit hash in v2.
3. dw_i2c_hid_uid struct duplicating existing structures: I will take
a look at acpi_dev_get_first_match_dev() and simplify accordingly.
4. device_lock deferral probe: I will add one explaining the race
between driver pointer set and probe completion.
5. device_link_add comment: will add.
6. ":00" suffix hardcoded in the warning: Understood. Will correct this.

I'll send a v2 addressing all of these. Is there anything else you'd
like addressed before I do?

Hardik


On Tue, 12 May 2026 at 16:37, Hardik Prakash
<hardikprakash.official@gmail.com> wrote:
>
> Thanks for taking the time to review, Andy.
>
> To answer your question directly: yes, this patch series was indeed written with significant AI assistance (Claude, GPT-Codex). I used it to navigate ACPI analysis, interpret GPIO register diffs, and draft code I don't yet have the kernel experience to write from scratch. I performed the investigation, testing, and hardware debugging, but I want to be transparent about the process.
>
> On the technical points:
>
> "Existing?": My bad, the commit message is indeed wrong. The dw_i2c_amd_gpio_defer_dmi table and dw_i2c_add_amd_gpio_link function are added by patch 2 and do not pre-exist. I'll fix the commit message in v2.
> Fixes tag: Noted. I will use the correct format with a commit hash in v2.
> dw_i2c_hid_uid struct duplicating existing structures: I will take a look at acpi_dev_get_first_match_dev() and simplify accordingly.
> device_lock deferral probe: I will add one explaining the race between driver pointer set and probe completion.
> device_link_add comment: will add.
> ":00" suffix hardcoded in the warning: Understood. Will correct this.
>
> I'll send a v2 addressing all of these. Is there anything else you'd like addressed before I do?
>
> Hardik
>
>
>
> On Tue, 12 May 2026 at 16:25, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>>
>> On Tue, May 12, 2026 at 01:01:39PM +0530, Hardik Prakash wrote:
>> > The existing dw_i2c_amd_gpio_defer_dmi quirk for Lenovo 83TD checks
>>
>> Existing? Is this message and the whole stuff is somehow AI-assisted?
>>
>> > gpio_dev->driver to determine if the GPIO controller is ready, but
>> > this pointer is set before pinctrl-amd's probe completes, causing
>> > i2c_designware to probe AMDI0010:02 before the GPIO IRQ quirk runs.
>> >
>> > Switch to device_is_bound() under device_lock() to correctly defer
>> > until GPIO probe has fully completed. Also replace the string-based
>> > device lookup with ACPI HID/UID matching for robustness, and add
>> > DMI_BOARD_NAME to the DMI match to reduce false positives.
>>
>> > Fixes: the lost arbitration on AMDI0010:02 at boot on Lenovo 83TD.
>>
>> This is incorrect way of providing a Fixes tag.
>>
>> ...
>>
>> > +struct dw_i2c_hid_uid {
>> > +     const char *hid;
>> > +     u64 uid;
>> > +};
>>
>> Useless as duplicates the existing strictures. See also below.
>>
>> ...
>>
>> > +static int dw_i2c_match_hid_uid(struct device *dev, const void *data)
>> > +{
>> > +     struct acpi_device *adev = ACPI_COMPANION(dev);
>> > +     const struct dw_i2c_hid_uid *id = data;
>> > +
>> > +     if (!adev)
>> > +             return 0;
>> > +
>> > +     return acpi_dev_hid_uid_match(adev, id->hid, id->uid);
>> > +}
>> > +
>> > +static struct device *dw_i2c_find_platform_hid_uid(const char *hid, u64 uid)
>> > +{
>> > +     struct dw_i2c_hid_uid data = {
>> > +             .hid = hid,
>> > +             .uid = uid,
>> > +     };
>> > +
>> > +     return bus_find_device(&platform_bus_type, NULL, &data, dw_i2c_match_hid_uid);
>> > +}
>> > +
>> > +static bool dw_i2c_needs_amd_gpio_dep(struct device *device)
>> > +{
>> > +     struct acpi_device *adev = ACPI_COMPANION(device);
>> > +
>> > +     if (!dmi_check_system(dw_i2c_amd_gpio_defer_dmi))
>> > +             return false;
>> > +     if (!adev)
>> > +             return false;
>> > +
>> > +     return acpi_dev_hid_uid_match(adev, "AMDI0010", 2);
>> > +}
>>
>> The whole flow is just a repetition of acpi_dev_get_first_match_dev().
>>
>> ...
>>
>> > +static int dw_i2c_defer_for_amd_gpio(struct device *device)
>> > +{
>> > +     struct device *gpio_dev;
>> > +
>> > +     if (!dw_i2c_needs_amd_gpio_dep(device))
>> > +             return 0;
>> > +
>> > +     gpio_dev = dw_i2c_find_platform_hid_uid("AMDI0030", 0);
>> > +     if (!gpio_dev)
>> > +             return -EPROBE_DEFER;
>> > +
>> > +     device_lock(gpio_dev);
>> > +     if (!device_is_bound(gpio_dev)) {
>> > +             device_unlock(gpio_dev);
>> > +             put_device(gpio_dev);
>> > +             return -EPROBE_DEFER;
>> > +     }
>> > +     device_unlock(gpio_dev);
>>
>> Interesting dance. Needs a comment explaining what's going on here and why this
>> deferral probe won't be a problem in other scenarios.
>>
>> > +     if (!device_link_add(device, gpio_dev, DL_FLAG_AUTOREMOVE_CONSUMER))
>>
>> This needs a good comment explaining what's going on.
>>
>> > +             dev_warn(device, "failed to add device link to AMDI0030:00\n");
>>
>> Why :00? Is it guaranteed that this is going to be with :00? Note, this suffix
>> is instance number in Linux and strictly speaking might differ even from boot
>> to boot on the same machine.
>>
>> > +     put_device(gpio_dev);
>> > +     return 0;
>> > +}
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
>>
>>

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

[Andy Shevchenko]

On Tue, May 12, 2026 at 04:37:58PM +0530, Hardik Prakash wrote:

First of all, please do not top-post!

> Thanks for taking the time to review, Andy.
> 
> To answer your question directly: yes, this patch series was indeed written
> with significant AI assistance (Claude, GPT-Codex). I used it to navigate
> ACPI analysis, interpret GPIO register diffs, and draft code I don't yet
> have the kernel experience to write from scratch. I performed the
> investigation, testing, and hardware debugging, but I want to be
> transparent about the process.

So, please study the kernel documentation about AI assistance.
This has to be clearly mentioned in the commit message (we have special
tag nowadays, Assisted-by: IIRC).

> On the technical points:
> 
>    1. "Existing?": My bad, the commit message is indeed wrong. The
>    dw_i2c_amd_gpio_defer_dmi table and dw_i2c_add_amd_gpio_link function are
>    added by patch 2 and do not pre-exist. I'll fix the commit message in v2.
>    2. Fixes tag: Noted. I will use the correct format with a commit hash in
>    v2.
>    3. dw_i2c_hid_uid struct duplicating existing structures: I will take a
>    look at acpi_dev_get_first_match_dev() and simplify accordingly.
>    4. device_lock deferral probe: I will add one explaining the race
>    between driver pointer set and probe completion.
>    5. device_link_add comment: will add.
>    6. ":00" suffix hardcoded in the warning: Understood. Will correct this.
> 
> I'll send a v2 addressing all of these. Is there anything else you'd like
> addressed before I do?

Two things that I mentioned above. The rest will see when there is the v2
appears.

-- 
With Best Regards,
Andy Shevchenko