Re: [PATCH 07/21] gpiolib: provide gpio_device_get_base()
Dipen Patel <[email protected]> Tue, 3 Oct 2023 13:32:12 -0700
| Newsgroups | dev.linux.lists.timestamp,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-acpi,org.kernel.vger.linux-gpio,org.kernel.vger.linux-kernel,org.kernel.vger.linux-omap,org.kernel.vger.linux-tegra,org.kernel.vger.platform-driver-x86 |
|---|---|
| Message-ID | <[email protected]> |
On 9/7/23 12:57 AM, Bartosz Golaszewski wrote: > On Thu, Sep 7, 2023 at 9:17 AM Linus Walleij <[email protected]> wrote: >> >> On Tue, Sep 5, 2023 at 8:53 PM Bartosz Golaszewski <[email protected]> wrote: >> >>> From: Bartosz Golaszewski <[email protected]> >>> >>> Let's start adding getters for the opaque struct gpio_device. Start with >>> a function allowing to retrieve the base GPIO number. >>> >>> Signed-off-by: Bartosz Golaszewski <[email protected]> >> >> I guess you have a solid usecase for drivers needing to do this >> crazy thing, because I suppose you feel as much as me that >> this should rather be gpiolib-internal and confined to >> drivers/gpio/gpiolib.h? >> >> If you add a valid reason for making this globally visible outside >> of drivers/[gpio|pinctrl] to the commit message I guess I can live >> with it because we need to think of the bigger picture: >> Acked-by: Linus Walleij <[email protected]> >> >> It brings to mind the now confusing "base" inside of >> struct gpio_chip. We all know it should go away, but since it >> is never used during the lifetime of the gpio_chip - or SHOULD >> never be used - it should rather be an argument to >> [devm_]gpiochip_add_data( .... int base);... >> >> Maybe something we should add to our TODO file. >> >> Yours, >> Linus Walleij > > For this series it's the HTE driver that uses it and I don't have a > good idea about how to change it. Dipen? Missed responding to this, apologies. I believe we are having similar discussion in the hte only patch. We can continue discussing there. > > I would also love to make pinctrl not use the internal GPIOLIB header > so it'll be another user, unless you can figure out a way to not use > gc->base? :) > > I think we're stuck with it for now. > > Bart