[i2c] [patch 2.6.23.1, version 4] add support for the PCF8575 chip

David Brownell david-b at pacbell.net
Fri Oct 26 23:40:12 CEST 2007


No comment on switching to be a "new style" driver and thus
getting past all those silly probe and driver parameter issues?


On Friday 26 October 2007, Bart Van Assche wrote:
> Even if you are used to see PCF857x chips being used with all pins in
> output mode, this doesn't mean that these chips are always used with
> all pins in output mode. In the context I'm familiar with the I/O pins
> of the PCF8575 are used as inputs.

The point was more that other kernel code needs to have full
access to the signals -- not that they're outputs.  Even when
they are used as inputs, other kernel code can need access.

Re why outputs ... usually there isn't a real shortage of GPIOs,
and the SOC at the heart of a system has plenty left unused.
The expander chips get used because they can sink or source at
least ten times more current than GPIOs from those main chips.

Obviously chips in smaller packages (QFP-100 vs BGA-400) will
not have so many GPIOs available; but that doesn't affect the
point that other kernel code can need access to the GPIOs.
 

> Regarding the sysfs interface: the sysfs interface for the pcf8575
> driver is consistent with that of the pcf8574 driver, so why do you
> call this interface strange ? Furthermore, you don't have to use the
> sysfs interface -- you can still call read() and write() from C/C++
> code on the device node corresponding with the chip you want to
> address.

Well, one little hint is that I've seen at least three or four
different pcf8574 drivers.  They haven't gone upstream since that
strange one is there.  Those other drivers are all ugly board
specific hacks ... but they address a critical issue which that
existing sysfs-oriented one doesn't.

The essential thing those other drivers have in common is critically
important, and can't be done with just a sysfs interface:  they give
other kernel code full access to those GPIO signals.


> Regarding gluing these chips into the generic GPIO framework: what is
> the benefit of adding additional complexity to the kernel for the GPIO
> integration ? In the context I know of it is perfectly valid to make
> the association between I/O pins and PCF857x chip address in
> userspace.

I don't know what you mean by "valid"; I'd agree to "possible"
but not, on *ANY* board I've worked with using such expanders,
anything approaching "useful".  (With the possible exception
of driving LEDs, which kernel code can still need to do...)

See above:  other kernel code needs to access those GPIOs.


> By the way, how well has your patch been tested/reviewed ?

Referring to a patch I sent off-list as an "FYI" with the
note that it was untested because the hardware setup I was
planning to use got borked, and I hadn't yet made time to
switch to a differnt one.


> The 
> following statement looks strange to me ( "== 0" is probably missing
> after the first strcmp() -- I copied the code below from the previous
> mail you sent to the i2c mailing list):
> 
> +       /* '75/'75c addresses are 0x20..0x27, just like the '74 */
> +       } else if (strcmp(client->name, "pcf8575c")
> +                       || strcmp(client->name, "pcf8575") == 0) {

Well, as I said in the *off-list* post:  not tested, since
the intended test hardware was borked.  When I get around to
it, I have other boards which will also work for testing.

And yes, I expect that little bug would have turned up quickly.
The 8-bit code paths didn't have that glitch.  :)

- Dave



More information about the i2c mailing list