Messages in this thread | | | From | David Brownell <> | Subject | Re: [patch/rfc 2/4] pcf875x I2C GPIO expander driver | Date | Fri, 30 Nov 2007 12:59:21 -0800 |
| |
On Friday 30 November 2007, Jean Delvare wrote: > > So the user-space interface would be part of the generic GPIO > infrastructure? I like the idea.
I thought that would make sense too! :) Someone would need to write the code though. Having such a mechanism would provide another "carrot" to migrate folk towards the gpiolib core.
I think adding a gpiochip primitive to mark a (potential) GPIO as invalid would support the converse of /sys/kernel/debug/gpio. Invalid GPIOs include pins set up for non-GPIO usage (like being used for MMC or MII), or not wired up on a given board. Pins that were valid as GPIOs and not requested by a kernel driver might reasonably be managed by userspace code.
> > > > +#include <linux/pcf857x.h> > > > > > > I suspect that there will be many more such header files in the future. > > > Would it make sense to move them to include/linux/gpio? > > > > I was thinking more like <linux/i2c/...> myself. There are many more > > I2C chips than GPIO expanders. > > But most i2c chip drivers don't need a header file. Or is this going to > change with the new-style i2c drivers?
I expect it will become a lot more common. Remember that legacy I2C drivers *couldn't* get any board-specific config data; that's been problematic, since it meant the drivers themselves ended up with lots of board-specific cruft. That prevented many drivers from going upstream at all. (As I mentioned about pcf8574 code, although in that case the problem was worsened by lack of any reusable kernel interface for such GPIO signals.)
> Along the same line, I am wondering if it would make sense to put the > various GPIO drivers in drivers/gpio.
Could be. Right now we have three "GPIO expander" drivers using the new "gpiolib" framework: pcf875x and pca9539 for I2C, and mcp23s08 for SPI. There are many more that *could* be used with Linux boxes. And there are other drivers/XYZ directories that are (currently) that small. Maybe gpiolib should go upstream like that, and lib/gpiolib should be in drivers/gpio too...
However, keep in mind that lots of chips export a few GPIOs but don't have that as their core functionality ... one example is the drivers/i2c/chips/tps65010 driver. So it'd never be the case that GPIO drivers only live in that directory.
- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |