linux-kernel - Re: [PATCH 04/17] i2c: omap: simplify omap_i2c_ack

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: <20120614114546.GP13602@arwen.pp.htv.fi>
Date:	Thu, 14 Jun 2012 14:45:50 +0300
From:	Felipe Balbi <balbi@...com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Felipe Balbi <balbi@...com>, ben-linux@...ff.org,
	Tony Lindgren <tony@...mide.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	w.sang@...gutronix.de, linux-i2c@...r.kernel.org,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux ARM Kernel Mailing List 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 04/17] i2c: omap: simplify omap_i2c_ack_stat()

Hi,

On Thu, Jun 14, 2012 at 12:13:33PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 14, 2012 at 01:20:37PM +0300, Felipe Balbi wrote:
> > stat & BIT(1) is the same as BIT(1), so let's
> > simplify things a bit by removing "stat &" from
> > all omap_i2c_ack_stat() calls.
> 
> This doesn't feel right, and the explanation is definitely wrong.
> 
> "stat & BIT(1)" is not the same as "BIT(1)" _unless_ you're saying that
> stat always has BIT(1) already set.  Can you guarantee that in this code?
> If so, how?
> 
> What happens if you read the status register, and it has bit 1 clear.
> immediately after the read, the status register bit 1 becomes set, and
> then you write bit 1 set (because you've dropped the stat & BIT(1) from
> the code.)
> 
> Is it not going to acknowledge that bit-1-set but because you haven't
> read it, you're going to miss that event?
> 
> This feels like a buggy change to me.

I fail to see that situation would happen with this driver. See what it
does (extremely simplified):

if (stat & NACK) {
	...
	omap_i2c_ack_stat(dev, stat & NACK);
}

if (stat & RDR) {
	...
	omap_i2c_ack_stat(dev, stat & RDR);
}

and so on. The tricky place is only WRT errata handling, for example:

if (*stat & (NACK | AL)) {
	omap_i2c_ack_stat(dev, *stat & (XRDY | XDR));
	...
}

but in this case, the errata says we must clear XRDY and XDR if that
errata triggers, so if they just got enabled or not, it doesn't matter.

Another tricky place is RDR | RRDY (likewise for XDR | XRDY):

if (stat & (RDR | RRDY)) {
	...
	omap_i2c_ack_stat(dev, stat & (RDR | RRDY));
}

again here there will be no issues because those IRQs never fire
simultaneously and one will only after after we have handled the
previous, that's because the same FIFO is used anyway and we won't shift
data into FIFO until we tell the IP "hey, I'm done with the FIFO, you
can shift more data". Right ?

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)