Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

[David Brownell]

On Monday 29 December 2008, Jamie Lokier wrote:
> David Brownell wrote:
> > The reason single-bit operations don't provide error paths is twofold.
> > First, they started as wrappers for can't-fail register accessors.
> > Second, it's extremely unrealisitic to expect much code to handle any
> > kind of faults in the middle of bitbanging loops ... or even just in
> > classic "set this bit and continue" configuration code.
> 
> That's interesting.  I'm not sure it's a good idea not to return an
> error code.  The caller can just ignore it if they don't care, and
> it's extremely cheap to "return 0" in GPIO drivers which can't error.

I'm not sure either; at this point I *might* consider doing
it differently -- but primarily for the case of external GPIO
chips, e.g. over I2C or SPI -- where errors are realistic.  But
it's been this way for a few years now, and changing stuff
that hasn't been observed to be a problem isn't on my list.

But as I noted:  patches for $SUBJECT don't seem to have any
reason not to report whatever faults they encounter.

Also worth remembering:  when reading a GPIO value, it's not
so easy to "ignore" a tristate (0, 1, error) return value.

 
> If I were bit-banging on GPIOs reached via some peripheral chip (such
> a GPIO-fanout chip over I2C/SPI, where that chip is itself feeding a
> secondary I2C or similar bit-banging bus), I probably would like to
> check for errors and take emergency action if the peripheral chip
> isn't responding, or just report to userspace.

If I had to do that, I'd *certainly* want to bang the hardware
designer over the head with some sort of cluebat or cluebrick.  :(


> This has actually happened on a board I worked with, where the primary
> I2C failed due to a plugged in peripheral loading it too much, and a
> secondary bit-banging bus was not then reachable.

It should now be realistic for I2C device drivers to have
fault recovery logic...

But for a long time, I2c only returned -EPERM so it was
completely hopeless trying to figure out how to "handle"
any problem beyond logging the problem and hoping someone
is watching syslog output.  That's a big part of why most
current I2C drivers have such unfriendly fault handling.

- Dave



> 
> -- Jamie
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/