Re: [PATCH 3/5] gpio: make gpiochip_get_desc() gpiolib-private

[Guenter Roeck]

On 07/22/2014 08:10 PM, Alexandre Courbot wrote:
> On Wed, Jul 23, 2014 at 5:17 AM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> > On Tue, Jul 22, 2014 at 04:17:41PM +0900, Alexandre Courbot wrote:
> > > As GPIO descriptors are not going to remain unique anymore, having this
> > > function public is not safe. Restrain its use to gpiolib since we have
> > > no user outside of it.
> > If I implement a gpio chip driver built as module, and I want to use
> > gpiochip_request_own_desc(), how am I supposed to get desc ?
> >
> > I understand that there is still gpio_to_desc(), but I would have thought
> > that
> >          desc = gpiochip_get_desc(chip, pin);
> > would be better than
> >          desc = gpio_to_desc(chip->base + pin);
> >
> > Not that it makes much of a difference for me, just asking.
>
> Actually I was thinking of changing the prototype of
> gpiochip_request_own_desc(), and your comment definitely strenghtens
> that idea. gpiochip functions should not work with descriptors,
> especially since we are going to switch to a multiple-consumer scheme
> where there won't be any canonical descriptor anymore. Thus, how about
> turning gpiochip_request_own_desc() into this:
>
> struct gpio_desc *
> gpiochip_request_own_desc(struct gpio_chip *chip, u16 hwnum, const char *label);
>
> which would basically do both the gpiochip_get_desc() and former
> gpiochip_request_own_desc() in one call. I think it should satisfy
> everybody and removes the need to have gpiochip_get_desc() (a not very
> useful function by itself) exposed out of gpiolib.
>
> I will send a patch taking care of this if you agree that makes sense.

I think you also plan to remove the capability to retrieve the chip
pointer, don't you ? If so, I won't be able to use the function from
the pca953x platform init function, since I won't be able to get the
pointer to the gpio chip. Even if you don't remove gpiod_to_chip(),
things would become a bit messy, since I would first have to convert
a pin to a desc and then to the chip pointer. Anyway, that change
would mean that exporting gpiochip_request_own_desc or its replacement
won't solve one of the problems addressed by my patch anymore, leaving
me more or less in the dark :-(.

I was thinking about implementing a separate platform driver which
would enable me to auto-export (or initialize, if needed) gpio pins
from arbitrary gpio drivers to user space. I could make this work
with both devicetree data and platform data. Sure, that driver
would not have a chance to get accepted upstream, since it would use
devicetree data to, in a sense, configure the system, but on the
upside it would be independent of gpio API changes, and it would
work for _all_ gpio chips, not just for the ones with gpio driver
support. Unfortunately this approach doesn't really work either,
since exported pin names need to be configured with the chip driver,
and can not be selected afterwards when a pin is actually exported.

On the other side, would you agree to adding something like
gpiod_export_name(), which would export a gpio pin with given name,
not using the default or chip->names ? That might help solving
at least some of my problems, and I would no longer depend on
gpiochip_request_own_desc or any of the related functions.

For reference, I currently need the ability to auto-export
gpio pins to user space for pca953x, ich, and for various
to-be-published gpio drivers used by my employer.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/