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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <97163966BA7F4D3A+aVPePaJvByddfCe3@troy-wujie14pro-arch>
Date: Tue, 30 Dec 2025 22:14:21 +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 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:
> > 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.
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.
> 
> >
> > 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