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.
Bartosz
