From: Bartosz Golaszewski <[email protected]>
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
drivers/gpio/gpiolib.c | 38 ++++++++++++++++++++++++++++++++
drivers/i2c/muxes/i2c-mux-gpio.c | 12 +++++-----
include/linux/gpio/driver.h | 3 +++
3 files changed, 47 insertions(+), 6 deletions(-)
--
2.39.2
Hi Bartosz,
On Wed, Oct 11, 2023 at 3:02 PM Bartosz Golaszewski <[email protected]> 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 <[email protected]>
Good job!
Yours,
Linus Walleij
On Wed, Oct 11, 2023 at 3:02 PM Bartosz Golaszewski <[email protected]> wrote:
>
> From: Bartosz Golaszewski <[email protected]>
>
> 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
>
> drivers/gpio/gpiolib.c | 38 ++++++++++++++++++++++++++++++++
> drivers/i2c/muxes/i2c-mux-gpio.c | 12 +++++-----
> include/linux/gpio/driver.h | 3 +++
> 3 files changed, 47 insertions(+), 6 deletions(-)
>
> --
> 2.39.2
>
Queued for v6.7.
Bart