Messages in this thread | | | From | David Brownell <> | Subject | Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins | Date | Mon, 29 Dec 2008 16:43:03 -0800 |
| |
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 > >
| |