Optional GPIOs mean they can be omitted. If they are described, a
failure in acquiring them still needs to be reported. When the
RESET_GPIO is not enabled (so the reset core cannot provide its assumed
fallback), the user should be informed about it. So, not only bail out
but also give a hint how to fix the situation. This means the check has
to be moved after ensuring the GPIO is really described.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
Changes since RFC v1:
* moved the code after second phandle check
* switched to pr_err
* updated commit message
* moved Reported-by to patch 2
drivers/reset/core.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 22f67fc77ae5..c1909074f715 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -1028,9 +1028,6 @@ __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.
@@ -1040,6 +1037,11 @@ __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.2On Wed, Oct 15, 2025 at 10:59:21PM +0200, Wolfram Sang wrote: > Optional GPIOs mean they can be omitted. If they are described, a > failure in acquiring them still needs to be reported. When the > RESET_GPIO is not enabled (so the reset core cannot provide its assumed > fallback), the user should be informed about it. So, not only bail out > but also give a hint how to fix the situation. This means the check has > to be moved after ensuring the GPIO is really described. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Philipp, I reverted the offending commit in i2c-mux. You can revert this one as well.
On Mi, 2025-10-15 at 22:59 +0200, Wolfram Sang wrote:
> Optional GPIOs mean they can be omitted. If they are described, a
> failure in acquiring them still needs to be reported. When the
> RESET_GPIO is not enabled (so the reset core cannot provide its assumed
> fallback), the user should be informed about it. So, not only bail out
> but also give a hint how to fix the situation. This means the check has
> to be moved after ensuring the GPIO is really described.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Patch 1 applied to reset/next, thanks!
[1/2] reset: always bail out on missing RESET_GPIO driver
https://git.pengutronix.de/cgit/pza/linux/commit/?id=25d4d4604d01
regards
Philipp
On 30/10/2025 13:54, Philipp Zabel wrote: > On Mi, 2025-10-15 at 22:59 +0200, Wolfram Sang wrote: >> Optional GPIOs mean they can be omitted. If they are described, a >> failure in acquiring them still needs to be reported. When the >> RESET_GPIO is not enabled (so the reset core cannot provide its assumed >> fallback), the user should be informed about it. So, not only bail out >> but also give a hint how to fix the situation. This means the check has >> to be moved after ensuring the GPIO is really described. >> >> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > Patch 1 applied to reset/next, thanks! > > [1/2] reset: always bail out on missing RESET_GPIO driver > https://git.pengutronix.de/cgit/pza/linux/commit/?id=25d4d4604d01 Why? This wasn't tested and wasn't reviewed... there were objections to this patchset and long discussion. Best regards, Krzysztof
> > [1/2] reset: always bail out on missing RESET_GPIO driver > > https://git.pengutronix.de/cgit/pza/linux/commit/?id=25d4d4604d01 > > > Why? This wasn't tested and wasn't reviewed... there were objections to > this patchset and long discussion. Only to patch 2? AFAIR there was no discussion regarding patch 1.
On 03/11/2025 16:12, Wolfram Sang wrote: > >>> [1/2] reset: always bail out on missing RESET_GPIO driver >>> https://git.pengutronix.de/cgit/pza/linux/commit/?id=25d4d4604d01 >> >> >> Why? This wasn't tested and wasn't reviewed... there were objections to >> this patchset and long discussion. > > Only to patch 2? AFAIR there was no discussion regarding patch 1. > This patch alone is broken. Breaks all users. The true problem for your systems is of course your I2C driver commit 690de2902dca... Best regards, Krzysztof
On Mi, 2025-10-15 at 22:59 +0200, Wolfram Sang wrote: > Optional GPIOs mean they can be omitted. If they are described, a > failure in acquiring them still needs to be reported. When the > RESET_GPIO is not enabled (so the reset core cannot provide its assumed > fallback), the user should be informed about it. So, not only bail out > but also give a hint how to fix the situation. This means the check has > to be moved after ensuring the GPIO is really described. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> regards Philipp
On Mi, 2025-10-15 at 22:59 +0200, Wolfram Sang wrote: > Optional GPIOs mean they can be omitted. If they are described, a > failure in acquiring them still needs to be reported. When the > RESET_GPIO is not enabled (so the reset core cannot provide its assumed > fallback), the user should be informed about it. So, not only bail out > but also give a hint how to fix the situation. This means the check has > to be moved after ensuring the GPIO is really described. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> regards Philipp
© 2016 - 2025 Red Hat, Inc.