linux-kernel - Re: [PATCH] OMAP: MMC: recover from transfer failures

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:	Thu, 5 Feb 2009 13:32:03 -0700 (MST)
From:	Paul Walmsley <paul@...an.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Jean Pihet <jpihet@...sta.com>, tony@...mide.com,
	ext-adrian.hunter@...ia.com,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-omap@...r.kernel.org, jarkko.lavinen@...ia.com,
	drzeus-mmc@...eus.cx, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] OMAP: MMC: recover from transfer failures - Resend

On Thu, 5 Feb 2009, Andrew Morton wrote:

> On Tue, 3 Feb 2009 15:05:58 +0100
> Jean Pihet <jpihet@...sta.com> wrote:
> 
> > +	while (OMAP_HSMMC_READ(host->base,
> > + 			SYSCTL) & SRD)
> > + 		;
> 
> Is a __raw_readl() sufficient to prevent the cpu from burning up here,
> or should we add cpu_relax()?

The __raw_readl() should be sufficient.  The MMC controller is located on 
the L4 CORE interconnect, so the round trip latency for the read from MMC 
is at least 90 ns, while the CPU cycle time is only about 1 to 2 ns.

> An infinite loop which assumes the hardware is perfect is always a
> worry.  But I see the driver already does that, so we're no worse off..


- Paul

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