linux-kernel - Re: [RFC] i2c-algo-bit: Disable interrupts while SCL is high

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]

Date:	Mon, 20 Dec 2010 14:04:59 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Michael Lawnick <ml.lawnick@....de>
Cc:	Ben Dooks <ben-i2c@...ff.org>,
	Linux I2C <linux-i2c@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Matthias Zacharias <Matthias.Zacharias@...-solutions.de>
Subject: Re: [RFC] i2c-algo-bit: Disable interrupts while SCL is high

Michael,

On Mon, 20 Dec 2010 08:24:07 +0100, Michael Lawnick wrote:
> Jean Delvare said the following:
> > Hi Michael,
> > 
> > On Fri, 17 Dec 2010 13:09:54 +0100, Michael Lawnick wrote:
> >> Sorry to disturb, but
> >> <MANTRA>
> >> 	Disabling interrupts may be done only for a few instructions.</MANTRA>
> >> 
> >> Even 1 us is an eternity on modern systems.
> > 
> > Don't be sorry, this is exactly the kind of input I was asking for. I'm
> > a little surprised, I thought disabling interrupts for a couple
> > microseconds was happening all the time, but I'll trust your
> > experience. 
> 
> I can't tell whether this is happening all the time, but I can imagine
> and I highly discourage this. This is IMHO one of the lessons many LINUX
> developers have still to learn. Maybe it's a history reason.
> 
> > Given your point and Ben's, it seems clear that my patch is
> > not acceptable as is, and at the very least I should make the spinlock
> > usage optional.
> 
> At last you might not come around your solution, but a H/W-S/W
> combination driving you in such a direction should be considered broken.

I don't disagree, but the fact is that i2c-algo-bit is frequently used.
It's used by all framebuffer and KMS drivers which want to read the
EDID data from the screen. It's also used by a large number of V4L and
DVB drivers.

Note that, in the cases above, the current i2c-algo-bit implementation
should be OK. These are cards with I2C devices mostly, not SMBus
devices, so they are much more tolerant to slow SCL.

> Using it in professional environment needs heavy discussions about pros
> and cons, best would be to beat the H/W designers to provide a real
> controller.

For future designs, certainly. But we also have to deal with the
existing hardware.

> Of course it may be used in a case, where you simply need a (temporary)
> hack to get something working.

The problem is that "temporary" tends to stay, either because there is
no other way, or because the hardware implementation is unreliable or
limited, or because we don't have the specifications of the hardware
implementation. So I don't see i2c-algo-bit going away anytime soon.

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