<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include/asm-generic/delay.h, branch v3.4-rc2</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include/asm-generic/delay.h?h=v3.4-rc2</id>
<link rel='self' href='https://git.amat.us/linux/atom/include/asm-generic/delay.h?h=v3.4-rc2'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2011-07-22T16:45:33Z</updated>
<entry>
<title>asm-generic: delay.h fix udelay and ndelay for 8 bit args</title>
<updated>2011-07-22T16:45:33Z</updated>
<author>
<name>Andrew Morton</name>
<email>akpm@linux-foundation.org</email>
</author>
<published>2011-07-18T13:28:20Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a87e553fabe8ceadc6f90889066559234cf194c7'/>
<id>urn:sha1:a87e553fabe8ceadc6f90889066559234cf194c7</id>
<content type='text'>
With a non-constant 8-bit argument, a call to udelay() generates a warning:

drivers/gpu/drm/radeon/atom.c: In function 'atom_op_delay':
drivers/gpu/drm/radeon/atom.c:654: warning: comparison is always false due to limited range of data type

The code looks like it works OK with an 8-bit arg, and the calling code is
doing nothing wrong, so udelay() needs fixing.

Fixing it was rather tricky.  Simply typecasting `n' in the comparison with
20000 didn't change anything.  Hence the divide-by-20000 trick.

Using a do{}while loop didn't work because udelay() is used in ?: statements,
hence the ({...}) construct.

While I was there I replaced the brain-bending ?:?:?: mess with nice if/else
code.

Probably other architectures are generating the same warning and can use a
similar change.

[Taken from the x86 tree and moved to asm-generic by Jonas Bonn]

Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: &lt;linux-arch@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Jonas Bonn &lt;jonas@southpole.se&gt;
</content>
</entry>
<entry>
<title>asm-generic: adapt delay.h to common implementation</title>
<updated>2011-07-07T18:11:39Z</updated>
<author>
<name>Jonas Bonn</name>
<email>jonas@southpole.se</email>
</author>
<published>2011-07-02T08:29:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=30ab2b034fa87472d700f584e277e3aeb7a84d2c'/>
<id>urn:sha1:30ab2b034fa87472d700f584e277e3aeb7a84d2c</id>
<content type='text'>
Several architectures are using a common delay.h implementation that
appears to have originated with the x86 architecture.  This common
implementation is a bit fuller than the current asm-generic version
and has some compile-time checks that should be interesting for all
architectures.

This patch takes the common delay.h version and replaces the rather
trivial asm-generic version with it.  As no architecture was actually
using asm-generic/delay.h, this change is rather innocuous; it will,
however, allow us to switch at least four architectures over to using
the asm-generic version.

Signed-off-by: Jonas Bonn &lt;jonas@southpole.se&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
</entry>
<entry>
<title>asm-generic: add generic versions of common headers</title>
<updated>2009-06-11T19:02:37Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2009-05-13T22:56:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=aafe4dbed0bf6cbdb2e9f03e1d42f8a540d8541d'/>
<id>urn:sha1:aafe4dbed0bf6cbdb2e9f03e1d42f8a540d8541d</id>
<content type='text'>
These are all kernel internal interfaces that get copied
around a lot. In most cases, architectures can provide
their own optimized versions, but these generic versions
can work as well.

I have tried to use the most common contents of each
header to allow existing architectures to migrate easily.

Thanks to Remis for suggesting a number of cleanups.

Signed-off-by: Remis Lima Baima &lt;remis.developer@googlemail.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
</entry>
</feed>
