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. OTOH, for the first case we can actually run SW debounce. But it might be quite an intrusive change to call it "a fix".
So, taking the above into account I suggest that the helper should return int and check the info.gpioint flag and in case of being set, return an error, otherwise ignore wrong settings. Or something like this. In such a case we may also use it in the acpi_dev_gpio_irq_wake_get_by().
https://lore.kernel.org/linux-gpio/20250811164356.613840-1-superm1@kernel.or... [1]