On Sun, Sep 21, 2025 at 11:11 PM Hans de Goede hansg@kernel.org wrote:
On 21-Sep-25 9:03 PM, Andy Shevchenko wrote:
On Sun, Sep 21, 2025 at 9:09 PM Mario Limonciello (AMD) (kernel.org) superm1@kernel.org wrote:
On 9/20/2025 3:12 PM, Hans de Goede wrote:
...
Looks pretty much identical now to what I sent in my v3 and that Andy had requested we change to make it fatal [1].
Where is this bad GPIO value coming from? It's in the GpioInt() declaration? If so, should the driver actually be supporting this?
Since it's in acpi_find_gpio() it's about any GPIO resource type. Sorry, it seems I missed this fact. I was under the impression that v4 was done only for the GpioInt() case. With this being said, the GpioIo() should not be fatal (it's already proven by cases in the wild that sometimes given values there are unsupported by HW), but GpioInt() in my opinion needs a justification to become non-fatal.
GpioInt() debounce setting not succeeding already is non fatal in the acpi_request_own_gpiod() case, which is used for ACPI events (_AEI resources) and that exact use-case is why it was made non-fatal, so no this is not only about GpioIo() resources. See commit cef0d022f553 ("gpiolib: acpi: Make set-debounce-timeout failures non fatal")
IOW we need set debounce failures to be non-fatal for both the GpioIo and GpioInt cases and this fix is correct as is.
Okay, since it doesn't change the state of affairs with for acpi_dev_gpio_irq_wake_get_by(), it's fair enough to get it as is. Mario, do you agree with Hans' explanations?
It is very likely too late to fix this *regression* for 6.17.0, please queue this up for merging ASAP so that we can get a fix added to 6.17.1