Message ID | 20241128154212.6216-2-hdegoede@redhat.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [1/4] platform/x86: int3472: Check for adev == NULL | expand |
On Thu, Nov 28, 2024 at 04:42:10PM +0100, Hans de Goede wrote: > 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. > > Drop the warning about these mismatches since Windows clearly is just > ignoring the _DSM pin-number so invalid values are too be expected there. ... > - 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]); > - Hmm... Perhaps move it to dev_dbg(FW_BUG) ?
diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c index 15678508ee50..01da18b426ae 100644 --- a/drivers/platform/x86/intel/int3472/discrete.c +++ b/drivers/platform/x86/intel/int3472/discrete.c @@ -189,9 +189,9 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares, { struct int3472_discrete_device *int3472 = data; struct acpi_resource_gpio *agpio; - u8 active_value, pin, type; union acpi_object *obj; struct gpio_desc *gpio; + u8 active_value, type; const char *err_msg; const char *func; u32 polarity; @@ -219,12 +219,6 @@ 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]); - active_value = FIELD_GET(INT3472_GPIO_DSM_SENSOR_ON_VAL, obj->integer.value); if (!active_value) polarity ^= GPIO_ACTIVE_LOW;
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. Drop the warning about these mismatches since Windows clearly is just ignoring the _DSM pin-number so invalid values are too be expected there. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/platform/x86/intel/int3472/discrete.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)