Subject: Re: [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine

From: Anton Vorontsov <[email-masked]>
Date: Fri, 29 Feb 2008 23:55:32 +0300

On Fri, Feb 15, 2008 at 02:40:29PM +0300, Anton Vorontsov wrote:
[...]
> > > {
> > > 	qe_chip = container_of(gpio_to_chip(...), struct qe_chip, chip);
> > > 	...
> > 
> > You know, you can write all this yourself, without needing any
> > support from the GPIO framework whatsoever.  The QE stuff that
> > registered a gpio_chip interface to its hardware probably keeps
> > some records itself, sufficient for such (infrequent) mappings.
> 
> Yes, surely. And as I've said already, I do know how to workaround
> that, without GPIOLIB support. The thing is that I don't like the
> way I'm going to do it.

...please, don't force me to do these dirty hacks inside the arch code,
nobody will like them, I know it beforehand. ;-)

...if you so reluctant supporting dedicated functions inside the gpiolib,
then nothing could be easier than exporting gpio_to_chip(), so arch code
can write extensions without dirty hacks. Please?

p.s. By "dirty hacks" I mean:

a) drivers will need to fetch and store device_node in their private
   driver data, in _addition_ to gpio numbers;

b) which means that I'll have to introduce of_get_gpio_controller()
   to solely workaround gpio_to_chip() absence;

c) and all that will result in 9 * N additional lines of code to
   handle by the drivers, where N is the number of GPIOs we want to use:

   struct drvdata {
   (1) struct device_node *gpioX_controller;

   drv_probe()
   (2) drvdata->gpioX_controller = of_get_gpio_controller(...);
   (3) if (!drvdata->gpioX_controller) {
   (4)        ret = -EINVAL;
   (5)        goto gpioX_contr_failed;
   (6) }
   (7) gpioX_contr_failed:
   (8) of_put_gpio_controller(drvdata->gpioX_controller)

   drv_remove()
   {
   (9) of_put_gpio_controller(drvdata->gpioX_controller)

-- 
Anton Vorontsov
email: [email-masked]
irc://irc.freenode.net/bd2