From: Harvey Harrison <harvey.harrison@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Chris Zankel <chris@zankel.net>
Subject: [PATCH 11/23] xtensa: introduce asm/swab.h
Date: Tue, 06 Jan 2009 13:30:51 -0800 [thread overview]
Message-ID: <1231277451.964.268.camel@brick> (raw)
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
arch/xtensa/include/asm/Kbuild | 2 +
arch/xtensa/include/asm/byteorder.h | 72 +---------------------------------
arch/xtensa/include/asm/swab.h | 70 ++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 69 deletions(-)
diff --git a/arch/xtensa/include/asm/Kbuild b/arch/xtensa/include/asm/Kbuild
index c68e168..58c02a4 100644
--- a/arch/xtensa/include/asm/Kbuild
+++ b/arch/xtensa/include/asm/Kbuild
@@ -1 +1,3 @@
include include/asm-generic/Kbuild.asm
+
+unifdef-y += swab.h
diff --git a/arch/xtensa/include/asm/byteorder.h b/arch/xtensa/include/asm/byteorder.h
index 07d10ad..329b945 100644
--- a/arch/xtensa/include/asm/byteorder.h
+++ b/arch/xtensa/include/asm/byteorder.h
@@ -1,80 +1,14 @@
-/*
- * include/asm-xtensa/byteorder.h
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 2001 - 2005 Tensilica Inc.
- */
-
#ifndef _XTENSA_BYTEORDER_H
#define _XTENSA_BYTEORDER_H
-#include <asm/types.h>
-#include <linux/compiler.h>
+#include <asm/swab.h>
#ifdef __XTENSA_EL__
-# define __LITTLE_ENDIAN
+#include <linux/byteorder/little_endian.h>
#elif defined(__XTENSA_EB__)
-# define __BIG_ENDIAN
+#include <linux/byteorder/big_endian.h>
#else
# error processor byte order undefined!
#endif
-#define __SWAB_64_THRU_32__
-
-static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
-{
- __u32 res;
- /* instruction sequence from Xtensa ISA release 2/2000 */
- __asm__("ssai 8 \n\t"
- "srli %0, %1, 16 \n\t"
- "src %0, %0, %1 \n\t"
- "src %0, %0, %0 \n\t"
- "src %0, %1, %0 \n"
- : "=&a" (res)
- : "a" (x)
- );
- return res;
-}
-#define __arch_swab32 __arch_swab32
-
-static inline __attribute_const__ __u16 __arch_swab16(__u16 x)
-{
- /* Given that 'short' values are signed (i.e., can be negative),
- * we cannot assume that the upper 16-bits of the register are
- * zero. We are careful to mask values after shifting.
- */
-
- /* There exists an anomaly between xt-gcc and xt-xcc. xt-gcc
- * inserts an extui instruction after putting this function inline
- * to ensure that it uses only the least-significant 16 bits of
- * the result. xt-xcc doesn't use an extui, but assumes the
- * __asm__ macro follows convention that the upper 16 bits of an
- * 'unsigned short' result are still zero. This macro doesn't
- * follow convention; indeed, it leaves garbage in the upport 16
- * bits of the register.
-
- * Declaring the temporary variables 'res' and 'tmp' to be 32-bit
- * types while the return type of the function is a 16-bit type
- * forces both compilers to insert exactly one extui instruction
- * (or equivalent) to mask off the upper 16 bits. */
-
- __u32 res;
- __u32 tmp;
-
- __asm__("extui %1, %2, 8, 8\n\t"
- "slli %0, %2, 8 \n\t"
- "or %0, %0, %1 \n"
- : "=&a" (res), "=&a" (tmp)
- : "a" (x)
- );
-
- return res;
-}
-#define __arch_swab16 __arch_swab16
-
-#include <linux/byteorder.h>
-
#endif /* _XTENSA_BYTEORDER_H */
diff --git a/arch/xtensa/include/asm/swab.h b/arch/xtensa/include/asm/swab.h
new file mode 100644
index 0000000..f50b697
--- /dev/null
+++ b/arch/xtensa/include/asm/swab.h
@@ -0,0 +1,70 @@
+/*
+ * include/asm-xtensa/swab.h
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2001 - 2005 Tensilica Inc.
+ */
+
+#ifndef _XTENSA_SWAB_H
+#define _XTENSA_SWAB_H
+
+#include <asm/types.h>
+#include <linux/compiler.h>
+
+#define __SWAB_64_THRU_32__
+
+static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
+{
+ __u32 res;
+ /* instruction sequence from Xtensa ISA release 2/2000 */
+ __asm__("ssai 8 \n\t"
+ "srli %0, %1, 16 \n\t"
+ "src %0, %0, %1 \n\t"
+ "src %0, %0, %0 \n\t"
+ "src %0, %1, %0 \n"
+ : "=&a" (res)
+ : "a" (x)
+ );
+ return res;
+}
+#define __arch_swab32 __arch_swab32
+
+static inline __attribute_const__ __u16 __arch_swab16(__u16 x)
+{
+ /* Given that 'short' values are signed (i.e., can be negative),
+ * we cannot assume that the upper 16-bits of the register are
+ * zero. We are careful to mask values after shifting.
+ */
+
+ /* There exists an anomaly between xt-gcc and xt-xcc. xt-gcc
+ * inserts an extui instruction after putting this function inline
+ * to ensure that it uses only the least-significant 16 bits of
+ * the result. xt-xcc doesn't use an extui, but assumes the
+ * __asm__ macro follows convention that the upper 16 bits of an
+ * 'unsigned short' result are still zero. This macro doesn't
+ * follow convention; indeed, it leaves garbage in the upport 16
+ * bits of the register.
+
+ * Declaring the temporary variables 'res' and 'tmp' to be 32-bit
+ * types while the return type of the function is a 16-bit type
+ * forces both compilers to insert exactly one extui instruction
+ * (or equivalent) to mask off the upper 16 bits. */
+
+ __u32 res;
+ __u32 tmp;
+
+ __asm__("extui %1, %2, 8, 8\n\t"
+ "slli %0, %2, 8 \n\t"
+ "or %0, %0, %1 \n"
+ : "=&a" (res), "=&a" (tmp)
+ : "a" (x)
+ );
+
+ return res;
+}
+#define __arch_swab16 __arch_swab16
+
+#endif /* _XTENSA_SWAB_H */
--
1.6.1.94.g9388
reply other threads:[~2009-01-06 21:35 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=1231277451.964.268.camel@brick \
--to=harvey.harrison@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chris@zankel.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.