[PATCH] Input: goodix - Workaround Cherry Trail devices with a bogus ACPI Interrupt() resource

[PATCH] Input: goodix - Workaround Cherry Trail devices with a bogus ACPI Interrupt() resource

[Hans de Goede]

ACPI/x86 devices with a Cherry Trail SoC should have a GpioInt + a regular
GPIO ACPI resource in their ACPI tables.

Some CHT devices have a bug, where the also is bogus Interrupt resource
(likely copied from a previous Bay Trail based generation of the device).

The i2c-core-acpi code will assign the bogus, non-working, Interrupt
resource to client->irq. Add a workaround to fix this up.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2043960
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Note this depends on "[PATCH v2 5/5] Input: goodix - Use the new
soc_intel_is_byt() helper" from this series:
https://lore.kernel.org/linux-input/20220131143539.109142-1-hdegoede@redhat.com/
---
 drivers/input/touchscreen/goodix.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index dac19a790c35..3ad9870db108 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -854,7 +854,7 @@ static int goodix_add_acpi_gpio_mappings(struct goodix_ts_data *ts)
 	const struct acpi_gpio_mapping *gpio_mapping = NULL;
 	struct device *dev = &ts->client->dev;
 	LIST_HEAD(resources);
-	int ret;
+	int irq, ret;
 
 	ts->gpio_count = 0;
 	ts->gpio_int_idx = -1;
@@ -867,6 +867,20 @@ static int goodix_add_acpi_gpio_mappings(struct goodix_ts_data *ts)
 
 	acpi_dev_free_resource_list(&resources);
 
+	/*
+	 * CHT devices should have a GpioInt + a regular GPIO ACPI resource.
+	 * Some CHT devices have a bug (where the also is bogus Interrupt
+	 * resource copied from a previous BYT based generation). i2c-core-acpi
+	 * will use the non-working Interrupt resource, fix this up.
+	 */
+	if (soc_intel_is_cht() && ts->gpio_count == 2 && ts->gpio_int_idx != -1) {
+		irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
+		if (irq > 0 && irq != ts->client->irq) {
+			dev_warn(dev, "Overriding IRQ %d -> %d\n", ts->client->irq, irq);
+			ts->client->irq = irq;
+		}
+	}
+
 	if (ts->gpio_count == 2 && ts->gpio_int_idx == 0) {
 		ts->irq_pin_access_method = IRQ_PIN_ACCESS_ACPI_GPIO;
 		gpio_mapping = acpi_goodix_int_first_gpios;
-- 
2.35.1

Re: [PATCH] Input: goodix - Workaround Cherry Trail devices with a bogus ACPI Interrupt() resource

[Dmitry Torokhov]

On Mon, Feb 28, 2022 at 12:16:13PM +0100, Hans de Goede wrote:
> ACPI/x86 devices with a Cherry Trail SoC should have a GpioInt + a regular
> GPIO ACPI resource in their ACPI tables.
> 
> Some CHT devices have a bug, where the also is bogus Interrupt resource
> (likely copied from a previous Bay Trail based generation of the device).
> 
> The i2c-core-acpi code will assign the bogus, non-working, Interrupt
> resource to client->irq. Add a workaround to fix this up.
> 
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2043960
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Applied (for 5.17), thank you.

-- 
Dmitry

Re: [PATCH] Input: goodix - Workaround Cherry Trail devices with a bogus ACPI Interrupt() resource

[Hans de Goede]

Hi Dmitry,

On 3/1/22 08:04, Dmitry Torokhov wrote:
> On Mon, Feb 28, 2022 at 12:16:13PM +0100, Hans de Goede wrote:
>> ACPI/x86 devices with a Cherry Trail SoC should have a GpioInt + a regular
>> GPIO ACPI resource in their ACPI tables.
>>
>> Some CHT devices have a bug, where the also is bogus Interrupt resource
>> (likely copied from a previous Bay Trail based generation of the device).
>>
>> The i2c-core-acpi code will assign the bogus, non-working, Interrupt
>> resource to client->irq. Add a workaround to fix this up.
>>
>> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2043960
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> Applied (for 5.17), thank you.

Thank you!

Unrelated question (now that I have your attention) may I have your
Acked-by for merging the (small) drivers/input/misc/soc_button_array.c
of this series:

https://lore.kernel.org/linux-input/20220224110241.9613-1-hdegoede@redhat.com/

see:

https://lore.kernel.org/linux-input/20220224110241.9613-2-hdegoede@redhat.com/

Through the drivers/platform/x86 tree ?

(so that we can keep the series together) 

Regards,

Hans