[i2c] [PATCH] basic gpio_chip support for 16-bit PCA9539 GPIO expander

[Jean Delvare]

On Mon, 3 Dec 2007 19:33:42 -0800, David Brownell wrote:
> On Monday 03 December 2007, eric miao wrote:
> > #> grep -iR "pca9539" *
> > 
> > gave me the following potential users of pca9539:
> > 
> > arch/mips/configs/bigsur_defconfig:CONFIG_SENSORS_PCA9539=y
> > arch/mips/configs/mtx1_defconfig:CONFIG_SENSORS_PCA9539=m
> > ...
> > arch/arm/configs/picotux200_defconfig:CONFIG_SENSORS_PCA9539=m
> > ...
> > 
> > and I doubt if these defconfigs are sane about their I2C configurations
> > (if you don't mind take a look into these files :-),
> 
> I've seen that issue with a few defconfigs, yes.

I wouldn't trust these defconfigs either way. Some appear to include
much more than they need (picotux being the best example of this) and
OTOH some people might not have submitted their config. Not to mention
that GPIO chips can be used by PC hobbyists (that's the main use for
the in-kernel pcf8574 driver as far as I know) so no defconfig is
available for these.

> > and also with Ben's 
> > acknowledgment, I don't think this would be a problem. If you don't
> > feel good about this, I can try adding those sysfs stuffs back, though
> > the final code might be a bit uglier.
> 
> No, I don't much like that sysfs interface.  If nobody actually
> needs it (Ben might be the best person to know), I have no qualms
> with removing it.

As discussed with David earlier, the right way to implement a
user-space interface to GPIOs would be at the gpiolib level, not in
individual drivers. If anyone complains about the now missing
user-space interface to the PCA9539, let's work with them on
implementing this properly. So I have no problem with the sysfs
interface removal from the pca9539 driver either.

Also as discussed earlier, did we reach a consensus on the right
location for these GPIO driver in the tree? My preference still goes to
drivers/gpio.

-- 
Jean Delvare