On Mon, Aug 11, 2025 at 11:43:56AM -0500, Mario Limonciello (AMD) wrote:
> When soc-button-array looks up the GPIO to use it calls acpi_find_gpio()
> which will parse _CRS.
>
> acpi_find_gpio.cold (drivers/gpio/gpiolib-acpi-core.c:953)
> gpiod_find_and_request (drivers/gpio/gpiolib.c:4598 drivers/gpio/gpiolib.c:4625)
> gpiod_get_index (drivers/gpio/gpiolib.c:4877)
>
> The GPIO is setup basically, but the debounce information is discarded.
> The platform will assert what debounce should be in _CRS, so program it
> at the time it's available.
>
> As this is considered non fatal if it fails, introduce a helper for
> programming debounce and show a warning when failing to program.
I think I already commented on this previously. Let me do that below anyway.
...
> +static void acpi_set_debounce_timeout(struct gpio_desc *desc, unsigned int timeout)
> +{
> + int ret;
> +
> + /* ACPI uses hundredths of milliseconds units */
> + ret = gpio_set_debounce_timeout(desc, timeout * 10);
> + if (ret)
> + dev_warn(&desc->gdev->dev,
> + "Failed to set debounce-timeout: %d\n", ret);
> +}
I would make it still return the code to the caller. See below why.
...
> - /* ACPI uses hundredths of milliseconds units */
> - ret = gpio_set_debounce_timeout(desc, info.debounce * 10);
> - if (ret)
> - return ret;
> + acpi_set_debounce_timeout(desc, info.debounce);
The commit message fails to explain why we do relax the condition here. This is
about GpioInt() resource and so far I haven't heard about misused debounce
values there. If we drop the fatality, it has to be a separate patch explaining
why. But only if we have practical use cases. AS long as there no failed
platforms, I can't agree on this piece of change.
--
With Best Regards,
Andy Shevchenko
