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
