gpio: pcf857x handle pca9500 and pca9501

From: Jonathan Cameron <[email protected]>
Addition of pca9500 and pca9501 chips to the pcf857x driver.

--
These two chips have two elements (on different i2c addresses), the first is a clone of the pcf8574 and the second 2kBit eeprom. Seems easiest to support these separately so main query about this patch is should the device naming reflect this dual functionality.

I've been using the pcf857x driver with a 9500 for several months without problems and just want this in to clean up a confusing element in a board config.

As the Kconfig title for these is getting a bit long and the datasheet for these starts with stating they are pcf957x compatible so I haven't changed it.
--

diff -uprN -X a/Documentation/dontdiff a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
@@ -54,6 +54,7 @@ config GPIO_PCF857X
 	  some of them.  Compatible models include:
 
 	  8 bits:   pcf8574, pcf8574a, pca8574, pca8574a,
+	    	    pca9500, pca9501,
 	            pca9670, pca9672, pca9674, pca9674a,
 	  	    max7328, max7329
 

diff -uprN -X a/Documentation/dontdiff a/drivers/gpio/pcf857x.c b/drivers/gpio/pcf857x.c
@@ -29,6 +29,8 @@
 static const struct i2c_device_id pcf857x_id[] = {
 	{ "pcf8574", 8 },
 	{ "pca8574", 8 },
+	{ "pca9500", 8 },
+	{ "pca9501", 8 },
 	{ "pca9670", 8 },
 	{ "pca9672", 8 },
 	{ "pca9674", 8 },

@@ -44,9 +46,9 @@ static const struct i2c_device_id pcf857
 MODULE_DEVICE_TABLE(i2c, pcf857x_id);
 
 /*
- * The pcf857x, pca857x, and pca967x chips only expose one read and one
- * write register.  Writing a "one" bit (to match the reset state) lets
- * that pin be used as an input; it's not an open-drain model, but acts
+ * The pcf857x, pca857x, pca950x and pca967x chips only expose one read
+ * and one write register.  Writing a "one" bit (to match the reset state)
+ * lets that pin be used as an input; it's not an open-drain model, but acts
  * a bit like one.  This is described as "quasi-bidirectional"; read the
  * chip documentation for details.
  *

That is, NXP documents say it's a pcf8582 eeprom, which is software-compatible with what Linux calls a 24c02 chip.

It'd be worth sending a patch so drivers/i2c/chips/at24.c can handle those EEPROMs ...

Hmm, well I don't really see a way around having two entries in the relevant boards' i2c board info ... so this patch just ensures that *one* entry can list the actual part.

I'm curious why you added this chp to the pcf857x driver rather than to the at24 driver ... since it's quite obvious from docs that the chip is pcf8574-compatible, but only the pca9500 lists the EEPROM compatibility.

I guess given my druthers I'd update Kconfig for both drivers to mention these parts (and their need for two drivers), plus add them to the at24 driver (rather than pcf857x) purely because the docs are, overall, more clear about the GPIO compatibility than about the EEPROM.

- Dave

Right; helptext can have a sentence.

Dear David,

Thanks, hadn't realized that it was compatible with that driver. Given the approach that seems to have been taken there, is it not the case that the changes should all be in the board config anyway to support a new chip? As the board config in question isn't going to be in mainline for a while anyway (awaiting da9030 driver) this means that no such patch would be needed.

Indeed, I was merely advocating listing the actual part number so that the board config corresponds to the chips in front of the person using it. Not exactly important though as a comment explaining what is going on will do instead.

Sorry, simply wasn't aware that the at24 driver would work with it and am currently running 2.6.26 meaning it wasn't actually there. I'm cynical and tend to wait for a release candidate or two before moving to a new kernel series!

Makes a certain amount of sense but given that the at24 driver is quite specific about the use of generic chip names, whereas the pcf857x is listing devices would it not make more sense to add it there with help text explaining that eeprom is supported by the at24 driver?

Pesky dual purpose chips get in the way of nice clean naming conventions!

Indeed.

Actually that's looking to be the only bit of the patch that will be needed.

--
Jonathan