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] [day] [month] [year] [list]

Message-ID: <62697B07E9803846BC582181BD6FB6B835EFD27D1C@NOK-EUMSG-02.mgdnok.nokia.com>
Date:	Mon, 18 Oct 2010 11:38:44 +0200
From:	<samu.p.onkalo@...ia.com>
To:	<samu.p.onkalo@...ia.com>, <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: linux-i2c-owner@...r.kernel.org [mailto:linux-i2c-
>owner@...r.kernel.org] On Behalf Of ext samu.p.onkalo@...ia.com


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

It seems that controller detects bus free condition when this happens.
So, instead of the timeout, bus free condition should be detected.
There is no such interrupt so this must be done by polling
the status register. In general this is not a good idea.

Would it make sense somehow tell that use polling and not
the interrupt / timeout control? I.e. by setting a flag that
this transfer doesn't end properly.

I2C_M_IGNORE_TIMEOUT?
In such case just either wait for bus free if supported by HW or
wait for some short time after start of the transmission

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