Re: [PATCH] Disintegrate asm/system.h for Unicore32 [based on ver #3, changed by gxt]

From: David Howells
Date: Tue Mar 20 2012 - 05:34:01 EST


Guan Xuetao <gxt@xxxxxxxxxxxxxxx> wrote:

> Disintegrate asm/system.h for Unicore32. (Compilation successful)
> The implementation details are not changed, but only splitted.
> BTW, some codestyles are adjusted.
>
> Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
> Signed-off-by: Guan Xuetao <gxt@xxxxxxxxxxxxxxx>

Aha! Much better. It mostly looks reasonable, apart from one thing. See the
attached patch, which I'll roll in if you're happy with it.

David
---
From: David Howells <dhowells@xxxxxxxxxx>
Subject: [PATCH] Fix unicore xchg() to fail at build time with an unsupported pointer

Fix unicore xchg() to fail at build time with an unsupported pointer rather
then using panic().

Additionally, panic() should not be redeclared in this manner, but rather
should be brought in by #inclusion of <linux/kernel.h>.

Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
---

arch/unicore32/include/asm/cmpxchg.h | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)


diff --git a/arch/unicore32/include/asm/cmpxchg.h b/arch/unicore32/include/asm/cmpxchg.h
index 37c431d..f39a59d 100644
--- a/arch/unicore32/include/asm/cmpxchg.h
+++ b/arch/unicore32/include/asm/cmpxchg.h
@@ -10,7 +10,11 @@
#ifndef __UNICORE_CMPXCHG_H__
#define __UNICORE_CMPXCHG_H__

-extern void panic(const char *fmt, ...);
+/*
+ * Generate a link failure on undefined symbol if the pointer points to a value
+ * of unsupported size.
+ */
+extern void __xchg_bad_pointer(void)

static inline unsigned long __xchg(unsigned long x, volatile void *ptr,
int size)
@@ -31,8 +35,8 @@ static inline unsigned long __xchg(unsigned long x, volatile void *ptr,
: "memory", "cc");
break;
default:
- panic("xchg: bad data size: ptr 0x%p, size %d\n",
- ptr, size);
+ __xchg_bad_pointer();
+ break;
}

return ret;

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