Message-ID: <CAMRc=MfNP4=PB5DwFJijTffW2uBa+k6=2F0=VT87uD7LPfusjg@mail.gmail.com>
Date: Sat, 6 Dec 2025 09:45:58 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, 
	Philipp Zabel <p.zabel@...gutronix.de>, linux-kernel@...r.kernel.org, 
	stable@...r.kernel.org
Subject: Re: [PATCH] reset: gpio: suppress bind attributes in sysfs

On Thu, Dec 4, 2025 at 12:53 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On 04/12/2025 12:22, Bartosz Golaszewski wrote:
> > On Thu, Dec 4, 2025 at 12:14 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> >>
> >> On 04/12/2025 10:44, Bartosz Golaszewski wrote:
> >>> This is a special device that's created dynamically and is supposed to
> >>> stay in memory forever. We also currently don't have a devlink between
> >>
> >> Not forever. If every consumer is unloaded, this can be unloaded too, no?
> >>
> >>> it and the actual reset consumer. Suppress sysfs bind attributes so that
> >>
> >> With that reasoning every reset consumer should have suppress binds.
> >> Devlink should be created by reset controller framework so it is not
> >> this driver's fault.
> >>
> >
> > Here's my reasoning: I will add a devlink but Phillipp requested some
> > changes so I still need to resend it. It will be a bigger change than
> > this one-liner. The reset-gpio device was also converted to auxiliary
> > bus for v6.19 and I will also convert reset core to using fwnodes for
> > v6.20 so we'll significantly diverge in stable branches, while this
> > issue is present ever since the reset-gpio driver exists. It's not the
> > driver's fault but it's easier to fix it here and it very much is a
> > special case - it's a software based device rammed in between two
> > firmware-described devices.
>
> That's not the answer to my question. You can unbind every other reset
> controller. Why is this special although maybe you mentioned below?
>

Well, for one: when you unbind the device, it's never removed from the
reset-gpio lookup list, the next consumer will never be able to get
its reset control again. I recall seeing either a comment, an email or
a commit message saying that this device stays in memory forever so my
point stands: there's no reason to allow unbinding it. The kernel will
never do it, nor should user-space.

> > I don't care if we keep the tag, it's just that this commit introduced
> > a way for user-space to crash the system by simply unbinding
> > reset-gpio and then its active consumers.
> >
> > And the difference here is that there is no devlink between reset-gpio
> > and its consumers. We need to first agree how to add it.
>
> So you mean that between every other reset consumer and reset provider
> there is a devlink? And here there is no devlink?
>

Effectively: yes, but only because reset is OF-only (as of commit
8bffbfdc01df ("reset: remove legacy reset lookup code")) so device
links are created from device-tree. If you look at any device using
reset-gpio in sysfs, you'll see a supplier:gpiochipX entry but no
entry for the reset. So the answer is: yes, there's no devlink between
the reset-gpio provider and its consumers unless we create them
explicitly, which we should eventually do but I need to rethink the
patch because we should possibly also remove the devlink between the
gpiochip and the reset consumer as well.

Of course, here we could mention a different story: reset seems like
one of these subsystems suffering from object lifetime issues: if you
remove the supplier and the consumer tries to use the reset, you'll
crash because of the dangling rstc->rcdev pointer. That should be
addressed as well eventually.

Bartosz

Powered by blists - more mailing lists