linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [patch 2.6.24-rc4-mm 0/6] gpiolib updates
@ 2007-12-10  4:34 David Brownell
  2007-12-10 16:07 ` Jean Delvare
  0 siblings, 1 reply; 2+ messages in thread
From: David Brownell @ 2007-12-10  4:34 UTC (permalink / raw)
  To: Andrew Morton, Linux Kernel list; +Cc: eric miao, Jean Delvare

Following this are several patches updating the current gpio
implemenentation framework.  Because one of those changes
involves creating a new drivers/gpio directory, the patches
are a bit simpler if two existing patches are first removed
from the MM tree:

	mcp23s08-spi-gpio-expander.patch
	mcp23s08-spi-gpio-expander-checkpatch-fixes.patch

The patches in this series are:

 - Adding a gpio_desc[] layer, making it easier to mix in
   gpio_chips with different numbers of GPIOs without any
   large holes in the number sequence.  When those holes
   are also reflected in IRQ number sequences, they cost
   a lot of memory.  (Based on work from Eric Miao.)

 - More diagnostics with CONFIG_DEBUG_GPIO.  Handy when
   bringing up a new board, needless later.  (Various
   platforms had similar diagnostics.)

 - A bit of implementor-oriented documentation for this
   gpiolib infrastructure.

 - Create a new drivers/gpio directory for expanders and
   (eventually) other code.  (Strongly encouraged by
   Jean Delvare, to help shrink drivers/i2c/chips.)

 - New-style I2C driver for pcf8574/pcf8575/compatible
   GPIO expanders ... these are pretty widely used.
   (This was previously posted as patch/rfc.)

 - Relocated mcp23s08 driver.  This includes two minor
   functional changes, to handle the gpio_desc changes
   and modified driver init sequence, and it merges the
   minor checkpatch.pl update above.

There's an updated pca9539 driver in the works too; it
should land in the drivers/i2c directory.

I'm thinking there should be a non-functional change to
the gpiolib code:  move it from lib to drivers/gpio.

My question is whether that's better done by replacing
the current patches with one new patch, or by a patch
deleting the current lib/gpiolib.c and adding a new
drivers/gpio/gpiolib.c ... I think the former would
make more sense to anyone looking at GIT history.

- Dave

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [patch 2.6.24-rc4-mm 0/6] gpiolib updates
  2007-12-10  4:34 [patch 2.6.24-rc4-mm 0/6] gpiolib updates David Brownell
@ 2007-12-10 16:07 ` Jean Delvare
  0 siblings, 0 replies; 2+ messages in thread
From: Jean Delvare @ 2007-12-10 16:07 UTC (permalink / raw)
  To: David Brownell; +Cc: Andrew Morton, Linux Kernel list, eric miao

Hi David,

On Sun, 9 Dec 2007 20:34:59 -0800, David Brownell wrote:
> I'm thinking there should be a non-functional change to
> the gpiolib code:  move it from lib to drivers/gpio.
> 
> My question is whether that's better done by replacing
> the current patches with one new patch, or by a patch
> deleting the current lib/gpiolib.c and adding a new
> drivers/gpio/gpiolib.c ... I think the former would
> make more sense to anyone looking at GIT history.

If gpiolib isn't in git yet, then indeed updating the patch that
creates it before it goes in git sounds more sensible. Let's not make
the git history more complex than needed.

Thanks,
-- 
Jean Delvare

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-12-10 16:07 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-10  4:34 [patch 2.6.24-rc4-mm 0/6] gpiolib updates David Brownell
2007-12-10 16:07 ` Jean Delvare

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).