Messages in this thread | | | From | Linus Walleij <> | Date | Thu, 12 Oct 2023 08:59:02 +0200 | Subject | Re: [PATCH 0/3] i2c: mux: don't access GPIOLIB internal structures |
| |
Hi Bartosz,
On Wed, Oct 11, 2023 at 3:02 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> The backstory for this short series is that we are identyfing and > removing all unauthorized uses of GPIOLIB structures across the kernel. > > For example: there are many users that access struct gpio_chip when the > only user allowed to safely do this is the provider of that chip. > > We are very close to removing gpiochip_find(). Another function that > poses a similar problem is gpiod_to_chip() which also returns the > address of the underlying gpio_chip without assuring that it will not go > away e.g. due to a hot-unplug event or a device unbind. > > We'll need to replace it with gpiod_to_gpio_device() across the entire > tree. Let's start by actually providing it and adding the first user: > the i2c-mux-gpio driver which dereferences the otherwise opaque struct > gpio_desc. > > Let's also add a helper that allows to retrieve the address of the > struct device backing the GPIO device as this is another valid use-case. > > Finally, let's un-include the GPIO private header and fix the code to > access the device in a safe way. > > As the change is pretty minor, it would be best if patch 3/3 could be > acked by the I2C mux maintainers and went through the GPIO tree. > Otherwise, I can apply patches 1 and 2 and provide an immutable branch. > > Bartosz Golaszewski (3): > gpiolib: provide gpio_device_to_device() > gpiolib: provide gpiod_to_gpio_device() > i2c: mux: gpio: don't fiddle with GPIOLIB internals
The series: Acked-by: Linus Walleij <linus.walleij@linaro.org> Good job!
Yours, Linus Walleij
| |