@@ -220,10 +220,10 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
int3472_get_func_and_polarity(type, &func, &polarity);
pin = FIELD_GET(INT3472_GPIO_DSM_PIN, obj->integer.value);
- if (pin != agpio->pin_table[0])
- dev_warn(int3472->dev, "%s %s pin number mismatch _DSM %d resource %d\n",
- func, agpio->resource_source.string_ptr, pin,
- agpio->pin_table[0]);
+ /* Pin field is not really used under Windows and wraps around at 8 bits */
+ if (pin != (agpio->pin_table[0] & 0xff))
+ dev_dbg(int3472->dev, FW_BUG "%s %s pin number mismatch _DSM %d resource %d\n",
+ func, agpio->resource_source.string_ptr, pin, agpio->pin_table[0]);
active_value = FIELD_GET(INT3472_GPIO_DSM_SENSOR_ON_VAL, obj->integer.value);
if (!active_value)
It seems that Windows is only using the ACPI GPIO resources and never looks at the part of the _DSM return value which encodes the pin number. For example on a Terra Pad 1262 v2 the following messages are printend: int3472-discrete INT3472:01: reset \_SB.GPI0 pin number mismatch _DSM 103 resource 359 int3472-discrete INT3472:01: powerdown \_SB.GPI0 pin number mismatch _DSM 207 resource 335 int3472-discrete INT3472:02: reset \_SB.GPI0 pin number mismatch _DSM 101 resource 357 Notice for the 2 reset pins that the _DSM value is off by 256, this is caused by there only being 8 bits reserved in the _DSM return value for the pin-number. As for the powerdown pin, testing has shown that the pin-number 335 from the ACPI GPIO resource is correct and the _DSM value is bogus. Lower the warning about these mismatches to a debug message and only look at the lower 8 bits of the GPIO resource pin numbers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- Changes in v2: - Lower message to debug level instead of dropping it --- drivers/platform/x86/intel/int3472/discrete.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)