All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: David Brownell <david-b@pacbell.net>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine
Date: Fri, 29 Feb 2008 23:55:32 +0300	[thread overview]
Message-ID: <20080229205532.GA26939@localhost.localdomain> (raw)
In-Reply-To: <20080215114029.GA16810@localhost.localdomain>

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: cboumailru@gmail.com
irc://irc.freenode.net/bd2

  reply	other threads:[~2008-02-29 20:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-03 17:08 [RFC PATCH 0/11] Patches needed to support QE USB Host Controller Anton Vorontsov
2008-02-03 17:09 ` [PATCH 01/11] [POWERPC] Implement support for the GPIO LIB API Anton Vorontsov
2008-02-03 21:17   ` David Brownell
2008-02-04 13:19     ` Anton Vorontsov
2008-02-03 17:09 ` [PATCH 02/11] [POWERPC] QE: split par_io_config_pin() Anton Vorontsov
2008-02-03 17:10 ` [PATCH 03/11] [POWERPC] QE: implement GPIO LIB API Anton Vorontsov
2008-02-03 17:10 ` [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine Anton Vorontsov
2008-02-03 21:22   ` David Brownell
2008-02-03 23:32     ` Anton Vorontsov
2008-02-15  4:36       ` David Brownell
2008-02-15 11:40         ` Anton Vorontsov
2008-02-29 20:55           ` Anton Vorontsov [this message]
2008-02-03 17:10 ` [PATCH 05/11] [POWERPC] qe_lib: support for gpio_set_dedicated Anton Vorontsov
2008-02-04 17:38   ` Timur Tabi
2008-02-03 17:10 ` [PATCH 06/11] [POWERPC] qe_lib: implement qe_muram_offset Anton Vorontsov
2008-02-03 17:10 ` [PATCH 07/11] [POWERPC] qe_lib: export qe_get_brg_clk Anton Vorontsov
2008-02-03 17:10 ` [PATCH 08/11] [POWERPC] qe_lib: implement QE GTM support Anton Vorontsov
2008-02-04 20:30   ` Scott Wood
2008-02-04 20:56     ` Anton Vorontsov
2008-02-03 17:10 ` [PATCH 09/11] [POWERPC] qe_lib: add support for QE USB Anton Vorontsov
2008-02-03 17:10 ` [PATCH 10/11] [POWERPC] mpc8360erdk: add FHCI USB support Anton Vorontsov
2008-02-03 17:11 ` [PATCH 11/11] [RFC USB POWERPC] Freescale QUICC Engine USB Host Controller Anton Vorontsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080229205532.GA26939@localhost.localdomain \
    --to=avorontsov@ru.mvista.com \
    --cc=david-b@pacbell.net \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.