From: akpm@linux-foundation.org
To: mingo@elte.hu
Cc: hpa@zytor.com, tglx@linutronix.de, akpm@linux-foundation.org,
linux-arch@vger.kernel.org
Subject: [patch 1/4] arch/x86/include/asm/delay.h: fix udelay() and ndelay() for 8-bit args
Date: Mon, 23 May 2011 14:47:00 -0700 [thread overview]
Message-ID: <201105232147.p4NLl0ti013960@imap1.linux-foundation.org> (raw)
From: Andrew Morton <akpm@linux-foundation.org>
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.
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/include/asm/delay.h | 33 +++++++++++++++++++++++++++------
1 file changed, 27 insertions(+), 6 deletions(-)
diff -puN arch/x86/include/asm/delay.h~arch-x86-include-asm-delayh-fix-udelay-and-ndelay-for-8-bit-args arch/x86/include/asm/delay.h
--- a/arch/x86/include/asm/delay.h~arch-x86-include-asm-delayh-fix-udelay-and-ndelay-for-8-bit-args
+++ a/arch/x86/include/asm/delay.h
@@ -16,15 +16,36 @@ extern void __ndelay(unsigned long nsecs
extern void __const_udelay(unsigned long xloops);
extern void __delay(unsigned long loops);
+/*
+ * The weird n/20000 thing suppresses a "comparison is always false due to
+ * limited range of data type" warning with non-const 8-bit arguments.
+ */
+
/* 0x10c7 is 2**32 / 1000000 (rounded up) */
-#define udelay(n) (__builtin_constant_p(n) ? \
- ((n) > 20000 ? __bad_udelay() : __const_udelay((n) * 0x10c7ul)) : \
- __udelay(n))
+#define udelay(n) \
+ ({ \
+ if (__builtin_constant_p(n)) { \
+ if ((n) / 20000 >= 1) \
+ __bad_udelay(); \
+ else \
+ __const_udelay((n) * 0x10c7ul); \
+ } else { \
+ __udelay(n); \
+ } \
+ })
/* 0x5 is 2**32 / 1000000000 (rounded up) */
-#define ndelay(n) (__builtin_constant_p(n) ? \
- ((n) > 20000 ? __bad_ndelay() : __const_udelay((n) * 5ul)) : \
- __ndelay(n))
+#define ndelay(n) \
+ ({ \
+ if (__builtin_constant_p(n)) { \
+ if ((n) / 20000 >= 1) \
+ __bad_ndelay(); \
+ else \
+ __const_udelay((n) * 5ul); \
+ } else { \
+ __ndelay(n); \
+ } \
+ })
void use_tsc_delay(void);
_
reply other threads:[~2011-05-23 21:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201105232147.p4NLl0ti013960@imap1.linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-arch@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).