linux-kernel - RE: [PATCH 0/2] Short timeout for I2C transfers

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: <62697B07E9803846BC582181BD6FB6B835EFD27C35@NOK-EUMSG-02.mgdnok.nokia.com>
Date:	Mon, 18 Oct 2010 10:48:00 +0200
From:	<samu.p.onkalo@...ia.com>
To:	<khali@...ux-fr.org>
CC:	<tony@...mide.com>, <linux-i2c@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/2] Short timeout for I2C transfers



>-----Original Message-----
>From: ext Jean Delvare [mailto:khali@...ux-fr.org]
>Sent: 15 October, 2010 15:52
>To: Onkalo Samu.P (Nokia-MS/Tampere)
>Cc: tony@...mide.com; linux-i2c@...r.kernel.org; linux-
>kernel@...r.kernel.org
>Subject: Re: [PATCH 0/2] Short timeout for I2C transfers
>
>Hi Samu,
>
>On Wed, 13 Oct 2010 16:45:08 +0300, Samu Onkalo wrote:
>> There are chips which doesn't work perfectly in certain
>> I2C operations. For example lp5523 led driver chip causes
>> always I2C timeout when SW reset is commanded to the chip.
>
>The timeout is a symptom as the controller level. What is the root
>cause at the LP5523 device level? What exactly happens on the wire?
>

Chip seems to release ACK signal too soon causing rising edge while
SCL is high. This violates bus protocol and causes timeout at the
controller. It is no recognized as ACK nor NACK.

>I am asking because maybe some of the already available protocol
>mangling flags would work for you, in particular I2C_M_IGNORE_NAK. See
>Documentation/i2c/i2c-protocol.
>
>> Patches add a possibility to tell that this access is likely
>> to cause time out and there is no need to wait normal time.
>> For example in omap time out is 1 second and the bus is reserved
>> all the time.
>
>You should ask yourself whether a 1 second timeout is a sane thing to
>have in the first place.

hmm.. 1 second is quite long time out for i2c.

>
>You should also check why you hit the timeout condition. Ideally the
>hardware would report problems as they happen, quickly, rather than
>having to rely on the driver's timeout mechanism. The timeout should
>really only be a safety mechanism, for when the bus controller itself
>misbehaves at the hardware level.
>
>> By setting I2C_M_SHORT_TIMEOUT flag to i2c-message, adapter is
>> requested to use shorter timeout.
>>
>> Samu Onkalo (2):
>>   drivers: i2c-core: Add a flag to allow short timeout
>>   drivers: i2c-omap: Add support for shorten I2C timeout
>>
>>  drivers/i2c/busses/i2c-omap.c |    9 ++++++++-
>>  drivers/i2c/i2c-core.c        |    2 +-
>>  include/linux/i2c.h           |    1 +
>>  3 files changed, 10 insertions(+), 2 deletions(-)
>
>I'm skeptical. If you know that the transfer will "fail" and you don't
>care, why do you want to wait a short time, rather than not waiting at
>all?

Well, at least some time should be spend to allow bits to go out.
Maybe controller provides something for that.

-Samu

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