Re: [PATCH 0/4] gpio: introduce descriptor-based interface

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 09 January 2013, Alexandre Courbot wrote:
> On Tue, Jan 8, 2013 at 10:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > I like the interface, good idea!
> 
> Great! This was initially suggested by Linus W.
> 
> > A few questions:
> >
> > Is there a plan for migrating all the existing users of the current GPIO
> > interface?
> 
> Nothing specifically planned for now, as we need to make sure the new
> interface covers all needs first. There would be a lot of drivers to
> change if we decide to deprecate the integer interface, but Coccinelle
> could probably help here.

Right.

> The question is, do we want to totally get rid of the integer
> namespace? That would be the ultimate step, but would require another
> way to identify GPIOs (controller_device:offset might be such a way),
> and also to reorganize sysfs nodes. Wouldn't that be considered
> breaking user-space? 'cause we all know what happens to those who
> break user-space.

The user interface could eventually be the only part of the kernel that
uses the numbers, but you are right that we cannot change that.

> > How do you want to deal with drivers that work on platforms that currently
> > don't use gpiolib but have their own implementation of asm/gpio.h? Are
> > we going to phase them out?
> 
> With the current code, a driver should depend on gpiolib being
> compiled if it uses the new interface. It is not even declared if
> gpiolib is not used.
> 
> Given that both interfaces are quite close, one could imagine having a
> gpiod wrapper around the integer namespace (the "opaque descriptors"
> would then just be casted integers). This way drivers would only need
> to depend on GENERIC_GPIO. It's a little bit weird to have gpiod
> wrapping around gpio in one case and the opposite in another though -
> I'd rather have these platforms convert to GPIO descriptors internally
> (or even better, to gpiolib), but this is probably asking too much.

I think it would be reasonable to force everybody to use gpiolib,
that's much easier than converting everyone to the descriptor based
interface.

> I do not know all the details of gpiolib's history, but why would
> anyone want to implement the generic gpio interface and not use
> gpiolib anyways?

Only legacy users did this. Initially there was only the header file,
with the API declared but several different implementations of it.
gpiolib was introduced later to reduce code duplication and allow having
multiple implementations in the same kernel.

> Then there are platforms who do not follow generic gpios and implement
> their own sauce. I don't think we need to care here, as these are not
> supposed to be used with generic drivers anyway.

I agree. Ideally we would convert them over as well, but there is no
need to rush that, or force it on anybody. We should just make sure
we don't grow any new platforms doing this.

> > If we are adding a new way to deal with GPIOs, would it make sense to
> > have that more closely integrated into pinctrl in one form or another?
> > My feeling is that there is already a significant overlap between the
> > two, and while the addition of the gpiod_* functions doesn't necessarily
> > make this worse, it could be a chance to improve the current situation
> > to make the interface more consistent with pinctrl.
> 
> That may be a chance to introduce deeper changes indeed - what do you
> have in mind exactly?

I don't know enough about pinctrl to have a specific idea yet, but maybe
someone else has ideas. Regarding the integration of pinctrl with gpio,
I was thinking in the past that we could make pinctrl provide everything
that gpiolib does, and have a generic gpiolib driver on top of pinctrl
so that platforms don't need to implement both interfaces but only need
to provide a pure pinctrl driver. Not sure if this makes any sense.

	Arnd