public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: David Brownell <david-b@pacbell.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	eric miao <eric.y.miao@marvell.com>
Subject: Re: [patch 2.6.24-rc4-mm 4/6] gpiolib:  create empty drivers/gpio
Date: Mon, 10 Dec 2007 17:16:09 +0100	[thread overview]
Message-ID: <20071210171609.0d4738b8@hyperion.delvare> (raw)
In-Reply-To: <200712092039.57722.david-b@pacbell.net>

Hi David,

On Sun, 9 Dec 2007 20:39:57 -0800, David Brownell wrote:
> From: David Brownell <dbrownell@users.sourceforge.net>
> 
> Add an empty drivers/gpio directory for gpiolib based GPIO expanders.
> We already have three of them (two I2C, one SPI), and there are dozens
> of similar chips that only exist for GPIO expansion.
> 
> This won't be the only place to hold such gpio_chip code.  Many external
> chips add a few GPIOs as secondary functionality, and platform code
> frequently needs to closely integrate GPIO and IRQ support.
> 
> This is placed *early* in the build/link sequence since it's common for
> other drivers to depend on GPIOs to do their work, so they need to be
> initialized early in the device_initcall() sequence.

Note that I foresee potential problems with this. These GPIO drivers
need I2C or SPI to be initialized before they can load. However on some
systems, I2C or SPI buses are hanging off GPIOs, meaning that these
GPIOS need to be initialized before I2C or SPI, respectively. I can
imagine weird setups where for example an SPI bus would be driven by an
I2C-based GPIO chip, or vice-versa. I sure hope that nobody does this,
but you never know... And I'm not sure how we would possibly support
this.

-- 
Jean Delvare

  reply	other threads:[~2007-12-10 16:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200712092022.14062.david-b@pacbell.net>
2007-12-10  4:39 ` [patch 2.6.24-rc4-mm 1/6] gpiolib: add gpio_desc[] David Brownell
2007-12-10  4:39 ` [patch 2.6.24-rc4-mm 2/6] gpiolib: more CONFIG_DEBUG_GPIO diagnostics David Brownell
2007-12-10  4:39 ` [patch 2.6.24-rc4-mm 3/6] gpiolib: implementor-oriented documentation David Brownell
2007-12-10  4:39 ` [patch 2.6.24-rc4-mm 4/6] gpiolib: create empty drivers/gpio David Brownell
2007-12-10 16:16   ` Jean Delvare [this message]
2007-12-10 16:52     ` David Brownell
2007-12-10  4:40 ` [patch 2.6.24-rc4-mm 5/6] gpiolib: pcf857x i2c expander driver David Brownell
2007-12-10  4:40 ` [patch 2.6.24-rc4-mm 6/6] gpiolib: replacement mcp23s08 driver David Brownell

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=20071210171609.0d4738b8@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=akpm@linux-foundation.org \
    --cc=david-b@pacbell.net \
    --cc=eric.y.miao@marvell.com \
    --cc=linux-kernel@vger.kernel.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