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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGS+omByuSWzV1Pa_ODugq9rrZ2DtgU_LPWDAfbrR_q_zuDvYQ@mail.gmail.com>
Date:	Wed, 7 Mar 2012 20:41:03 +0800
From:	Daniel Kurtz <djkurtz@...omium.org>
To:	Chris Wilson <chris@...is-wilson.co.uk>
Cc:	Keith Packard <keithp@...thp.com>, David Airlie <airlied@...ux.ie>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	Benson Leung <bleung@...omium.org>,
	Yufeng Shen <miletus@...omium.org>,
	Sameer Nanda <snanda@...omium.org>
Subject: Re: [PATCH 6/9] drm/i915/intel_i2c: return -ENXIO for device NAK

On Wed, Mar 7, 2012 at 8:12 PM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> On Wed,  7 Mar 2012 19:50:47 +0800, Daniel Kurtz <djkurtz@...omium.org> 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@...omium.org>
>
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/