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