Thread (16 messages) 16 messages, 5 authors, 2025-12-30

Re: [PATCH v2 2/3] i2c: k1: add reset support

From: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Date: 2025-12-30 14:15:49
Also in: linux-i2c, linux-riscv, lkml, spacemit

On Tue, Dec 30, 2025 at 10:11:16PM +0800, Troy Mitchell wrote:
On Sun, Dec 28, 2025 at 08:42:47AM +0800, Guodong Xu wrote:
quoted
Hi, Andi

On Sun, Dec 28, 2025 at 3:26 AM Andi Shyti [off-list ref] wrote:
quoted
Hi Guodong,

On Fri, Dec 26, 2025 at 07:38:22AM +0800, Guodong Xu wrote:
quoted
On Fri, Dec 26, 2025 at 5:01 AM Andi Shyti [off-list ref] wrote:
quoted
quoted
+     rst = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
+     if (IS_ERR(rst))
+             return dev_err_probe(dev, PTR_ERR(rst),
+                                  "failed to acquire deasserted reset\n");
If this is optional, why are we returning with error?
According to include/linux/reset.h, if the requested reset is not
specified in the device tree, this function returns NULL instead of
an error. Therefore, IS_ERR(rst) will only be true for actual
errors (e.g probe deferral).
And this is quite obvious, but you haven't answered my qestion.

Why do we care of internal failures in reset? If reset fails on
an optional reset control function why should we kill our driver?
Thanks for the clarification. I see your point now.

My reasoning is that if the resets property is explicitly listed in the
Device Tree, the driver must respect it.
Sorry, I misread your comment. I thought you were referring to the
bindings. In that case, we are on the same page.

                                    - Troy
It's not required.
quoted
If the property is present but
we encounter an error (like -EPROBE_DEFER), ignoring that failure could
put the hardware in an undefined or dirty state.
Then why it's optional?

The real reason:
"Optional" here means the reset line is allowed to be absent from the
Device Tree. It does not mean we can ignore the failure when it is
defined in the DT but fails to be acquired.

If devm_reset_control_get_optional_* returns an error (e.g.,
-EPROBE_DEFER), it indicates the hardware description expects a reset
control, but the system is not yet ready to provide it. Ignoring this
error would break the probe deferral mechanism and potentially cause the
driver to access hardware in an invalid state.

                          - Troy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help