[PATCH] Revert "reset: always bail out on missing RESET_GPIO driver"

Philipp Zabel posted 1 patch 1 month, 2 weeks ago
drivers/reset/core.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
[PATCH] Revert "reset: always bail out on missing RESET_GPIO driver"
Posted by Philipp Zabel 1 month, 2 weeks ago
This reverts commit 25d4d4604d01eb0ce5254f0516826127dacb5015, which
caused unexpected fallout:

Drivers that handle optional reset GPIOs via the reset controller API,
on platforms that have a reset-gpios property in the device tree node,
would fail to probe instead of falling back to either ignoring the reset
or handling it via the GPIO API, if the RESET_GPIO driver was disabled.

Suggested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 drivers/reset/core.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 4fbaa67a6f79..8029e547e3db 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -1001,6 +1001,9 @@ __of_reset_control_get(struct device_node *node, const char *id, int index,
 	if (ret == -EINVAL)
 		return ERR_PTR(ret);
 	if (ret) {
+		if (!IS_ENABLED(CONFIG_RESET_GPIO))
+			return optional ? NULL : ERR_PTR(ret);
+
 		/*
 		 * There can be only one reset-gpio for regular devices, so
 		 * don't bother with the "reset-gpios" phandle index.
@@ -1010,11 +1013,6 @@ __of_reset_control_get(struct device_node *node, const char *id, int index,
 		if (ret)
 			return optional ? NULL : ERR_PTR(ret);
 
-		if (!IS_ENABLED(CONFIG_RESET_GPIO)) {
-			pr_err("%s(): RESET_GPIO driver not enabled, cannot fall back\n", __func__);
-			return ERR_PTR(-ENOEXEC);
-		}
-
 		gpio_fallback = true;
 
 		ret = __reset_add_reset_gpio_device(&args);
-- 
2.47.3
Re: [PATCH] Revert "reset: always bail out on missing RESET_GPIO driver"
Posted by Wolfram Sang 1 month, 2 weeks ago
On Wed, Nov 05, 2025 at 10:39:20AM +0100, Philipp Zabel wrote:
> This reverts commit 25d4d4604d01eb0ce5254f0516826127dacb5015, which
> caused unexpected fallout:
> 
> Drivers that handle optional reset GPIOs via the reset controller API,
> on platforms that have a reset-gpios property in the device tree node,
> would fail to probe instead of falling back to either ignoring the reset
> or handling it via the GPIO API, if the RESET_GPIO driver was disabled.
> 
> Suggested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Thank you!