gpiolib: acpi: Make set debounce errors non fatal

Commit 16c07342b542 ("gpiolib: acpi: Program debounce when finding GPIO") adds a gpio_set_debounce_timeout() call to acpi_find_gpio() and makes acpi_find_gpio() fail if this fails.

But gpio_set_debounce_timeout() failing is a somewhat normal occurrence, since not all debounce values are supported on all GPIO/pinctrl chips.

Making this an error for example break getting the card-detect GPIO for the micro-sd slot found on many Bay Trail tablets, breaking support for the micro-sd slot on these tablets.

acpi_request_own_gpiod() already treats gpio_set_debounce_timeout() failures as non-fatal, just warning about them.

Add a acpi_gpio_set_debounce_timeout() helper which wraps gpio_set_debounce_timeout() and warns on failures and replace both existing gpio_set_debounce_timeout() calls with the helper.

Since the helper only warns on failures this fixes the card-detect issue.

Fixes 16c07342b542 ("gpiolib: acpi: Program debounce when finding GPIO")

Cc [email protected]

Cc Mario Limonciello <[email protected]>

Signed-off-by Hans de Goede <[email protected]>

---
  drivers/gpio/gpiolib-acpi-core.c | 27 +++++++++++++++------------
  1 file changed, 15 insertions(+), 12 deletions(-)

drivers/gpio/gpiolib-acpi-core.c +15 -12

index 284e762d92c4..67c4c38afb86 100644
@@ -291,6 +291,19 @@ acpi_gpio_to_gpiod_flags(const struct acpi_resource_gpio *agpio, int polarity)
  	return GPIOD_ASIS;
  }
 
+static void acpi_gpio_set_debounce_timeout(struct gpio_desc *desc,
+					   unsigned int acpi_debounce)
+{
+	int ret;
+
+	/* ACPI uses hundredths of milliseconds units */
+	acpi_debounce *= 10;
+	ret = gpio_set_debounce_timeout(desc, acpi_debounce);
+	if (ret)
+		gpiod_warn(desc, "Failed to set debounce-timeout %u: %d\n",
+			   acpi_debounce, ret);
+}
+
  static struct gpio_desc *acpi_request_own_gpiod(struct gpio_chip *chip,
  						struct acpi_resource_gpio *agpio,
  						unsigned int index,

@@ -300,18 +313,12 @@ static struct gpio_desc *acpi_request_own_gpiod(struct gpio_chip *chip,
  	enum gpiod_flags flags = acpi_gpio_to_gpiod_flags(agpio, polarity);
  	unsigned int pin = agpio->pin_table[index];
  	struct gpio_desc *desc;
-	int ret;
 
  	desc = gpiochip_request_own_desc(chip, pin, label, polarity, flags);
  	if (IS_ERR(desc))
  		return desc;
 
-	/* ACPI uses hundredths of milliseconds units */
-	ret = gpio_set_debounce_timeout(desc, agpio->debounce_timeout * 10);
-	if (ret)
-		dev_warn(chip->parent,
-			 "Failed to set debounce-timeout for pin 0x%04X, err %d\n",
-			 pin, ret);
+	acpi_gpio_set_debounce_timeout(desc, agpio->debounce_timeout);
 
  	return desc;
  }

@@ -944,7 +951,6 @@ struct gpio_desc *acpi_find_gpio(struct fwnode_handle *fwnode,
  	bool can_fallback = acpi_can_fallback_to_crs(adev, con_id);
  	struct acpi_gpio_info info = {};
  	struct gpio_desc *desc;
-	int ret;
 
  	desc = __acpi_find_gpio(fwnode, con_id, idx, can_fallback, &info);
  	if (IS_ERR(desc))

@@ -959,10 +965,7 @@ struct gpio_desc *acpi_find_gpio(struct fwnode_handle *fwnode,
  	acpi_gpio_update_gpiod_flags(dflags, &info);
  	acpi_gpio_update_gpiod_lookup_flags(lookupflags, &info);
 
-	/* ACPI uses hundredths of milliseconds units */
-	ret = gpio_set_debounce_timeout(desc, info.debounce * 10);
-	if (ret)
-		return ERR_PTR(ret);
+	acpi_gpio_set_debounce_timeout(desc, info.debounce);
 
  	return desc;
  }

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?

https://lore.kernel.org/linux-gpio/[email protected]/
[1]

Quoted 1 line · Mario Limonciello (AMD) (kernel.org)

On 9/20/2025 3:12 PM, Hans de Goede wrote:

...

Quoted 5 lines

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.

Quoted 3 lines · Andy Shevchenko

Quoted 1 line · Mario Limonciello (AMD) (kernel.org)

On 9/20/2025 3:12 PM, Hans de Goede wrote:

Quoted 6 lines

Quoted 5 lines

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?

Quoted 6 lines

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.

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

Quoted 4 lines · Hans de Goede

Quoted 3 lines · Andy Shevchenko

Quoted 1 line · Mario Limonciello (AMD) (kernel.org)

On 9/20/2025 3:12 PM, Hans de Goede wrote:

...

Quoted 20 lines

Quoted 6 lines

Quoted 5 lines

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?

Quoted 6 lines

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")

Quoted 2 lines

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?

Quoted 2 lines

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