Re: [PATCH 6/9] drm/i915/intel_i2c: return -ENXIO for device NAK

From: Daniel Kurtz
Date: Wed Mar 07 2012 - 07:41:31 EST


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
--
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/