| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 06 Jan 2009 13:30:51 -0800
From: Harvey Harrison <harvey.harrison@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Chris Zankel <chris@...kel.net>
Subject: [PATCH 11/23] xtensa: introduce asm/swab.h
Signed-off-by: Harvey Harrison <harvey.harrison@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists