On Tue, 23 Jan 2024 at 15:32, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> 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
No, I don't want you to ignore the commits without Cc: stable. I may
have been too eager to react but earlier today I saw Sasha pick up
patches that were clearly adding new features and *did not* have any
Fixes tags on them.
Nevermind this message.
Thanks
Bartosz
