On Wed, Mar 7, 2012 at 8:12 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > On Wed, 7 Mar 2012 19:50:47 +0800, Daniel Kurtz <djkurtz@xxxxxxxxxxxx> wrote: >> Return -ENXIO if a device NAKs a transaction. >> >> Note: We should return -ETIMEDOUT, too if the transaction times out, >> however, that error path is currently handled by the 'bit-bang fallback'. >> >> Signed-off-by: Daniel Kurtz <djkurtz@xxxxxxxxxxxx> > > Can you clarify what the rule is if an error is detected part-way > through a xfer? A priceless comment from drivers/i2c/i2c-core::i2c_transfer... /* REVISIT the fault reporting model here is weak: * * - When we get an error after receiving N bytes from a slave, * there is no way to report "N". * * - When we get a NAK after transmitting N bytes to a slave, * there is no way to report "N" ... or to let the master * continue executing the rest of this combined message, if * that's the appropriate response. * * - When for example "num" is two and we successfully complete * the first message but get an error part way through the * second, it's unclear whether that should be reported as * one (discarding status on the second message) or errno * (discarding status on the first one). */ As for which error code to use, all I have found is this: Documentation/i2c/fault-codes: ENXIO Returned by I2C adapters to indicate that the address phase of a transfer didn't get an ACK. While it might just mean an I2C device was temporarily not responding, usually it means there's nothing listening at that address. This doesn't specify what to do if the transfer doesn't get an ACK during another phase of the transfer. However, it does say to send -ENXIO "if no ACK during address phase", which is a subset of the possible no-ACK conditions during a transfer. Thus, I choose to return ENXIO in all no-ACK cases, to ensure we send it during the one case that is specified. For different i2c adapters i've seen wildly different behavior: -ENXIO (i2c-algo-pca) -EIO (i2c-algo-bit) -EREMOTEIO (i2c-algo-pcf). -Dan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
