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.
- TroyIt'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