[PATCH 00/21] gpio: convert users to gpio_device_find() and remove gpiochip_find()

[Linus Walleij]

On Tue, Sep 5, 2023 at 8:53 PM Bartosz Golaszewski <brgl at bgdev.pl> wrote:

> The GPIO subsystem does not handle hot-unplug events very well.

Yeah :/ it was never designed for this, and I've seen the discussions.

The person who made the biggest effort to make this sort-of work
was actually Johan Hovold so I added him to the mail so you can
include him in upcoming iterations. I think he was working with
GPIO on greybus at the time. Maybe he want to take a look!

> Before we can even get to fixing the locking, we need to address a serious
> abuse of the GPIO driver API - accessing struct gpio_chip by anyone who isn't
> the driver owning this object. This structure is owned by the GPIO provider
> and its lifetime is tied to that of that provider. It is destroyed when the
> device is unregistered and this may happen at any moment. struct gpio_device
> is the opaque, reference counted interface to struct gpio_chip (which is the
> low-level implementation) and all access should pass through it.

Thanks for looking into this. As I remember I have tried to bring down
this abuse over the years and IIRC it used to be even worse, it came
from the fact that all GPIO drivers used to be under some arch/*
tree and often loosely using the kernel GPIO API but in addition
providing a custom API...

> The end-goal is to make all gpio_device manipulators check the existence of
> gdev->chip and then lock it for the duration of any of the calls using SRCU.

Excellent!

> This series starts the process by replacing gpiochip_find() with
> gpio_device_find(). This is in line with other device_find type interfaces and
> returns a reference to the GPIO device that is guaranteed to remain valid
> until it is put.

I agree with the direction and I see no major problem with the
patches other than some testing and cosmetics. The kernel sure
as hell looks better *after* this than *before* so once you have rough
confidence in the patches I think they should be merged and any
issuse fixed up in-tree so we get wider audience and can continue
the planned refactorings. So:
Acked-by: Linus Walleij <linus.walleij at linaro.org>

I'll try to provide some detailed reviews if something stands out.

Yours,
Linus Walleij