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-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
