| 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) ?
Hi, On 28-Nov-24 4:52 PM, Andy Shevchenko wrote: > 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) ? I'm not sure there is much value in keeping this. If we do go for dev_dbg() then the check should be changed to: if (pin != (agpio->pin_table[0] % 256)) to avoid false positives and the need for that IMHO already shows that there is little use in keeping the check. But lowering it to dev_dbg() + adding the % 256 also works for me, please let me know how you want to proceed. Regards, Hans
On Wed, Dec 4, 2024 at 7:36 PM Hans de Goede <hdegoede@redhat.com> wrote: > On 28-Nov-24 4:52 PM, Andy Shevchenko wrote: > > On Thu, Nov 28, 2024 at 04:42:10PM +0100, Hans de Goede wrote: ... > >> - 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) ? > > I'm not sure there is much value in keeping this. If we do go for dev_dbg() > then the check should be changed to: > > if (pin != (agpio->pin_table[0] % 256)) > > to avoid false positives and the need for that IMHO already shows that > there is little use in keeping the check. > > But lowering it to dev_dbg() + adding the % 256 also works for me, > please let me know how you want to proceed. I think dev_dbg() might still make (a little, though) sense. But also add a FW_BUG prefix to the message.
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(-)