[tip:x86/cleanups] x86: Use "do { } while(0)" for empty lock_cmos()/unlock_cmos() macros

[tip-bot for Jesper Juhl]

Commit-ID:  1affc46cffad9f2bc7c9ffec85726446903a58f9
Gitweb:     http://git.kernel.org/tip/1affc46cffad9f2bc7c9ffec85726446903a58f9
Author:     Jesper Juhl <jj@xxxxxxxxxxxxx>
AuthorDate: Sun, 18 Dec 2011 01:05:31 +0100
Committer:  Ingo Molnar <mingo@xxxxxxx>
CommitDate: Sun, 18 Dec 2011 09:14:31 +0100

x86: Use "do { } while(0)" for empty lock_cmos()/unlock_cmos() macros

gcc noticed (when using -Wempty-body) that our use of
lock_cmos() and unlock_cmos() in
arch/x86/include/asm/mach_traps.h is potentially problematic :

  arch/x86/include/asm/mach_traps.h:32:15: warning: suggest braces around empty body in an Âelse statement [-Wempty-body]
  arch/x86/include/asm/mach_traps.h:40:16: warning: suggest braces around empty body in an Âelse statement [-Wempty-body]

Let's just use the standard 'do {} while (0)' solution. That
shuts up gcc and also prevents future problems if the macros
should end up being used in a similar situation elsewhere.

Signed-off-by: Jesper Juhl <jj@xxxxxxxxxxxxx>
Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1112180103130.21784@xxxxxxxxxxxxxxxxxxxxxxxxx
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
---
 arch/x86/include/asm/mc146818rtc.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/mc146818rtc.h b/arch/x86/include/asm/mc146818rtc.h
index 01fdf56..0e8e85b 100644
--- a/arch/x86/include/asm/mc146818rtc.h
+++ b/arch/x86/include/asm/mc146818rtc.h
@@ -81,8 +81,8 @@ static inline unsigned char current_lock_cmos_reg(void)
 #else
 #define lock_cmos_prefix(reg) do {} while (0)
 #define lock_cmos_suffix(reg) do {} while (0)
-#define lock_cmos(reg)
-#define unlock_cmos()
+#define lock_cmos(reg) do { } while (0)
+#define unlock_cmos() do { } while (0)
 #define do_i_have_lock_cmos() 0
 #define current_lock_cmos_reg() 0
 #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/