On Tue, Jan 23, 2024 at 02:13:40PM +0100, Bartosz Golaszewski wrote:
> On Tue, 23 Jan 2024 at 13:48, Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, Jan 23, 2024 at 10:56:50AM +0100, Bartosz Golaszewski wrote:
> > > On Tue, 23 Jan 2024 at 03:03, Greg Kroah-Hartman
> > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > 6.6-stable review patch. If anyone has any objections, please let me know.
> > > >
> > > > ------------------
> > > >
> > > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
> > > >
> > > > [ Upstream commit cfe102f63308c8c8e01199a682868a64b83f653e ]
> > > >
> > > > gpiochip_find() is wrong and its kernel doc is misleading as the
> > > > function doesn't return a reference to the gpio_chip but just a raw
> > > > pointer. The chip itself is not guaranteed to stay alive, in fact it can
> > > > be deleted at any point. Also: other than GPIO drivers themselves,
> > > > nobody else has any business accessing gpio_chip structs.
> > > >
> > > > Provide a new gpio_device_find() function that returns a real reference
> > > > to the opaque gpio_device structure that is guaranteed to stay alive for
> > > > as long as there are active users of it.
> > > >
> > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
> > > > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
> > > > Stable-dep-of: 48e1b4d369cf ("gpiolib: remove the GPIO device from the list when it's unregistered")
> > > > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
> > > > ---
> > >
> > > Greg,
> > >
> > > I think there's something not quite right with the system for picking
> > > up patches into stable lately. This is the third email where I'm
> > > stopping Sasha or you from picking up changes that are clearly new
> > > features and not fixes suitable for backporting.
> > >
> > > Providing a new, improved function to replace an old interface should
> > > not be considered for stable branches IMO. Please drop it.
> >
> > Even if it is required for a valid bugfix that affects users? This is a
> > dependency of the commit 48e1b4d369cf ("gpiolib: remove the GPIO device
> > from the list when it's unregistered"), shouldn't that be backported to
> > all affected kernels properly?
> >
> > thanks,
> >
> > greg k-h
>
> Eh... It is technically a fix but also this has been like it since
> 2014 and nobody ever hit the bug (or bothered to report it). Ok do as
> you wish with this one.
You all marked the commit as a fix for an issue, so that's why we
backported all of this. If something is NOT a fix, don't tag it as
such? :)
Or, if you want, we can ignore all patches in the gpio subsystem that
are NOT explicitly tagged with a cc: stable@ tag, if you agree that you
will properly tag everything. Some other subsytems do this, but that
increases the responsibility on the maintainers of the subsystem, which
is not something I would ever ask anyone to do.
Heck, for my subsystems, I miss tagging stable a lot, but the scripts
pick up those that get Fixes: tags, so it's a good back-stop to solve
problems.
Again, if you want us to ignore any portion of the tree that you are the
maintainer, just let me know the directory(ies) that you want and I can
add it to the "ignore list" or you can send a patch for this file:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list
thanks!
gre gk-h
