[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <541066FE3973E490+aVPdhNKK70qltaVV@troy-wujie14pro-arch>
Date: Tue, 30 Dec 2025 22:11:16 +0800
From: Troy Mitchell <troy.mitchell@...ux.spacemit.com>
To: Guodong Xu <guodong@...cstar.com>, Andi Shyti <andi.shyti@...nel.org>
Cc: Encrow Thorne <jyc0019@...il.com>,
Troy Mitchell <troy.mitchell@...ux.spacemit.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Yixun Lan <dlan@...too.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Paul Walmsley <pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
Troy Mitchell <troymitchell988@...il.com>,
linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
linux-riscv@...ts.infradead.org, spacemit@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] i2c: k1: add reset support
On Sun, Dec 28, 2025 at 08:42:47AM +0800, Guodong Xu wrote:
> Hi, Andi
>
> On Sun, Dec 28, 2025 at 3:26 AM Andi Shyti <andi.shyti@...nel.org> wrote:
> >
> > Hi Guodong,
> >
> > On Fri, Dec 26, 2025 at 07:38:22AM +0800, Guodong Xu wrote:
> > > On Fri, Dec 26, 2025 at 5:01 AM Andi Shyti <andi.shyti@...nel.org> wrote:
> > > > > + 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.
It's not required.
>
> 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
Powered by blists - more mailing lists