cris holds its arch overrides in an arch/ folder, rename these
byteorder.h files to swab.h and include them from asm/swab.h
Signed-off-by: Harvey Harrison <[email protected]>
---
arch/cris/include/arch-v10/arch/byteorder.h | 28 ---------------------------
arch/cris/include/arch-v10/arch/swab.h | 28 +++++++++++++++++++++++++++
arch/cris/include/arch-v32/arch/byteorder.h | 22 ---------------------
arch/cris/include/arch-v32/arch/swab.h | 22 +++++++++++++++++++++
arch/cris/include/asm/Kbuild | 1 +
arch/cris/include/asm/byteorder.h | 10 +-------
arch/cris/include/asm/swab.h | 12 +++++++++++
7 files changed, 65 insertions(+), 58 deletions(-)
diff --git a/arch/cris/include/arch-v10/arch/byteorder.h b/arch/cris/include/arch-v10/arch/byteorder.h
deleted file mode 100644
index ffbd667..0000000
--- a/arch/cris/include/arch-v10/arch/byteorder.h
+++ /dev/null
@@ -1,28 +0,0 @@
-#ifndef _CRIS_ARCH_BYTEORDER_H
-#define _CRIS_ARCH_BYTEORDER_H
-
-#include <asm/types.h>
-#include <linux/compiler.h>
-
-/* we just define these two (as we can do the swap in a single
- * asm instruction in CRIS) and the arch-independent files will put
- * them together into ntohl etc.
- */
-
-static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
-{
- __asm__ ("swapwb %0" : "=r" (x) : "0" (x));
-
- return(x);
-}
-#define __arch_swab32 __arch_swab32
-
-static inline __attribute_const__ __u16 __arch_swab16(__u16 x)
-{
- __asm__ ("swapb %0" : "=r" (x) : "0" (x));
-
- return(x);
-}
-#define __arch_swab16 __arch_swab16
-
-#endif
diff --git a/arch/cris/include/arch-v10/arch/swab.h b/arch/cris/include/arch-v10/arch/swab.h
new file mode 100644
index 0000000..3eb0993
--- /dev/null
+++ b/arch/cris/include/arch-v10/arch/swab.h
@@ -0,0 +1,28 @@
+#ifndef _CRIS_ARCH_SWAB_H
+#define _CRIS_ARCH_SWAB_H
+
+#include <asm/types.h>
+#include <linux/compiler.h>
+
+/* we just define these two (as we can do the swap in a single
+ * asm instruction in CRIS) and the arch-independent files will put
+ * them together into ntohl etc.
+ */
+
+static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
+{
+ __asm__ ("swapwb %0" : "=r" (x) : "0" (x));
+
+ return(x);
+}
+#define __arch_swab32 __arch_swab32
+
+static inline __attribute_const__ __u16 __arch_swab16(__u16 x)
+{
+ __asm__ ("swapb %0" : "=r" (x) : "0" (x));
+
+ return(x);
+}
+#define __arch_swab16 __arch_swab16
+
+#endif
diff --git a/arch/cris/include/arch-v32/arch/byteorder.h b/arch/cris/include/arch-v32/arch/byteorder.h
deleted file mode 100644
index fb76087..0000000
--- a/arch/cris/include/arch-v32/arch/byteorder.h
+++ /dev/null
@@ -1,22 +0,0 @@
-#ifndef _ASM_CRIS_ARCH_BYTEORDER_H
-#define _ASM_CRIS_ARCH_BYTEORDER_H
-
-#include <asm/types.h>
-
-static inline __const__ __u32
-__arch_swab32(__u32 x)
-{
- __asm__ __volatile__ ("swapwb %0" : "=r" (x) : "0" (x));
- return (x);
-}
-#define __arch_swab32 __arch_swab32
-
-static inline __const__ __u16
-__arch_swab16(__u16 x)
-{
- __asm__ __volatile__ ("swapb %0" : "=r" (x) : "0" (x));
- return (x);
-}
-#define __arch_swab16 __arch_swab16
-
-#endif /* _ASM_CRIS_ARCH_BYTEORDER_H */
diff --git a/arch/cris/include/arch-v32/arch/swab.h b/arch/cris/include/arch-v32/arch/swab.h
new file mode 100644
index 0000000..ed1f280
--- /dev/null
+++ b/arch/cris/include/arch-v32/arch/swab.h
@@ -0,0 +1,22 @@
+#ifndef _ASM_CRIS_ARCH_SWAB_H
+#define _ASM_CRIS_ARCH_SWAB_H
+
+#include <asm/types.h>
+
+static inline __const__ __u32
+__arch_swab32(__u32 x)
+{
+ __asm__ __volatile__ ("swapwb %0" : "=r" (x) : "0" (x));
+ return (x);
+}
+#define __arch_swab32 __arch_swab32
+
+static inline __const__ __u16
+__arch_swab16(__u16 x)
+{
+ __asm__ __volatile__ ("swapb %0" : "=r" (x) : "0" (x));
+ return (x);
+}
+#define __arch_swab16 __arch_swab16
+
+#endif /* _ASM_CRIS_ARCH_SWAB_H */
diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild
index d5b6319..b79b7c6 100644
--- a/arch/cris/include/asm/Kbuild
+++ b/arch/cris/include/asm/Kbuild
@@ -9,3 +9,4 @@ header-y += sync_serial.h
unifdef-y += etraxgpio.h
unifdef-y += rs485.h
+unifdef-y += swab.h
diff --git a/arch/cris/include/asm/byteorder.h b/arch/cris/include/asm/byteorder.h
index 420c030..7678d86 100644
--- a/arch/cris/include/asm/byteorder.h
+++ b/arch/cris/include/asm/byteorder.h
@@ -1,14 +1,8 @@
#ifndef _CRIS_BYTEORDER_H
#define _CRIS_BYTEORDER_H
-#define __LITTLE_ENDIAN
-#define __SWAB_64_THRU_32__
-
-#ifdef __KERNEL__
-# include <arch/byteorder.h>
-#endif
-
-#include <linux/byteorder.h>
+#include <asm/swab.h>
+#include <linux/byteorder/little_endian.h>
#endif
diff --git a/arch/cris/include/asm/swab.h b/arch/cris/include/asm/swab.h
new file mode 100644
index 0000000..9a0ad25
--- /dev/null
+++ b/arch/cris/include/asm/swab.h
@@ -0,0 +1,12 @@
+#ifndef _CRIS_SWAB_H
+#define _CRIS_SWAB_H
+
+#define __SWAB_64_THRU_32__
+
+#ifdef __KERNEL__
+# include <arch/swab.h>
+#endif
+
+#endif
+
+
--
1.6.1.94.g9388
On Tue, 6 Jan 2009, Harvey Harrison wrote:
>
> cris holds its arch overrides in an arch/ folder, rename these
> byteorder.h files to swab.h and include them from asm/swab.h
>
> Signed-off-by: Harvey Harrison <[email protected]>
> ---
> arch/cris/include/arch-v10/arch/byteorder.h | 28 ---------------------------
> arch/cris/include/arch-v10/arch/swab.h | 28 +++++++++++++++++++++++++++
> arch/cris/include/arch-v32/arch/byteorder.h | 22 ---------------------
> arch/cris/include/arch-v32/arch/swab.h | 22 +++++++++++++++++++++
Since you'e a git user, and you're basically renaming files while then
putting a new name in place, can you please send patches done with both
the "-M" flag (rename detection) _and_ the "-B" flag (which breaks
associations of files even if the name stays the same)?
It's rare that this is needed, but it really helps. Now the patches look
like a big delete/create event, and it's not at all obvious that the code
is actually the same before and after.
Linus
On Tue, 2009-01-06 at 13:59 -0800, Linus Torvalds wrote:
>
> On Tue, 6 Jan 2009, Harvey Harrison wrote:
> >
> > cris holds its arch overrides in an arch/ folder, rename these
> > byteorder.h files to swab.h and include them from asm/swab.h
> >
> > Signed-off-by: Harvey Harrison <[email protected]>
> > ---
> > arch/cris/include/arch-v10/arch/byteorder.h | 28 ---------------------------
> > arch/cris/include/arch-v10/arch/swab.h | 28 +++++++++++++++++++++++++++
> > arch/cris/include/arch-v32/arch/byteorder.h | 22 ---------------------
> > arch/cris/include/arch-v32/arch/swab.h | 22 +++++++++++++++++++++
>
>
> Since you'e a git user, and you're basically renaming files while then
> putting a new name in place, can you please send patches done with both
> the "-M" flag (rename detection) _and_ the "-B" flag (which breaks
> associations of files even if the name stays the same)?
>
> It's rare that this is needed, but it really helps. Now the patches look
> like a big delete/create event, and it's not at all obvious that the code
> is actually the same before and after.
Sure, I sent regular patches as a courtesy to Andrew in case he slurped
it up, but I can resend with -M -B if you're going to take it directly,
should I wait until I see the remaining 4 arches hit your tree, or will
you worry about the timing?
Harvey
On Tue, 6 Jan 2009, Harvey Harrison wrote:
>
> Sure, I sent regular patches as a courtesy to Andrew in case he slurped
> it up, but I can resend with -M -B if you're going to take it directly,
> should I wait until I see the remaining 4 arches hit your tree, or will
> you worry about the timing?
I'm not sure worrying about the timing makes much sense, since the bigger
worry is wanting to merge things in time for -rc1 - and that means having
a few days to catch any gotcha's. If parisc/xtensa/cris is broken for a
day or two, I don't consider that a problem.
Linus
On Tue, Jan 06, 2009 at 02:11:43PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 6 Jan 2009, Harvey Harrison wrote:
> >
> > Sure, I sent regular patches as a courtesy to Andrew in case he slurped
> > it up, but I can resend with -M -B if you're going to take it directly,
> > should I wait until I see the remaining 4 arches hit your tree, or will
> > you worry about the timing?
>
> I'm not sure worrying about the timing makes much sense, since the bigger
> worry is wanting to merge things in time for -rc1 - and that means having
> a few days to catch any gotcha's. If parisc/xtensa/cris is broken for a
> day or two, I don't consider that a problem.
mn10300, frv and maybe h8300 are waiting for these patches to hit mainline
before they move their headers to arch/$ARCH/include
So sooner is better so we can get the rest fixed in this respect.
For m68k I have sent a patch to unify the headers for m68k and m68knommu
in arch/m68k/include/...
I really hope it is heading towards you soon.
Sam
On Tue, 2009-01-06 at 14:11 -0800, Linus Torvalds wrote:
>
> On Tue, 6 Jan 2009, Harvey Harrison wrote:
> >
> > Sure, I sent regular patches as a courtesy to Andrew in case he slurped
> > it up, but I can resend with -M -B if you're going to take it directly,
> > should I wait until I see the remaining 4 arches hit your tree, or will
> > you worry about the timing?
>
> I'm not sure worrying about the timing makes much sense, since the bigger
> worry is wanting to merge things in time for -rc1 - and that means having
> a few days to catch any gotcha's. If parisc/xtensa/cris is broken for a
> day or two, I don't consider that a problem.
I've seen the sparc pull request go by and will assume it will be in
your tree.
I will not send cris, xtensa, parisc and the removal patches (22-23) so these
arches don't get broken even for a few days and will send those three and the removal
patch as soon as they merged.
Cheers,
Harvey