Re: [PATCH] gpio: sysfs: fix chip removal with GPIOs exported over sysfs

[Johan Hovold <johan@kernel.org>]

On Fri, Feb 13, 2026 at 10:11:47AM -0800, Bartosz Golaszewski wrote:
> On Fri, 13 Feb 2026 09:32:47 +0100, Johan Hovold <johan@kernel.org> said:
> > On Thu, Feb 12, 2026 at 02:35:05PM +0100, Bartosz Golaszewski wrote:
> >> Currently if we export a GPIO over sysfs and unbind the parent GPIO
> >> controller, the exported attribute will remain under /sys/class/gpio
> >> because once we remove the parent device, we can no longer associate the
> >> descriptor with it in gpiod_unexport() and never drop the final
> >> reference.
> >
> > Is this a recent regression? I'm quite sure fixed this once back in
> > 2015.
> 
> Yes, that sometimes happens. There have been close to 100 commits between your
> fix and now, including two major reworks.

It sure does. I was just pointing out that this is a regression, which
wasn't apparent from your commit message.

> >> Rework the teardown code: provide an unlocked variant of
> >> gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken
> >> before unregistering the parent device itself. This is done to prevent
> >> any new exports happening before we unregister the device completely.
> >
> > So please add a Fixes tag here to document this.
> >
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

> It bisects to this commit, though it's possible it's a mix of several changes.
> 
> Fixes: 1cd53df733c2 ("gpio: sysfs: don't look up exported lines as
> class devices")

That's the commit from last summer that I suspected as well after a
quick glance at the code (hence the word "recent" above).

We don't want anyone trying to backport this further back than needed.

Johan