linuxppc-dev.lists.ozlabs.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).