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
