[patch 2.6.24-rc4-mm 0/6] gpiolib updates

[David Brownell]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/