All of lore.kernel.org
 help / color / mirror / Atom feed
* Introduce support for little endian PowerPC
@ 2010-10-01  7:05 Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                   ` (19 more replies)
  0 siblings, 20 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh; +Cc: paulus

Some PowerPC processors can be run in either big or little endian modes, some
others can map selected pages of memory as little endian, which allows the same
thing. Until now we have only supported the default big endian mode in Linux.
This patch set introduces little endian support for the 44x family of PowerPC
processors.

This patch set in combination with a patched GCC, binutils, uClibc and
buildroot has allowed for a full proof of concept little endian environment on
a 440 Taishan board, which was able to successfully run busybox, OpenSSH and a
handful of other userspace programs without problems.

I am not currently in a position to release my patches for the toolchain, but
in the meantime I thought I would send my patches on the kernel side for review
and feedback.

While my toolchain patches are necessary to support the powerpcle-linux target,
the kernel can still be built with an unpatched toolchain using the
powerpcle-elf target instead. Userspace programs, however, do require the
patched toolchain to build.

Since the processor still starts as big endian, the boot wrapper must still be
compiled with a big endian 32bit toolchain. This can be passed into the build
as CROSSBE_COMPILE in the same manner as the CROSS_COMPILE variable. When the
boot wrapper is finished it runs some platform specific assembly to switch to
little endian and execute the kernel.

This is not yet complete support for little endian PowerPC, some outstanding
issues that I am aware of are:
 * We only support 32bit PowerPC for now (and indeed, only 44x)
 * The vdso has not been fixed to be endian agnostic - any userspace program
   accessing it will get an unexpected result.
 * I have not touched PCI at all
 * Remaining device tree accesses still need to be examined to ensure they are
   correctly handling the endianess of the device tree.
 * Any other driver that uses the device tree is likely be broken for the same reason.
 * I've included a patch for the alignment handler, however it is as yet
   completely untested due to a property of the hardware I've been using for
   testing.


^ permalink raw reply	[flat|nested] 101+ messages in thread

* [PATCH 01/18] powerpc: Add ability to build little endian kernels
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:05   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Michal Marek, Sam Ravnborg, Andrew Morton,
	Albert Herranz, Grant Likely, Segher Boessenkool, Andreas Schwab,
	Kumar Gala, Torez Smith

From: Ian Munsie <imunsie@au1.ibm.com>

This patch allows the kbuild system to successfully compile a kernel for
the little endian PowerPC architecture.

To build such a kernel a supported platform must be used and
CONFIG_CPU_LITTLE_ENDIAN must be set. CROSS_COMPILE must be set to a
suitable toolchain prefix (compiled for the powerpcle-elf target, or
patched to allow the powerpcle-linux target).

Since the system will always start in big endian mode, the zImage
wrapper must still be compiled with a big endian toolchain, which can be
specified via CROSS32_COMPILE.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/Makefile                   |   22 +++++++++++++++++++---
 arch/powerpc/boot/Makefile              |    3 ++-
 arch/powerpc/kernel/vdso32/vdso32.lds.S |    4 ++++
 arch/powerpc/platforms/Kconfig.cputype  |   16 ++++++++++++++++
 4 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index b7212b6..3eed685 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -56,11 +56,27 @@ endif
 
 UTS_MACHINE := $(OLDARCH)
 
+ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
+override CC	+= -mlittle-endian
+override AS	+= -mlittle-endian
+override LD	+= -EL
+LDEMULATION	:= lppc
+GNUTARGET	:= powerpcle
+MULTIPLEWORD	:= -mno-multiple
+else
+override CC	+= -mbig-endian
+override AS	+= -mbig-endian
+override LD	+= -EB
+LDEMULATION	:= ppc
+GNUTARGET	:= powerpc
+MULTIPLEWORD	:= -mmultiple
+endif
+
 ifeq ($(HAS_BIARCH),y)
 override AS	+= -a$(CONFIG_WORD_SIZE)
-override LD	+= -m elf$(CONFIG_WORD_SIZE)ppc
+override LD	+= -m elf$(CONFIG_WORD_SIZE)$(LDEMULATION)
 override CC	+= -m$(CONFIG_WORD_SIZE)
-override AR	:= GNUTARGET=elf$(CONFIG_WORD_SIZE)-powerpc $(AR)
+override AR	:= GNUTARGET=elf$(CONFIG_WORD_SIZE)-$(GNUTARGET) $(AR)
 endif
 
 LDFLAGS_vmlinux-yy := -Bstatic
@@ -68,7 +84,7 @@ LDFLAGS_vmlinux-$(CONFIG_PPC64)$(CONFIG_RELOCATABLE) := -pie
 LDFLAGS_vmlinux	:= $(LDFLAGS_vmlinux-yy)
 
 CFLAGS-$(CONFIG_PPC64)	:= -mminimal-toc -mtraceback=none  -mcall-aixdesc
-CFLAGS-$(CONFIG_PPC32)	:= -ffixed-r2 -mmultiple
+CFLAGS-$(CONFIG_PPC32)	:= -ffixed-r2 $(MULTIPLEWORD)
 KBUILD_CPPFLAGS	+= -Iarch/$(ARCH)
 KBUILD_AFLAGS	+= -Iarch/$(ARCH)
 KBUILD_CFLAGS	+= -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index fae8192..39f10a4 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -22,7 +22,8 @@ all: $(obj)/zImage
 BOOTCFLAGS    := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
 		 -fno-strict-aliasing -Os -msoft-float -pipe \
 		 -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
-		 -isystem $(shell $(CROSS32CC) -print-file-name=include)
+		 -isystem $(shell $(CROSS32CC) -print-file-name=include) \
+		 -mbig-endian
 BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
 
 ifdef CONFIG_DEBUG_INFO
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index 0546bcd..f4c6676 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -4,7 +4,11 @@
  */
 #include <asm/vdso.h>
 
+#ifdef __LITTLE_ENDIAN__
+OUTPUT_FORMAT("elf32-powerpcle", "elf32-powerpcle", "elf32-powerpcle")
+#else
 OUTPUT_FORMAT("elf32-powerpc", "elf32-powerpc", "elf32-powerpc")
+#endif
 OUTPUT_ARCH(powerpc:common)
 ENTRY(_start)
 
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index d361f81..074ff12 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY
 	bool
 
 endmenu
+
+config ARCH_SUPPORTS_LITTLE_ENDIAN
+	bool
+
+config CPU_LITTLE_ENDIAN
+	bool "Build little endian kernel"
+	depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL
+	default n
+	help
+	  This option selects whether a big endian or little endian kernel will
+	  be built.
+
+	  Note that if building a little endian kernel, CROSS_COMPILE must
+	  point to a toolchain capable of targetting little endian powerpc,
+	  while the toolchain specified by CROSS32_COMPILE must be capable of
+	  targetting *BIG* endian PowerPC.
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 01/18] powerpc: Add ability to build little endian kernels
@ 2010-10-01  7:05   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Michal Marek, Albert Herranz, paulus, Ian Munsie, Andreas Schwab,
	Andrew Morton, Sam Ravnborg, Torez Smith

From: Ian Munsie <imunsie@au1.ibm.com>

This patch allows the kbuild system to successfully compile a kernel for
the little endian PowerPC architecture.

To build such a kernel a supported platform must be used and
CONFIG_CPU_LITTLE_ENDIAN must be set. CROSS_COMPILE must be set to a
suitable toolchain prefix (compiled for the powerpcle-elf target, or
patched to allow the powerpcle-linux target).

Since the system will always start in big endian mode, the zImage
wrapper must still be compiled with a big endian toolchain, which can be
specified via CROSS32_COMPILE.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/Makefile                   |   22 +++++++++++++++++++---
 arch/powerpc/boot/Makefile              |    3 ++-
 arch/powerpc/kernel/vdso32/vdso32.lds.S |    4 ++++
 arch/powerpc/platforms/Kconfig.cputype  |   16 ++++++++++++++++
 4 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index b7212b6..3eed685 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -56,11 +56,27 @@ endif
 
 UTS_MACHINE := $(OLDARCH)
 
+ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
+override CC	+= -mlittle-endian
+override AS	+= -mlittle-endian
+override LD	+= -EL
+LDEMULATION	:= lppc
+GNUTARGET	:= powerpcle
+MULTIPLEWORD	:= -mno-multiple
+else
+override CC	+= -mbig-endian
+override AS	+= -mbig-endian
+override LD	+= -EB
+LDEMULATION	:= ppc
+GNUTARGET	:= powerpc
+MULTIPLEWORD	:= -mmultiple
+endif
+
 ifeq ($(HAS_BIARCH),y)
 override AS	+= -a$(CONFIG_WORD_SIZE)
-override LD	+= -m elf$(CONFIG_WORD_SIZE)ppc
+override LD	+= -m elf$(CONFIG_WORD_SIZE)$(LDEMULATION)
 override CC	+= -m$(CONFIG_WORD_SIZE)
-override AR	:= GNUTARGET=elf$(CONFIG_WORD_SIZE)-powerpc $(AR)
+override AR	:= GNUTARGET=elf$(CONFIG_WORD_SIZE)-$(GNUTARGET) $(AR)
 endif
 
 LDFLAGS_vmlinux-yy := -Bstatic
@@ -68,7 +84,7 @@ LDFLAGS_vmlinux-$(CONFIG_PPC64)$(CONFIG_RELOCATABLE) := -pie
 LDFLAGS_vmlinux	:= $(LDFLAGS_vmlinux-yy)
 
 CFLAGS-$(CONFIG_PPC64)	:= -mminimal-toc -mtraceback=none  -mcall-aixdesc
-CFLAGS-$(CONFIG_PPC32)	:= -ffixed-r2 -mmultiple
+CFLAGS-$(CONFIG_PPC32)	:= -ffixed-r2 $(MULTIPLEWORD)
 KBUILD_CPPFLAGS	+= -Iarch/$(ARCH)
 KBUILD_AFLAGS	+= -Iarch/$(ARCH)
 KBUILD_CFLAGS	+= -msoft-float -pipe -Iarch/$(ARCH) $(CFLAGS-y)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index fae8192..39f10a4 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -22,7 +22,8 @@ all: $(obj)/zImage
 BOOTCFLAGS    := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
 		 -fno-strict-aliasing -Os -msoft-float -pipe \
 		 -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
-		 -isystem $(shell $(CROSS32CC) -print-file-name=include)
+		 -isystem $(shell $(CROSS32CC) -print-file-name=include) \
+		 -mbig-endian
 BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
 
 ifdef CONFIG_DEBUG_INFO
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index 0546bcd..f4c6676 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -4,7 +4,11 @@
  */
 #include <asm/vdso.h>
 
+#ifdef __LITTLE_ENDIAN__
+OUTPUT_FORMAT("elf32-powerpcle", "elf32-powerpcle", "elf32-powerpcle")
+#else
 OUTPUT_FORMAT("elf32-powerpc", "elf32-powerpc", "elf32-powerpc")
+#endif
 OUTPUT_ARCH(powerpc:common)
 ENTRY(_start)
 
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index d361f81..074ff12 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY
 	bool
 
 endmenu
+
+config ARCH_SUPPORTS_LITTLE_ENDIAN
+	bool
+
+config CPU_LITTLE_ENDIAN
+	bool "Build little endian kernel"
+	depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL
+	default n
+	help
+	  This option selects whether a big endian or little endian kernel will
+	  be built.
+
+	  Note that if building a little endian kernel, CROSS_COMPILE must
+	  point to a toolchain capable of targetting little endian powerpc,
+	  while the toolchain specified by CROSS32_COMPILE must be capable of
+	  targetting *BIG* endian PowerPC.
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 02/18] powerpc: Add CROSSBE_COMPILE to build big endian boot wrapper
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:05   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Michal Marek, Sam Ravnborg, Andrew Morton,
	Albert Herranz, Grant Likely, Segher Boessenkool

From: Ian Munsie <imunsie@au1.ibm.com>

Since the boot wrapper must be built by a big endian 32bit toolchain
regardless of what the rest of the kernel is using introduce a new
parameter to specify that toolchain - CROSSBE_COMPILE.

We already have CROSS32_COMPILE which is already used for the boot
wrapper, but it is also used to build the 32bit vdso which should be
build in the same endianness as the rest of the kernel, so it is
necessary to be able to specify the toolchain to build the boot wrapper
separately from that used to build the vdso and again separately from
that used to build the main kernel.

CROSSBE_COMPILE should be pointed to a toolchain capable of targeting
32bit big endian powerpc, either specifically targetted at 32bit or
bi-arch 64 and 32bit. If CROSSBE_COMPILE is not specified it will fall
back to CROSS32_COMPILE to maintain compatibility with big endian
targets.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/Makefile      |   19 +++++++++++++++++--
 arch/powerpc/boot/Makefile |   25 +++++++++++++++----------
 2 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 3eed685..ab69b0e 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -14,7 +14,7 @@
 
 HAS_BIARCH	:= $(call cc-option-yn, -m32)
 
-# Set default 32 bits cross compilers for vdso and boot wrapper
+# Set default 32 bits cross compilers for vdso
 CROSS32_COMPILE ?=
 
 CROSS32CC		:= $(CROSS32_COMPILE)gcc
@@ -27,7 +27,22 @@ CROSS32AR	:= GNUTARGET=elf32-powerpc $(AR)
 endif
 endif
 
-export CROSS32CC CROSS32AR
+# Set default big endian 32 bits cross compiler for boot wrapper
+ifeq ($(CROSSBE_COMPILE),)
+CROSSBECC	:= $(CROSS32CC)
+CROSSBEAR	:= $(CROSS32AR)
+else
+CROSSBECC	:= $(CROSSBE_COMPILE)gcc
+CROSSBEAR	:= $(CROSSBE_COMPILE)ar
+endif
+
+ifeq ($(call try-run,\
+	$(CROSSBECC) -m32 -c -xc /dev/null -o "$$TMP",y,n),y)
+CROSSBECC	:= $(CROSSBECC) -m32
+CROSSBEAR	:= GNUTARGET=elf32-powerpc $(CROSSBEAR)
+endif
+
+export CROSS32CC CROSS32AR CROSSBECC CROSSBEAR
 
 ifeq ($(CROSS_COMPILE),)
 KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 39f10a4..79d7e69 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -6,23 +6,24 @@
 # Based on coffboot by Paul Mackerras
 # Simplified for ppc64 by Todd Inglett
 #
-# NOTE:	this code is built for 32 bit in ELF32 format even though
-#	it packages a 64 bit kernel.  We do this to simplify the
+# NOTE:	this code is built for 32 bit big endian in ELF32 format even
+#	though it packages a 64 bit kernel.  We do this to simplify the
 #	bootloader and increase compatibility with OpenFirmware.
 #
-#	To this end we need to define BOOTCC, etc, as the tools
-#	needed to build the 32 bit image.  That's normally the same
+#	To this end we need to define BOOTCC, etc, as the tools needed
+#	to build the 32 bit big endian image.  That's normally the same
 #	compiler for the rest of the kernel, with the -m32 flag added.
 #	To make it easier to setup a cross compiler,
-#	CROSS32_COMPILE is setup as a prefix just like CROSS_COMPILE
-#	in the toplevel makefile.
+#	CROSSBE_COMPILE is setup as a prefix just like CROSS_COMPILE
+#	in the toplevel makefile. If building a big endian kernel,
+#	CROSS32_COMPILE may be used in it's place.
 
 all: $(obj)/zImage
 
 BOOTCFLAGS    := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
 		 -fno-strict-aliasing -Os -msoft-float -pipe \
 		 -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
-		 -isystem $(shell $(CROSS32CC) -print-file-name=include) \
+		 -isystem $(shell $(CROSSBECC) -print-file-name=include) \
 		 -mbig-endian
 BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
 
@@ -122,13 +123,13 @@ clean-files := $(zlib) $(zlibheader) $(zliblinuxheader) \
 		empty.c zImage.coff.lds zImage.ps3.lds zImage.lds
 
 quiet_cmd_bootcc = BOOTCC  $@
-      cmd_bootcc = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
+      cmd_bootcc = $(CROSSBECC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
 
 quiet_cmd_bootas = BOOTAS  $@
-      cmd_bootas = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $<
+      cmd_bootas = $(CROSSBECC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $<
 
 quiet_cmd_bootar = BOOTAR  $@
-      cmd_bootar = $(CROSS32AR) -cr $@.$$$$ $(filter-out FORCE,$^); mv $@.$$$$ $@
+      cmd_bootar = $(CROSSBEAR) -cr $@.$$$$ $(filter-out FORCE,$^); mv $@.$$$$ $@
 
 $(obj-libfdt): $(obj)/%.o: $(srctree)/scripts/dtc/libfdt/%.c FORCE
 	$(call if_changed_dep,bootcc)
@@ -157,6 +158,9 @@ wrapperbits	:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \
 #############
 # Bits for building various flavours of zImage
 
+ifneq ($(CROSSBE_COMPILE),)
+CROSSWRAP := -C "$(CROSSBE_COMPILE)"
+else
 ifneq ($(CROSS32_COMPILE),)
 CROSSWRAP := -C "$(CROSS32_COMPILE)"
 else
@@ -164,6 +168,7 @@ ifneq ($(CROSS_COMPILE),)
 CROSSWRAP := -C "$(CROSS_COMPILE)"
 endif
 endif
+endif
 
 # args (to if_changed): 1 = (this rule), 2 = platform, 3 = dts 4=dtb 5=initrd
 quiet_cmd_wrap	= WRAP    $@
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 02/18] powerpc: Add CROSSBE_COMPILE to build big endian boot wrapper
@ 2010-10-01  7:05   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Michal Marek, Albert Herranz, paulus, Ian Munsie, Andrew Morton,
	Sam Ravnborg

From: Ian Munsie <imunsie@au1.ibm.com>

Since the boot wrapper must be built by a big endian 32bit toolchain
regardless of what the rest of the kernel is using introduce a new
parameter to specify that toolchain - CROSSBE_COMPILE.

We already have CROSS32_COMPILE which is already used for the boot
wrapper, but it is also used to build the 32bit vdso which should be
build in the same endianness as the rest of the kernel, so it is
necessary to be able to specify the toolchain to build the boot wrapper
separately from that used to build the vdso and again separately from
that used to build the main kernel.

CROSSBE_COMPILE should be pointed to a toolchain capable of targeting
32bit big endian powerpc, either specifically targetted at 32bit or
bi-arch 64 and 32bit. If CROSSBE_COMPILE is not specified it will fall
back to CROSS32_COMPILE to maintain compatibility with big endian
targets.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/Makefile      |   19 +++++++++++++++++--
 arch/powerpc/boot/Makefile |   25 +++++++++++++++----------
 2 files changed, 32 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 3eed685..ab69b0e 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -14,7 +14,7 @@
 
 HAS_BIARCH	:= $(call cc-option-yn, -m32)
 
-# Set default 32 bits cross compilers for vdso and boot wrapper
+# Set default 32 bits cross compilers for vdso
 CROSS32_COMPILE ?=
 
 CROSS32CC		:= $(CROSS32_COMPILE)gcc
@@ -27,7 +27,22 @@ CROSS32AR	:= GNUTARGET=elf32-powerpc $(AR)
 endif
 endif
 
-export CROSS32CC CROSS32AR
+# Set default big endian 32 bits cross compiler for boot wrapper
+ifeq ($(CROSSBE_COMPILE),)
+CROSSBECC	:= $(CROSS32CC)
+CROSSBEAR	:= $(CROSS32AR)
+else
+CROSSBECC	:= $(CROSSBE_COMPILE)gcc
+CROSSBEAR	:= $(CROSSBE_COMPILE)ar
+endif
+
+ifeq ($(call try-run,\
+	$(CROSSBECC) -m32 -c -xc /dev/null -o "$$TMP",y,n),y)
+CROSSBECC	:= $(CROSSBECC) -m32
+CROSSBEAR	:= GNUTARGET=elf32-powerpc $(CROSSBEAR)
+endif
+
+export CROSS32CC CROSS32AR CROSSBECC CROSSBEAR
 
 ifeq ($(CROSS_COMPILE),)
 KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 39f10a4..79d7e69 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -6,23 +6,24 @@
 # Based on coffboot by Paul Mackerras
 # Simplified for ppc64 by Todd Inglett
 #
-# NOTE:	this code is built for 32 bit in ELF32 format even though
-#	it packages a 64 bit kernel.  We do this to simplify the
+# NOTE:	this code is built for 32 bit big endian in ELF32 format even
+#	though it packages a 64 bit kernel.  We do this to simplify the
 #	bootloader and increase compatibility with OpenFirmware.
 #
-#	To this end we need to define BOOTCC, etc, as the tools
-#	needed to build the 32 bit image.  That's normally the same
+#	To this end we need to define BOOTCC, etc, as the tools needed
+#	to build the 32 bit big endian image.  That's normally the same
 #	compiler for the rest of the kernel, with the -m32 flag added.
 #	To make it easier to setup a cross compiler,
-#	CROSS32_COMPILE is setup as a prefix just like CROSS_COMPILE
-#	in the toplevel makefile.
+#	CROSSBE_COMPILE is setup as a prefix just like CROSS_COMPILE
+#	in the toplevel makefile. If building a big endian kernel,
+#	CROSS32_COMPILE may be used in it's place.
 
 all: $(obj)/zImage
 
 BOOTCFLAGS    := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
 		 -fno-strict-aliasing -Os -msoft-float -pipe \
 		 -fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
-		 -isystem $(shell $(CROSS32CC) -print-file-name=include) \
+		 -isystem $(shell $(CROSSBECC) -print-file-name=include) \
 		 -mbig-endian
 BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
 
@@ -122,13 +123,13 @@ clean-files := $(zlib) $(zlibheader) $(zliblinuxheader) \
 		empty.c zImage.coff.lds zImage.ps3.lds zImage.lds
 
 quiet_cmd_bootcc = BOOTCC  $@
-      cmd_bootcc = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
+      cmd_bootcc = $(CROSSBECC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $<
 
 quiet_cmd_bootas = BOOTAS  $@
-      cmd_bootas = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $<
+      cmd_bootas = $(CROSSBECC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $<
 
 quiet_cmd_bootar = BOOTAR  $@
-      cmd_bootar = $(CROSS32AR) -cr $@.$$$$ $(filter-out FORCE,$^); mv $@.$$$$ $@
+      cmd_bootar = $(CROSSBEAR) -cr $@.$$$$ $(filter-out FORCE,$^); mv $@.$$$$ $@
 
 $(obj-libfdt): $(obj)/%.o: $(srctree)/scripts/dtc/libfdt/%.c FORCE
 	$(call if_changed_dep,bootcc)
@@ -157,6 +158,9 @@ wrapperbits	:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \
 #############
 # Bits for building various flavours of zImage
 
+ifneq ($(CROSSBE_COMPILE),)
+CROSSWRAP := -C "$(CROSSBE_COMPILE)"
+else
 ifneq ($(CROSS32_COMPILE),)
 CROSSWRAP := -C "$(CROSS32_COMPILE)"
 else
@@ -164,6 +168,7 @@ ifneq ($(CROSS_COMPILE),)
 CROSSWRAP := -C "$(CROSS_COMPILE)"
 endif
 endif
+endif
 
 # args (to if_changed): 1 = (this rule), 2 = platform, 3 = dts 4=dtb 5=initrd
 quiet_cmd_wrap	= WRAP    $@
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 03/18] powerpc: Support parsing a little endian kernel from zImage wrapper
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
@ 2010-10-01  7:05 ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                   ` (16 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh; +Cc: paulus, Ian Munsie

From: Ian Munsie <imunsie@au1.ibm.com>

This patch adds support to the PowerPC zImage wrapper (which always runs
in big endian mode) to detect if the zImage is little endian and parse
it's ELF header to enable it's successful extraction.

It also provides some infrastructure for executing a little endian
kernel - PowerPC platforms that support little endian should fill
platform_ops.le_kentry with a function pointer to the routine
responsible for switching the CPU to little endian and executing the
kernel. This routing takes the same arguments in the same positions as
kentry to allow them to easily be passed onto the kernel, with the
kentry pointer itself tacked on as argument 4.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/boot/elf.h       |    2 +-
 arch/powerpc/boot/elf_util.c  |   48 +++++++++++++++++++++++++++++++++++++---
 arch/powerpc/boot/main.c      |   26 +++++++++++++++++-----
 arch/powerpc/boot/ops.h       |    3 ++
 arch/powerpc/boot/prpmc2800.c |    5 +++-
 arch/powerpc/boot/swab.h      |   26 ++++++++++++++++++++++
 6 files changed, 98 insertions(+), 12 deletions(-)
 create mode 100644 arch/powerpc/boot/swab.h

diff --git a/arch/powerpc/boot/elf.h b/arch/powerpc/boot/elf.h
index 1941bc5..9de8105 100644
--- a/arch/powerpc/boot/elf.h
+++ b/arch/powerpc/boot/elf.h
@@ -152,6 +152,6 @@ struct elf_info {
 	unsigned long elfoffset;
 };
 int parse_elf64(void *hdr, struct elf_info *info);
-int parse_elf32(void *hdr, struct elf_info *info);
+int parse_elf32(void *hdr, struct elf_info *info, int *little_endian);
 
 #endif				/* _PPC_BOOT_ELF_H_ */
diff --git a/arch/powerpc/boot/elf_util.c b/arch/powerpc/boot/elf_util.c
index 1567a0c..67bba80 100644
--- a/arch/powerpc/boot/elf_util.c
+++ b/arch/powerpc/boot/elf_util.c
@@ -14,6 +14,7 @@
 #include "page.h"
 #include "string.h"
 #include "stdio.h"
+#include "swab.h"
 
 int parse_elf64(void *hdr, struct elf_info *info)
 {
@@ -47,7 +48,35 @@ int parse_elf64(void *hdr, struct elf_info *info)
 	return 1;
 }
 
-int parse_elf32(void *hdr, struct elf_info *info)
+void byteswap_elf32(Elf32_Ehdr *elf32) {
+	Elf32_Phdr *elf32ph;
+
+	swab16s(&elf32->e_type);
+	swab16s(&elf32->e_machine);
+	swab32s(&elf32->e_version);
+	swab32s(&elf32->e_entry);
+	swab32s(&elf32->e_phoff);
+	swab32s(&elf32->e_shoff);
+	swab32s(&elf32->e_flags);
+	swab16s(&elf32->e_ehsize);
+	swab16s(&elf32->e_phentsize);
+	swab16s(&elf32->e_phnum);
+	swab16s(&elf32->e_shentsize);
+	swab16s(&elf32->e_shnum);
+	swab16s(&elf32->e_shstrndx);
+
+	elf32ph = (Elf32_Phdr *) ((unsigned long)elf32 + elf32->e_phoff);
+	swab32s(&elf32ph->p_type);
+	swab32s(&elf32ph->p_offset);
+	swab32s(&elf32ph->p_vaddr);
+	swab32s(&elf32ph->p_paddr);
+	swab32s(&elf32ph->p_filesz);
+	swab32s(&elf32ph->p_memsz);
+	swab32s(&elf32ph->p_flags);
+	swab32s(&elf32ph->p_align);
+}
+
+int parse_elf32(void *hdr, struct elf_info *info, int *little_endian)
 {
 	Elf32_Ehdr *elf32 = hdr;
 	Elf32_Phdr *elf32ph;
@@ -57,9 +86,20 @@ int parse_elf32(void *hdr, struct elf_info *info)
 	      elf32->e_ident[EI_MAG1]  == ELFMAG1	&&
 	      elf32->e_ident[EI_MAG2]  == ELFMAG2	&&
 	      elf32->e_ident[EI_MAG3]  == ELFMAG3	&&
-	      elf32->e_ident[EI_CLASS] == ELFCLASS32	&&
-	      elf32->e_ident[EI_DATA]  == ELFDATA2MSB	&&
-	      (elf32->e_type            == ET_EXEC ||
+	      elf32->e_ident[EI_CLASS] == ELFCLASS32))
+		return 0;
+	switch(elf32->e_ident[EI_DATA]) {
+		case ELFDATA2MSB:
+			*little_endian = 0;
+			break;
+		case ELFDATA2LSB:
+			*little_endian = 1;
+			byteswap_elf32(elf32);
+			break;
+		default:
+			return 0;
+	}
+	if (!((elf32->e_type            == ET_EXEC ||
 	       elf32->e_type            == ET_DYN)      &&
 	      elf32->e_machine         == EM_PPC))
 		return 0;
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index a28f021..36dd2b6 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -27,7 +27,7 @@ struct addr_range {
 
 #undef DEBUG
 
-static struct addr_range prep_kernel(void)
+static struct addr_range prep_kernel(int *little_endian)
 {
 	char elfheader[256];
 	void *vmlinuz_addr = _vmlinux_start;
@@ -40,8 +40,10 @@ static struct addr_range prep_kernel(void)
 	gunzip_start(&gzstate, vmlinuz_addr, vmlinuz_size);
 	gunzip_exactly(&gzstate, elfheader, sizeof(elfheader));
 
-	if (!parse_elf64(elfheader, &ei) && !parse_elf32(elfheader, &ei))
+	if (!parse_elf64(elfheader, &ei) && !parse_elf32(elfheader, &ei, little_endian))
 		fatal("Error: not a valid PPC32 or PPC64 ELF file!\n\r");
+	if (*little_endian && !platform_ops.le_kentry)
+		fatal("Little Endian kernel unsupported on this platform!");
 
 	if (platform_ops.image_hdr)
 		platform_ops.image_hdr(elfheader);
@@ -166,8 +168,10 @@ void start(void)
 {
 	struct addr_range vmlinux, initrd;
 	kernel_entry_t kentry;
+	le_kernel_entry_t le_kentry;
 	unsigned long ft_addr = 0;
 	void *chosen;
+	int little_endian = 0;
 
 	/* Do this first, because malloc() could clobber the loader's
 	 * command line.  Only use the loader command line if a
@@ -189,7 +193,7 @@ void start(void)
 	if (!chosen)
 		chosen = create_node(NULL, "chosen");
 
-	vmlinux = prep_kernel();
+	vmlinux = prep_kernel(&little_endian);
 	initrd = prep_initrd(vmlinux, chosen,
 			     loader_info.initrd_addr, loader_info.initrd_size);
 	prep_cmdline(chosen);
@@ -206,11 +210,21 @@ void start(void)
 		console_ops.close();
 
 	kentry = (kernel_entry_t) vmlinux.addr;
+	le_kentry = (le_kernel_entry_t)platform_ops.le_kentry;
 	if (ft_addr)
-		kentry(ft_addr, 0, NULL);
+		if (little_endian)
+			le_kentry(ft_addr, 0, NULL, kentry);
+		else
+			kentry(ft_addr, 0, NULL);
 	else
-		kentry((unsigned long)initrd.addr, initrd.size,
-		       loader_info.promptr);
+		if (little_endian)
+			le_kentry((unsigned long)initrd.addr, initrd.size,
+			       loader_info.promptr, kentry);
+		else
+			kentry((unsigned long)initrd.addr, initrd.size,
+			       loader_info.promptr);
+
+	kentry(ft_addr, 0, NULL);
 
 	/* console closed so printf in fatal below may not work */
 	fatal("Error: Linux kernel returned to zImage boot wrapper!\n\r");
diff --git a/arch/powerpc/boot/ops.h b/arch/powerpc/boot/ops.h
index b3218ce..cd6c7bf 100644
--- a/arch/powerpc/boot/ops.h
+++ b/arch/powerpc/boot/ops.h
@@ -20,6 +20,8 @@
 #define	MAX_PROP_LEN		256 /* What should this be? */
 
 typedef void (*kernel_entry_t)(unsigned long r3, unsigned long r4, void *r5);
+typedef void (*le_kernel_entry_t)(unsigned long r3, unsigned long r4, void *r5,
+				  kernel_entry_t kentry);
 
 /* Platform specific operations */
 struct platform_ops {
@@ -30,6 +32,7 @@ struct platform_ops {
 	void *	(*realloc)(void *ptr, unsigned long size);
 	void	(*exit)(void);
 	void *	(*vmlinux_alloc)(unsigned long size);
+	le_kernel_entry_t le_kentry;
 };
 extern struct platform_ops platform_ops;
 
diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c
index da31d60..6bad899 100644
--- a/arch/powerpc/boot/prpmc2800.c
+++ b/arch/powerpc/boot/prpmc2800.c
@@ -519,6 +519,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 	void *vmlinuz_addr = _vmlinux_start;
 	unsigned long vmlinuz_size = _vmlinux_end - _vmlinux_start;
 	char elfheader[256];
+	int little_endian;
 
 	if (dt_size <= 0) /* No fdt */
 		exit();
@@ -533,7 +534,9 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 	gunzip_start(&gzstate, vmlinuz_addr, vmlinuz_size);
 	gunzip_exactly(&gzstate, elfheader, sizeof(elfheader));
 
-	if (!parse_elf32(elfheader, &ei))
+	if (!parse_elf32(elfheader, &ei, &little_endian))
+		exit();
+	if (little_endian)
 		exit();
 
 	heap_start = (char *)(ei.memsize + ei.elfoffset); /* end of kernel*/
diff --git a/arch/powerpc/boot/swab.h b/arch/powerpc/boot/swab.h
new file mode 100644
index 0000000..b122c2d
--- /dev/null
+++ b/arch/powerpc/boot/swab.h
@@ -0,0 +1,26 @@
+#ifndef _SWAB_H_
+#define _SWAB_H_
+
+#include "types.h"
+
+static __inline__ void st_le16(volatile u16 *addr, const u16 val)
+{
+	__asm__ __volatile__ ("sthbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
+}
+
+static inline void swab16s(u16 *addr)
+{
+	st_le16(addr, *addr);
+}
+
+static __inline__ void st_le32(volatile u32 *addr, const u32 val)
+{
+	__asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" (addr));
+}
+
+static inline void swab32s(u32 *addr)
+{
+	st_le32(addr, *addr);
+}
+
+#endif
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 04/18] powerpc: Allow taishan platform to boot a little endian kernel
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:05   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Albert Herranz, Grant Likely,
	Segher Boessenkool, Kumar Gala, Torez Smith

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6196 bytes --]

From: Ian Munsie <imunsie@au1.ibm.com>

This adds code to the boot wrapper to allow 44x CPUs to boot little
endian kernels. Presumably all 44x PowerPC platforms should also be able
to use this code unmodified, but this patch only wires up the taishan
platform as that has been tested.

The boot wrapper is still run in 32bit big endian mode and must set the
E bit in the TLB entries that the kernel may use initially. Naturally
the code setting this up can't afford to change the E bit on it's own
TLB entry while it is executing so it sets up a trampoline in address
space 1 to affect the change on all address space 0 TLB entries.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/boot/4xx.h                |    2 +
 arch/powerpc/boot/Makefile             |    2 +-
 arch/powerpc/boot/cuboot-taishan.c     |    1 +
 arch/powerpc/boot/le-44x.S             |   85 ++++++++++++++++++++++++++++++++
 arch/powerpc/platforms/Kconfig.cputype |    1 +
 5 files changed, 90 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/le-44x.S

diff --git a/arch/powerpc/boot/4xx.h b/arch/powerpc/boot/4xx.h
index 7dc5d45..05bc068 100644
--- a/arch/powerpc/boot/4xx.h
+++ b/arch/powerpc/boot/4xx.h
@@ -29,5 +29,7 @@ void ibm440gx_fixup_clocks(unsigned int sys_clk, unsigned int ser_clk,
 			   unsigned int tmr_clk);
 void ibm440spe_fixup_clocks(unsigned int sys_clk, unsigned int ser_clk,
 			    unsigned int tmr_clk);
+void ibm44x_le_kentry(unsigned long r3, unsigned long r4, void *r5,
+		      kernel_entry_t kentry);
 
 #endif /* _POWERPC_BOOT_4XX_H_ */
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 79d7e69..c4b8616 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -69,7 +69,7 @@ src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
 		gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
 		4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
 		cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
-		fsl-soc.c mpc8xx.c pq2.c ugecon.c
+		fsl-soc.c mpc8xx.c pq2.c ugecon.c le-44x.S
 src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \
 		cuboot-ebony.c cuboot-hotfoot.c treeboot-ebony.c prpmc2800.c \
 		ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
diff --git a/arch/powerpc/boot/cuboot-taishan.c b/arch/powerpc/boot/cuboot-taishan.c
index 9bc906a..7fdd614 100644
--- a/arch/powerpc/boot/cuboot-taishan.c
+++ b/arch/powerpc/boot/cuboot-taishan.c
@@ -52,6 +52,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 	CUBOOT_INIT();
 
 	platform_ops.fixups = taishan_fixups;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	fdt_init(_dtb_start);
 	serial_console_init();
 }
diff --git a/arch/powerpc/boot/le-44x.S b/arch/powerpc/boot/le-44x.S
new file mode 100644
index 0000000..c8d2ee4
--- /dev/null
+++ b/arch/powerpc/boot/le-44x.S
@@ -0,0 +1,85 @@
+/*
+ * Copyright © 2010 Ian Munsie, IBM Corporation
+ *
+ * Assembly to begin executing a little endian kernel from a big endian boot
+ * wrapper. Uses a trampoline in address space 1 to update the E bit in each
+ * TLB entry of address space 0 before entering the kernel.
+ */
+
+#include "ppc_asm.h"
+
+#define __MASK(X)		(1<<(X))
+
+#define SPRN_SRR0		0x01A		/* Save/Restore Register 0 */
+#define SPRN_SRR1		0x01B		/* Save/Restore Register 1 */
+
+#define MSR_IS			__MASK(5)	/* Instruction Space */
+#define MSR_DS			__MASK(4)	/* Data Space */
+
+#define	PPC44x_TLB_PAGEID	0
+#define	PPC44x_TLB_XLAT		1
+#define	PPC44x_TLB_ATTRIB	2
+
+/* Page identification fields */
+#define	PPC44x_TLB_VALID	0x00000200      /* Valid flag */
+#define PPC44x_TLB_TS		0x00000100	/* Translation address space */
+
+/* Storage attribute and access control fields */
+#define PPC44x_TLB_E		0x00000080      /* Memory is little endian */
+
+	.text
+	.global ibm44x_le_kentry
+ibm44x_le_kentry:
+	/* Find an invalid TLB entry we can use */
+	li	r12,0				/* Start searching at TLB 0 */
+1:	tlbre	r10,r12,PPC44x_TLB_PAGEID	/* Read TLB page ID word */
+	andi.	r0,r10,PPC44x_TLB_VALID		/* Test if TLB is valid */
+	beq	2f				/* If not valid we are free to use it */
+	addi	r12,r12,1			/* If valid, increment */
+	cmpwi	r12,64				/* Have we reached the end of the TLBs? */
+	bne	1b				/* If not, continue searching */
+	blr					/* If so, no invalid TLB entries found :( Shouldn't happen AFAIK */
+
+	/* Locate TLB entry containing trampoline */
+2:	lis	r0,le_trampoline@h
+	ori	r0,r0,le_trampoline@l
+	tlbsx	r11,0,r0
+
+	/* Set free TLB to match our TLB, but with TS=1 */
+	tlbre	r10,r11,PPC44x_TLB_XLAT
+	tlbwe	r10,r12,PPC44x_TLB_XLAT
+	tlbre	r10,r11,PPC44x_TLB_ATTRIB
+	tlbwe	r10,r12,PPC44x_TLB_ATTRIB
+	tlbre	r10,r11,PPC44x_TLB_PAGEID
+	ori	r10,r10,PPC44x_TLB_TS
+	tlbwe	r10,r12,PPC44x_TLB_PAGEID
+
+	/* Goto trampoline in address space 1 */
+	mtspr	SPRN_SRR0,r0
+	mfmsr	r0
+	ori	r0,r0,MSR_IS | MSR_DS
+	mtspr	SPRN_SRR1,r0
+	rfi
+
+le_trampoline:
+	/* Set E bit on all valid TLB entries with TS=0 */
+	li	r12,0				/* Start searching at TLB 0 */
+1:	tlbre	r10,r12,PPC44x_TLB_PAGEID	/* Read TLB page ID word */
+	andi.	r0,r10,PPC44x_TLB_VALID		/* Test if TLB is valid */
+	beq	2f				/* If not valid, continue */
+	andi.	r0,r10,PPC44x_TLB_TS		/* If valid, test if TLB is TS=1 */
+	bne	2f				/* If TS=1, continue */
+	tlbre	r10,r12,PPC44x_TLB_ATTRIB	/* If TS=0, read TLB attributes */
+	ori	r10,r10,PPC44x_TLB_E		/* Set little endian bit */
+	tlbwe	r10,r12,PPC44x_TLB_ATTRIB	/* Write attributes back */
+2:	addi	r12,r12,1			/* Increment */
+	cmpwi	r12,64				/* Are we done? */
+	bne	1b				/* If not, continue searching */
+
+	/* Goto kentry in address space 0 */
+	mtspr	SPRN_SRR0,r6			/* arg 4 (kentry) */
+	mfmsr	r11
+	li	r12,MSR_IS | MSR_DS
+	andc	r11,r11,r12
+	mtspr	SPRN_SRR1,r11
+	rfi
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 074ff12..8ba962e 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -49,6 +49,7 @@ config 44x
 	select 4xx_SOC
 	select PPC_PCI_CHOICE
 	select PHYS_64BIT
+	select ARCH_SUPPORTS_LITTLE_ENDIAN
 
 config E200
 	bool "Freescale e200"
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 04/18] powerpc: Allow taishan platform to boot a little endian kernel
@ 2010-10-01  7:05   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Albert Herranz, paulus, Ian Munsie, Torez Smith

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6195 bytes --]

From: Ian Munsie <imunsie@au1.ibm.com>

This adds code to the boot wrapper to allow 44x CPUs to boot little
endian kernels. Presumably all 44x PowerPC platforms should also be able
to use this code unmodified, but this patch only wires up the taishan
platform as that has been tested.

The boot wrapper is still run in 32bit big endian mode and must set the
E bit in the TLB entries that the kernel may use initially. Naturally
the code setting this up can't afford to change the E bit on it's own
TLB entry while it is executing so it sets up a trampoline in address
space 1 to affect the change on all address space 0 TLB entries.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/boot/4xx.h                |    2 +
 arch/powerpc/boot/Makefile             |    2 +-
 arch/powerpc/boot/cuboot-taishan.c     |    1 +
 arch/powerpc/boot/le-44x.S             |   85 ++++++++++++++++++++++++++++++++
 arch/powerpc/platforms/Kconfig.cputype |    1 +
 5 files changed, 90 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/le-44x.S

diff --git a/arch/powerpc/boot/4xx.h b/arch/powerpc/boot/4xx.h
index 7dc5d45..05bc068 100644
--- a/arch/powerpc/boot/4xx.h
+++ b/arch/powerpc/boot/4xx.h
@@ -29,5 +29,7 @@ void ibm440gx_fixup_clocks(unsigned int sys_clk, unsigned int ser_clk,
 			   unsigned int tmr_clk);
 void ibm440spe_fixup_clocks(unsigned int sys_clk, unsigned int ser_clk,
 			    unsigned int tmr_clk);
+void ibm44x_le_kentry(unsigned long r3, unsigned long r4, void *r5,
+		      kernel_entry_t kentry);
 
 #endif /* _POWERPC_BOOT_4XX_H_ */
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 79d7e69..c4b8616 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -69,7 +69,7 @@ src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
 		gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
 		4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
 		cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
-		fsl-soc.c mpc8xx.c pq2.c ugecon.c
+		fsl-soc.c mpc8xx.c pq2.c ugecon.c le-44x.S
 src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \
 		cuboot-ebony.c cuboot-hotfoot.c treeboot-ebony.c prpmc2800.c \
 		ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
diff --git a/arch/powerpc/boot/cuboot-taishan.c b/arch/powerpc/boot/cuboot-taishan.c
index 9bc906a..7fdd614 100644
--- a/arch/powerpc/boot/cuboot-taishan.c
+++ b/arch/powerpc/boot/cuboot-taishan.c
@@ -52,6 +52,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 	CUBOOT_INIT();
 
 	platform_ops.fixups = taishan_fixups;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	fdt_init(_dtb_start);
 	serial_console_init();
 }
diff --git a/arch/powerpc/boot/le-44x.S b/arch/powerpc/boot/le-44x.S
new file mode 100644
index 0000000..c8d2ee4
--- /dev/null
+++ b/arch/powerpc/boot/le-44x.S
@@ -0,0 +1,85 @@
+/*
+ * Copyright © 2010 Ian Munsie, IBM Corporation
+ *
+ * Assembly to begin executing a little endian kernel from a big endian boot
+ * wrapper. Uses a trampoline in address space 1 to update the E bit in each
+ * TLB entry of address space 0 before entering the kernel.
+ */
+
+#include "ppc_asm.h"
+
+#define __MASK(X)		(1<<(X))
+
+#define SPRN_SRR0		0x01A		/* Save/Restore Register 0 */
+#define SPRN_SRR1		0x01B		/* Save/Restore Register 1 */
+
+#define MSR_IS			__MASK(5)	/* Instruction Space */
+#define MSR_DS			__MASK(4)	/* Data Space */
+
+#define	PPC44x_TLB_PAGEID	0
+#define	PPC44x_TLB_XLAT		1
+#define	PPC44x_TLB_ATTRIB	2
+
+/* Page identification fields */
+#define	PPC44x_TLB_VALID	0x00000200      /* Valid flag */
+#define PPC44x_TLB_TS		0x00000100	/* Translation address space */
+
+/* Storage attribute and access control fields */
+#define PPC44x_TLB_E		0x00000080      /* Memory is little endian */
+
+	.text
+	.global ibm44x_le_kentry
+ibm44x_le_kentry:
+	/* Find an invalid TLB entry we can use */
+	li	r12,0				/* Start searching at TLB 0 */
+1:	tlbre	r10,r12,PPC44x_TLB_PAGEID	/* Read TLB page ID word */
+	andi.	r0,r10,PPC44x_TLB_VALID		/* Test if TLB is valid */
+	beq	2f				/* If not valid we are free to use it */
+	addi	r12,r12,1			/* If valid, increment */
+	cmpwi	r12,64				/* Have we reached the end of the TLBs? */
+	bne	1b				/* If not, continue searching */
+	blr					/* If so, no invalid TLB entries found :( Shouldn't happen AFAIK */
+
+	/* Locate TLB entry containing trampoline */
+2:	lis	r0,le_trampoline@h
+	ori	r0,r0,le_trampoline@l
+	tlbsx	r11,0,r0
+
+	/* Set free TLB to match our TLB, but with TS=1 */
+	tlbre	r10,r11,PPC44x_TLB_XLAT
+	tlbwe	r10,r12,PPC44x_TLB_XLAT
+	tlbre	r10,r11,PPC44x_TLB_ATTRIB
+	tlbwe	r10,r12,PPC44x_TLB_ATTRIB
+	tlbre	r10,r11,PPC44x_TLB_PAGEID
+	ori	r10,r10,PPC44x_TLB_TS
+	tlbwe	r10,r12,PPC44x_TLB_PAGEID
+
+	/* Goto trampoline in address space 1 */
+	mtspr	SPRN_SRR0,r0
+	mfmsr	r0
+	ori	r0,r0,MSR_IS | MSR_DS
+	mtspr	SPRN_SRR1,r0
+	rfi
+
+le_trampoline:
+	/* Set E bit on all valid TLB entries with TS=0 */
+	li	r12,0				/* Start searching at TLB 0 */
+1:	tlbre	r10,r12,PPC44x_TLB_PAGEID	/* Read TLB page ID word */
+	andi.	r0,r10,PPC44x_TLB_VALID		/* Test if TLB is valid */
+	beq	2f				/* If not valid, continue */
+	andi.	r0,r10,PPC44x_TLB_TS		/* If valid, test if TLB is TS=1 */
+	bne	2f				/* If TS=1, continue */
+	tlbre	r10,r12,PPC44x_TLB_ATTRIB	/* If TS=0, read TLB attributes */
+	ori	r10,r10,PPC44x_TLB_E		/* Set little endian bit */
+	tlbwe	r10,r12,PPC44x_TLB_ATTRIB	/* Write attributes back */
+2:	addi	r12,r12,1			/* Increment */
+	cmpwi	r12,64				/* Are we done? */
+	bne	1b				/* If not, continue searching */
+
+	/* Goto kentry in address space 0 */
+	mtspr	SPRN_SRR0,r6			/* arg 4 (kentry) */
+	mfmsr	r11
+	li	r12,MSR_IS | MSR_DS
+	andc	r11,r11,r12
+	mtspr	SPRN_SRR1,r11
+	rfi
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 074ff12..8ba962e 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -49,6 +49,7 @@ config 44x
 	select 4xx_SOC
 	select PPC_PCI_CHOICE
 	select PHYS_64BIT
+	select ARCH_SUPPORTS_LITTLE_ENDIAN
 
 config E200
 	bool "Freescale e200"
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
                   ` (3 preceding siblings ...)
  2010-10-01  7:05   ` Ian Munsie
@ 2010-10-01  7:05 ` Ian Munsie
  2010-10-01 11:27     ` Josh Boyer
  2010-10-01  7:05   ` Ian Munsie
                   ` (14 subsequent siblings)
  19 siblings, 1 reply; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh; +Cc: paulus, Ian Munsie

From: Ian Munsie <imunsie@au1.ibm.com>

I haven't tested booting a little endian kernel on any of these targets,
but they all claim to be 44x so my little endian trampoline should work
on all of them, so wire it up on:

bamboo
katmai
kilauea
rainer
sam440ep
sequoia
warp
yosemite
ebony

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/boot/bamboo.c          |    1 +
 arch/powerpc/boot/cuboot-katmai.c   |    1 +
 arch/powerpc/boot/cuboot-kilauea.c  |    1 +
 arch/powerpc/boot/cuboot-rainier.c  |    1 +
 arch/powerpc/boot/cuboot-sam440ep.c |    1 +
 arch/powerpc/boot/cuboot-sequoia.c  |    1 +
 arch/powerpc/boot/cuboot-warp.c     |    1 +
 arch/powerpc/boot/cuboot-yosemite.c |    1 +
 arch/powerpc/boot/ebony.c           |    1 +
 9 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/bamboo.c b/arch/powerpc/boot/bamboo.c
index b82cacb..547494b 100644
--- a/arch/powerpc/boot/bamboo.c
+++ b/arch/powerpc/boot/bamboo.c
@@ -41,6 +41,7 @@ void bamboo_init(void *mac0, void *mac1)
 {
 	platform_ops.fixups = bamboo_fixups;
 	platform_ops.exit = ibm44x_dbcr_reset;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	bamboo_mac0 = mac0;
 	bamboo_mac1 = mac1;
 	fdt_init(_dtb_start);
diff --git a/arch/powerpc/boot/cuboot-katmai.c b/arch/powerpc/boot/cuboot-katmai.c
index 5434d70..c72bdbf 100644
--- a/arch/powerpc/boot/cuboot-katmai.c
+++ b/arch/powerpc/boot/cuboot-katmai.c
@@ -52,6 +52,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 	CUBOOT_INIT();
 
 	platform_ops.fixups = katmai_fixups;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	fdt_init(_dtb_start);
 	serial_console_init();
 }
diff --git a/arch/powerpc/boot/cuboot-kilauea.c b/arch/powerpc/boot/cuboot-kilauea.c
index 80cdad6..115048a 100644
--- a/arch/powerpc/boot/cuboot-kilauea.c
+++ b/arch/powerpc/boot/cuboot-kilauea.c
@@ -44,6 +44,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 	CUBOOT_INIT();
 	platform_ops.fixups = kilauea_fixups;
 	platform_ops.exit = ibm40x_dbcr_reset;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	fdt_init(_dtb_start);
 	serial_console_init();
 }
diff --git a/arch/powerpc/boot/cuboot-rainier.c b/arch/powerpc/boot/cuboot-rainier.c
index 0a3fdde..7c1ad02 100644
--- a/arch/powerpc/boot/cuboot-rainier.c
+++ b/arch/powerpc/boot/cuboot-rainier.c
@@ -52,6 +52,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 	CUBOOT_INIT();
 	platform_ops.fixups = rainier_fixups;
 	platform_ops.exit = ibm44x_dbcr_reset;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	fdt_init(_dtb_start);
 	serial_console_init();
 }
diff --git a/arch/powerpc/boot/cuboot-sam440ep.c b/arch/powerpc/boot/cuboot-sam440ep.c
index ec10a47..60761fd 100644
--- a/arch/powerpc/boot/cuboot-sam440ep.c
+++ b/arch/powerpc/boot/cuboot-sam440ep.c
@@ -44,6 +44,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 	CUBOOT_INIT();
 	platform_ops.fixups = sam440ep_fixups;
 	platform_ops.exit = ibm44x_dbcr_reset;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	fdt_init(_dtb_start);
 	serial_console_init();
 }
diff --git a/arch/powerpc/boot/cuboot-sequoia.c b/arch/powerpc/boot/cuboot-sequoia.c
index caf8f2e..3e93748 100644
--- a/arch/powerpc/boot/cuboot-sequoia.c
+++ b/arch/powerpc/boot/cuboot-sequoia.c
@@ -52,6 +52,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 	CUBOOT_INIT();
 	platform_ops.fixups = sequoia_fixups;
 	platform_ops.exit = ibm44x_dbcr_reset;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	fdt_init(_dtb_start);
 	serial_console_init();
 }
diff --git a/arch/powerpc/boot/cuboot-warp.c b/arch/powerpc/boot/cuboot-warp.c
index 806df69..8bdc383 100644
--- a/arch/powerpc/boot/cuboot-warp.c
+++ b/arch/powerpc/boot/cuboot-warp.c
@@ -33,6 +33,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 
 	platform_ops.fixups = warp_fixups;
 	platform_ops.exit = ibm44x_dbcr_reset;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	fdt_init(_dtb_start);
 	serial_console_init();
 }
diff --git a/arch/powerpc/boot/cuboot-yosemite.c b/arch/powerpc/boot/cuboot-yosemite.c
index cc6e338..7fe0e05 100644
--- a/arch/powerpc/boot/cuboot-yosemite.c
+++ b/arch/powerpc/boot/cuboot-yosemite.c
@@ -39,6 +39,7 @@ void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
 	CUBOOT_INIT();
 	platform_ops.fixups = yosemite_fixups;
 	platform_ops.exit = ibm44x_dbcr_reset;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	fdt_init(_dtb_start);
 	serial_console_init();
 }
diff --git a/arch/powerpc/boot/ebony.c b/arch/powerpc/boot/ebony.c
index 5532ab3..6f302aa 100644
--- a/arch/powerpc/boot/ebony.c
+++ b/arch/powerpc/boot/ebony.c
@@ -85,6 +85,7 @@ void ebony_init(void *mac0, void *mac1)
 {
 	platform_ops.fixups = ebony_fixups;
 	platform_ops.exit = ibm44x_dbcr_reset;
+	platform_ops.le_kentry = ibm44x_le_kentry;
 	ebony_mac0 = mac0;
 	ebony_mac1 = mac1;
 	fdt_init(_dtb_start);
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 06/18] powerpc 44x: Set E bit in TLBs and PTEs when CPU is in little endian mode
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:05   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Torez Smith, Dave Kleikamp, Josh Boyer,
	Stephen Rothwell

From: Ian Munsie <imunsie@au1.ibm.com>

The endianness on the 44x CPUs is controlled by the E bit in the TLB
entries. If the kernel has been compiled for little endian this patch
sets this E bit wherever they are set - in the PTE base flags, the early
debugging, and TLB pinning.

It defines some _PAGE_CPUENDIAN and ..._TLB_CPUE macros which are set
if the CPU is little endian or 0 if the CPU is big endian so these can
be used to easily set the E bit only if the CPU is little endian.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/include/asm/mmu-44x.h    |   12 ++++++++++++
 arch/powerpc/include/asm/pte-44x.h    |    4 ++++
 arch/powerpc/include/asm/pte-common.h |    9 ++++++---
 arch/powerpc/kernel/head_44x.S        |    6 +++---
 arch/powerpc/mm/44x_mmu.c             |    4 ++--
 5 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu-44x.h b/arch/powerpc/include/asm/mmu-44x.h
index bf52d70..e96f5c3 100644
--- a/arch/powerpc/include/asm/mmu-44x.h
+++ b/arch/powerpc/include/asm/mmu-44x.h
@@ -42,6 +42,12 @@
 #define PPC44x_TLB_G		0x00000100      /* Memory is guarded */
 #define PPC44x_TLB_E		0x00000080      /* Memory is little endian */
 
+#ifdef __LITTLE_ENDIAN__
+#define PPC44x_TLB_CPUE		PPC44x_TLB_E
+#else
+#define PPC44x_TLB_CPUE		0
+#endif
+
 #define PPC44x_TLB_PERM_MASK	0x0000003f
 #define PPC44x_TLB_UX		0x00000020      /* User execution */
 #define PPC44x_TLB_UW		0x00000010      /* User write */
@@ -99,6 +105,12 @@
 #define PPC47x_TLB2_S_RW	(PPC47x_TLB2_SW | PPC47x_TLB2_SR)
 #define PPC47x_TLB2_IMG		(PPC47x_TLB2_I | PPC47x_TLB2_M | PPC47x_TLB2_G)
 
+#ifdef __LITTLE_ENDIAN__
+#define PPC47x_TLB2_CPUE	PPC47x_TLB2_E
+#else
+#define PPC47x_TLB2_CPUE	0
+#endif
+
 #ifndef __ASSEMBLY__
 
 extern unsigned int tlb_44x_hwater;
diff --git a/arch/powerpc/include/asm/pte-44x.h b/arch/powerpc/include/asm/pte-44x.h
index 4192b9b..9c79a85 100644
--- a/arch/powerpc/include/asm/pte-44x.h
+++ b/arch/powerpc/include/asm/pte-44x.h
@@ -89,6 +89,10 @@
 #define _PAGE_NO_CACHE	0x00000400		/* H: I bit */
 #define _PAGE_WRITETHRU	0x00000800		/* H: W bit */
 
+#ifdef __LITTLE_ENDIAN__
+#define _PAGE_CPUENDIAN	_PAGE_ENDIAN
+#endif
+
 /* TODO: Add large page lowmem mapping support */
 #define _PMD_PRESENT	0
 #define _PMD_PRESENT_MASK (PAGE_MASK)
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index f2b3701..b69609c 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -19,6 +19,9 @@
 #ifndef _PAGE_ENDIAN
 #define _PAGE_ENDIAN	0
 #endif
+#ifndef _PAGE_CPUENDIAN
+#define _PAGE_CPUENDIAN	0
+#endif
 #ifndef _PAGE_COHERENT
 #define _PAGE_COHERENT	0
 #endif
@@ -104,11 +107,11 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
  * pages. We always set _PAGE_COHERENT when SMP is enabled or
  * the processor might need it for DMA coherency.
  */
-#define _PAGE_BASE_NC	(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_PSIZE)
+#define _PAGE_BASE_NC	(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_PSIZE | _PAGE_CPUENDIAN)
 #if defined(CONFIG_SMP) || defined(CONFIG_PPC_STD_MMU)
-#define _PAGE_BASE	(_PAGE_BASE_NC | _PAGE_COHERENT)
+#define _PAGE_BASE	(_PAGE_BASE_NC | _PAGE_COHERENT | _PAGE_CPUENDIAN)
 #else
-#define _PAGE_BASE	(_PAGE_BASE_NC)
+#define _PAGE_BASE	(_PAGE_BASE_NC | _PAGE_CPUENDIAN)
 #endif
 
 /* Permission masks used to generate the __P and __S table,
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 562305b..6198733 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -813,7 +813,7 @@ skpinv:	addi	r4,r4,1				/* Increment */
 	/* attrib fields */
 	/* Added guarded bit to protect against speculative loads/stores */
 	li	r5,0
-	ori	r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G)
+	ori	r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G | PPC44x_TLB_CPUE)
 
         li      r0,63                    /* TLB slot 63 */
 
@@ -850,7 +850,7 @@ skpinv:	addi	r4,r4,1				/* Increment */
 	ori	r4,r4,CONFIG_PPC_EARLY_DEBUG_44x_PHYSHIGH
 
 	/* attrib fields */
-	li	r5,(PPC44x_TLB_SW|PPC44x_TLB_SR|PPC44x_TLB_I|PPC44x_TLB_G)
+	li	r5,(PPC44x_TLB_SW|PPC44x_TLB_SR|PPC44x_TLB_I|PPC44x_TLB_G|PPC44x_TLB_CPUE)
         li      r0,62                    /* TLB slot 0 */
 
 	tlbwe	r3,r0,PPC44x_TLB_PAGEID
@@ -1068,7 +1068,7 @@ clear_utlb_entry:
 	ori	r4,r4,CONFIG_PPC_EARLY_DEBUG_44x_PHYSHIGH
 
 	/* Word 2 */
-	li	r5,(PPC47x_TLB2_S_RW | PPC47x_TLB2_IMG)
+	li	r5,(PPC47x_TLB2_S_RW | PPC47x_TLB2_IMG | PPC47x_TLB2_CPUE)
 
 	/* Bolted in way 0, bolt slot 5, we -hope- we don't hit the same
 	 * congruence class as the kernel, we need to make sure of it at
diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
index d8c6efb..70760e7 100644
--- a/arch/powerpc/mm/44x_mmu.c
+++ b/arch/powerpc/mm/44x_mmu.c
@@ -79,7 +79,7 @@ static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys)
 #ifdef CONFIG_PPC47x
 	: "r" (PPC47x_TLB2_S_RWX),
 #else
-	: "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
+	: "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G | PPC44x_TLB_CPUE),
 #endif
 	  "r" (phys),
 	  "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
@@ -163,7 +163,7 @@ static void __cpuinit ppc47x_pin_tlb(unsigned int virt, unsigned int phys)
 		"tlbwe	%0,%3,2\n"
 		:
 		: "r" (PPC47x_TLB2_SW | PPC47x_TLB2_SR |
-		       PPC47x_TLB2_SX
+		       PPC47x_TLB2_SX |  PPC47x_TLB2_CPUE
 #ifdef CONFIG_SMP
 		       | PPC47x_TLB2_M
 #endif
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 06/18] powerpc 44x: Set E bit in TLBs and PTEs when CPU is in little endian mode
@ 2010-10-01  7:05   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:05 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Stephen Rothwell, Dave Kleikamp, Ian Munsie, paulus, Torez Smith

From: Ian Munsie <imunsie@au1.ibm.com>

The endianness on the 44x CPUs is controlled by the E bit in the TLB
entries. If the kernel has been compiled for little endian this patch
sets this E bit wherever they are set - in the PTE base flags, the early
debugging, and TLB pinning.

It defines some _PAGE_CPUENDIAN and ..._TLB_CPUE macros which are set
if the CPU is little endian or 0 if the CPU is big endian so these can
be used to easily set the E bit only if the CPU is little endian.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/include/asm/mmu-44x.h    |   12 ++++++++++++
 arch/powerpc/include/asm/pte-44x.h    |    4 ++++
 arch/powerpc/include/asm/pte-common.h |    9 ++++++---
 arch/powerpc/kernel/head_44x.S        |    6 +++---
 arch/powerpc/mm/44x_mmu.c             |    4 ++--
 5 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu-44x.h b/arch/powerpc/include/asm/mmu-44x.h
index bf52d70..e96f5c3 100644
--- a/arch/powerpc/include/asm/mmu-44x.h
+++ b/arch/powerpc/include/asm/mmu-44x.h
@@ -42,6 +42,12 @@
 #define PPC44x_TLB_G		0x00000100      /* Memory is guarded */
 #define PPC44x_TLB_E		0x00000080      /* Memory is little endian */
 
+#ifdef __LITTLE_ENDIAN__
+#define PPC44x_TLB_CPUE		PPC44x_TLB_E
+#else
+#define PPC44x_TLB_CPUE		0
+#endif
+
 #define PPC44x_TLB_PERM_MASK	0x0000003f
 #define PPC44x_TLB_UX		0x00000020      /* User execution */
 #define PPC44x_TLB_UW		0x00000010      /* User write */
@@ -99,6 +105,12 @@
 #define PPC47x_TLB2_S_RW	(PPC47x_TLB2_SW | PPC47x_TLB2_SR)
 #define PPC47x_TLB2_IMG		(PPC47x_TLB2_I | PPC47x_TLB2_M | PPC47x_TLB2_G)
 
+#ifdef __LITTLE_ENDIAN__
+#define PPC47x_TLB2_CPUE	PPC47x_TLB2_E
+#else
+#define PPC47x_TLB2_CPUE	0
+#endif
+
 #ifndef __ASSEMBLY__
 
 extern unsigned int tlb_44x_hwater;
diff --git a/arch/powerpc/include/asm/pte-44x.h b/arch/powerpc/include/asm/pte-44x.h
index 4192b9b..9c79a85 100644
--- a/arch/powerpc/include/asm/pte-44x.h
+++ b/arch/powerpc/include/asm/pte-44x.h
@@ -89,6 +89,10 @@
 #define _PAGE_NO_CACHE	0x00000400		/* H: I bit */
 #define _PAGE_WRITETHRU	0x00000800		/* H: W bit */
 
+#ifdef __LITTLE_ENDIAN__
+#define _PAGE_CPUENDIAN	_PAGE_ENDIAN
+#endif
+
 /* TODO: Add large page lowmem mapping support */
 #define _PMD_PRESENT	0
 #define _PMD_PRESENT_MASK (PAGE_MASK)
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index f2b3701..b69609c 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -19,6 +19,9 @@
 #ifndef _PAGE_ENDIAN
 #define _PAGE_ENDIAN	0
 #endif
+#ifndef _PAGE_CPUENDIAN
+#define _PAGE_CPUENDIAN	0
+#endif
 #ifndef _PAGE_COHERENT
 #define _PAGE_COHERENT	0
 #endif
@@ -104,11 +107,11 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
  * pages. We always set _PAGE_COHERENT when SMP is enabled or
  * the processor might need it for DMA coherency.
  */
-#define _PAGE_BASE_NC	(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_PSIZE)
+#define _PAGE_BASE_NC	(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_PSIZE | _PAGE_CPUENDIAN)
 #if defined(CONFIG_SMP) || defined(CONFIG_PPC_STD_MMU)
-#define _PAGE_BASE	(_PAGE_BASE_NC | _PAGE_COHERENT)
+#define _PAGE_BASE	(_PAGE_BASE_NC | _PAGE_COHERENT | _PAGE_CPUENDIAN)
 #else
-#define _PAGE_BASE	(_PAGE_BASE_NC)
+#define _PAGE_BASE	(_PAGE_BASE_NC | _PAGE_CPUENDIAN)
 #endif
 
 /* Permission masks used to generate the __P and __S table,
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 562305b..6198733 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -813,7 +813,7 @@ skpinv:	addi	r4,r4,1				/* Increment */
 	/* attrib fields */
 	/* Added guarded bit to protect against speculative loads/stores */
 	li	r5,0
-	ori	r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G)
+	ori	r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G | PPC44x_TLB_CPUE)
 
         li      r0,63                    /* TLB slot 63 */
 
@@ -850,7 +850,7 @@ skpinv:	addi	r4,r4,1				/* Increment */
 	ori	r4,r4,CONFIG_PPC_EARLY_DEBUG_44x_PHYSHIGH
 
 	/* attrib fields */
-	li	r5,(PPC44x_TLB_SW|PPC44x_TLB_SR|PPC44x_TLB_I|PPC44x_TLB_G)
+	li	r5,(PPC44x_TLB_SW|PPC44x_TLB_SR|PPC44x_TLB_I|PPC44x_TLB_G|PPC44x_TLB_CPUE)
         li      r0,62                    /* TLB slot 0 */
 
 	tlbwe	r3,r0,PPC44x_TLB_PAGEID
@@ -1068,7 +1068,7 @@ clear_utlb_entry:
 	ori	r4,r4,CONFIG_PPC_EARLY_DEBUG_44x_PHYSHIGH
 
 	/* Word 2 */
-	li	r5,(PPC47x_TLB2_S_RW | PPC47x_TLB2_IMG)
+	li	r5,(PPC47x_TLB2_S_RW | PPC47x_TLB2_IMG | PPC47x_TLB2_CPUE)
 
 	/* Bolted in way 0, bolt slot 5, we -hope- we don't hit the same
 	 * congruence class as the kernel, we need to make sure of it at
diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
index d8c6efb..70760e7 100644
--- a/arch/powerpc/mm/44x_mmu.c
+++ b/arch/powerpc/mm/44x_mmu.c
@@ -79,7 +79,7 @@ static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys)
 #ifdef CONFIG_PPC47x
 	: "r" (PPC47x_TLB2_S_RWX),
 #else
-	: "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
+	: "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G | PPC44x_TLB_CPUE),
 #endif
 	  "r" (phys),
 	  "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
@@ -163,7 +163,7 @@ static void __cpuinit ppc47x_pin_tlb(unsigned int virt, unsigned int phys)
 		"tlbwe	%0,%3,2\n"
 		:
 		: "r" (PPC47x_TLB2_SW | PPC47x_TLB2_SR |
-		       PPC47x_TLB2_SX
+		       PPC47x_TLB2_SX |  PPC47x_TLB2_CPUE
 #ifdef CONFIG_SMP
 		       | PPC47x_TLB2_M
 #endif
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 07/18] powerpc: Use generic bitops for little endian bitmap operations
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
                   ` (5 preceding siblings ...)
  2010-10-01  7:05   ` Ian Munsie
@ 2010-10-01  7:06 ` Ian Munsie
  2010-10-01  7:06 ` [PATCH 08/18] powerpc: Include the appropriate endianness header Ian Munsie
                   ` (12 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh; +Cc: paulus, Ian Munsie, Anton Blanchard

From: Ian Munsie <imunsie@au1.ibm.com>

With the little endian PowerPC Linux port, the CPU could be in either
mode. Rather than byte swapping and mapping the little endian bitmap
operations ourselves on the assumption that we are big endian, map them
to the generic macros that will automatically byte swap the bit number
only if we actually are big endian.

The generic bitops le.h already defines the macros/prototypes for the
generic_find_next_[zero_]le_bit appropriately for the current endian so
we can drop those prototypes altogether.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/include/asm/bitops.h |   30 ++++++++++++------------------
 1 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
index 30964ae..066b2df 100644
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -54,7 +54,6 @@
 
 #define BITOP_MASK(nr)		(1UL << ((nr) % BITS_PER_LONG))
 #define BITOP_WORD(nr)		((nr) / BITS_PER_LONG)
-#define BITOP_LE_SWIZZLE	((BITS_PER_LONG-1) & ~0x7)
 
 /* Macro for generating the ***_bits() functions */
 #define DEFINE_BITOP(fn, op, prefix, postfix)	\
@@ -272,34 +271,29 @@ static __inline__ int fls64(__u64 x)
 
 /* Little-endian versions */
 
-static __inline__ int test_le_bit(unsigned long nr,
-				  __const__ unsigned long *addr)
-{
-	__const__ unsigned char	*tmp = (__const__ unsigned char *) addr;
-	return (tmp[nr >> 3] >> (nr & 7)) & 1;
-}
+#include <asm-generic/bitops/le.h>
+
+#define test_le_bit(nr, addr) \
+	generic_test_le_bit(nr, addr)
 
 #define __set_le_bit(nr, addr) \
-	__set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
+	generic__set_le_bit(nr, addr)
 #define __clear_le_bit(nr, addr) \
-	__clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
+	generic__clear_le_bit(nr, addr)
 
 #define test_and_set_le_bit(nr, addr) \
-	test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
+	generic_test_and_set_le_bit(nr, addr)
 #define test_and_clear_le_bit(nr, addr) \
-	test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
+	generic_test_and_clear_le_bit(nr, addr)
 
 #define __test_and_set_le_bit(nr, addr) \
-	__test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
+	generic__test_and_set_le_bit(nr, addr)
 #define __test_and_clear_le_bit(nr, addr) \
-	__test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
+	generic__test_and_clear_le_bit(nr, addr)
 
-#define find_first_zero_le_bit(addr, size) generic_find_next_zero_le_bit((addr), (size), 0)
-unsigned long generic_find_next_zero_le_bit(const unsigned long *addr,
-				    unsigned long size, unsigned long offset);
+#define find_first_zero_le_bit(addr, size) \
+	generic_find_first_zero_le_bit(addr, size)
 
-unsigned long generic_find_next_le_bit(const unsigned long *addr,
-				    unsigned long size, unsigned long offset);
 /* Bitmap functions for the ext2 filesystem */
 
 #define ext2_set_bit(nr,addr) \
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 08/18] powerpc: Include the appropriate endianness header
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
                   ` (6 preceding siblings ...)
  2010-10-01  7:06 ` [PATCH 07/18] powerpc: Use generic bitops for little endian bitmap operations Ian Munsie
@ 2010-10-01  7:06 ` Ian Munsie
  2010-10-01  7:06   ` Ian Munsie
                   ` (11 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh; +Cc: paulus, Ian Munsie

From: Ian Munsie <imunsie@au1.ibm.com>

This patch will have powerpc include the appropriate generic endianness
header depending on what the compiler reports.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/include/asm/byteorder.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/byteorder.h b/arch/powerpc/include/asm/byteorder.h
index aa6cc4f..ca931d0 100644
--- a/arch/powerpc/include/asm/byteorder.h
+++ b/arch/powerpc/include/asm/byteorder.h
@@ -7,6 +7,10 @@
  * as published by the Free Software Foundation; either version
  * 2 of the License, or (at your option) any later version.
  */
+#ifdef __LITTLE_ENDIAN__
+#include <linux/byteorder/little_endian.h>
+#else
 #include <linux/byteorder/big_endian.h>
+#endif
 
 #endif /* _ASM_POWERPC_BYTEORDER_H */
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 09/18] powerpc: Support device tree regardless of CPU endianness
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:06   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Grant Likely, Wolfram Sang, Michal Simek,
	Jeremy Kerr, devicetree-discuss

From: Ian Munsie <imunsie@au1.ibm.com>

On PowerPC the device tree is always big endian, but the CPU could be
either, so add be32_to_cpu where appropriate and change the types of
device tree data to __be32 etc to allow sparse to locate endian issues.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/kernel/prom.c |   60 ++++++++++++++++++++++----------------------
 1 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fed9bf6..9b9ebb2 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -188,16 +188,16 @@ static void __init check_cpu_pa_features(unsigned long node)
 #ifdef CONFIG_PPC_STD_MMU_64
 static void __init check_cpu_slb_size(unsigned long node)
 {
-	u32 *slb_size_ptr;
+	__be32 *slb_size_ptr;
 
 	slb_size_ptr = of_get_flat_dt_prop(node, "slb-size", NULL);
 	if (slb_size_ptr != NULL) {
-		mmu_slb_size = *slb_size_ptr;
+		mmu_slb_size = be32_to_cpup(slb_size_ptr);
 		return;
 	}
 	slb_size_ptr = of_get_flat_dt_prop(node, "ibm,slb-size", NULL);
 	if (slb_size_ptr != NULL) {
-		mmu_slb_size = *slb_size_ptr;
+		mmu_slb_size = be32_to_cpup(slb_size_ptr);
 	}
 }
 #else
@@ -252,11 +252,11 @@ static void __init check_cpu_feature_properties(unsigned long node)
 {
 	unsigned long i;
 	struct feature_property *fp = feature_properties;
-	const u32 *prop;
+	const __be32 *prop;
 
 	for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
 		prop = of_get_flat_dt_prop(node, fp->name, NULL);
-		if (prop && *prop >= fp->min_value) {
+		if (prop && be32_to_cpup(prop) >= fp->min_value) {
 			cur_cpu_spec->cpu_features |= fp->cpu_feature;
 			cur_cpu_spec->cpu_user_features |= fp->cpu_user_ftr;
 		}
@@ -269,8 +269,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
 {
 	static int logical_cpuid = 0;
 	char *type = of_get_flat_dt_prop(node, "device_type", NULL);
-	const u32 *prop;
-	const u32 *intserv;
+	const __be32 *prop;
+	const __be32 *intserv;
 	int i, nthreads;
 	unsigned long len;
 	int found = 0;
@@ -297,9 +297,9 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
 		 * version 2 of the kexec param format adds the phys cpuid of
 		 * booted proc.
 		 */
-		if (initial_boot_params && initial_boot_params->version >= 2) {
-			if (intserv[i] ==
-					initial_boot_params->boot_cpuid_phys) {
+		if (initial_boot_params && be32_to_cpu(initial_boot_params->version) >= 2) {
+			if (be32_to_cpu(intserv[i]) ==
+					be32_to_cpu(initial_boot_params->boot_cpuid_phys)) {
 				found = 1;
 				break;
 			}
@@ -324,9 +324,9 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
 
 	if (found) {
 		DBG("boot cpu: logical %d physical %d\n", logical_cpuid,
-			intserv[i]);
+			be32_to_cpu(intserv[i]));
 		boot_cpuid = logical_cpuid;
-		set_hard_smp_processor_id(boot_cpuid, intserv[i]);
+		set_hard_smp_processor_id(boot_cpuid, be32_to_cpu(intserv[i]));
 
 		/*
 		 * PAPR defines "logical" PVR values for cpus that
@@ -343,8 +343,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
 		 * it uses 0x0f000001.
 		 */
 		prop = of_get_flat_dt_prop(node, "cpu-version", NULL);
-		if (prop && (*prop & 0xff000000) == 0x0f000000)
-			identify_cpu(0, *prop);
+		if (prop && (be32_to_cpup(prop) & 0xff000000) == 0x0f000000)
+			identify_cpu(0, be32_to_cpup(prop));
 
 		identical_pvr_fixup(node);
 	}
@@ -365,7 +365,7 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
 
 void __init early_init_dt_scan_chosen_arch(unsigned long node)
 {
-	unsigned long *lprop;
+	unsigned long *lprop; /* All these set by kernel, so no need to convert endian */
 
 #ifdef CONFIG_PPC64
 	/* check if iommu is forced on or off */
@@ -524,16 +524,16 @@ void __init early_init_dt_setup_initrd_arch(unsigned long start,
 static void __init early_reserve_mem(void)
 {
 	u64 base, size;
-	u64 *reserve_map;
+	__be64 *reserve_map;
 	unsigned long self_base;
 	unsigned long self_size;
 
-	reserve_map = (u64 *)(((unsigned long)initial_boot_params) +
-					initial_boot_params->off_mem_rsvmap);
+	reserve_map = (__be64 *)(((unsigned long)initial_boot_params) +
+			be32_to_cpu(initial_boot_params->off_mem_rsvmap));
 
 	/* before we do anything, lets reserve the dt blob */
 	self_base = __pa((unsigned long)initial_boot_params);
-	self_size = initial_boot_params->totalsize;
+	self_size = be32_to_cpu(initial_boot_params->totalsize);
 	memblock_reserve(self_base, self_size);
 
 #ifdef CONFIG_BLK_DEV_INITRD
@@ -547,13 +547,13 @@ static void __init early_reserve_mem(void)
 	 * Handle the case where we might be booting from an old kexec
 	 * image that setup the mem_rsvmap as pairs of 32-bit values
 	 */
-	if (*reserve_map > 0xffffffffull) {
+	if (be64_to_cpup(reserve_map) > 0xffffffffull) {
 		u32 base_32, size_32;
-		u32 *reserve_map_32 = (u32 *)reserve_map;
+		__be32 *reserve_map_32 = (__be32 *)reserve_map;
 
 		while (1) {
-			base_32 = *(reserve_map_32++);
-			size_32 = *(reserve_map_32++);
+			base_32 = be32_to_cpup(reserve_map_32++);
+			size_32 = be32_to_cpup(reserve_map_32++);
 			if (size_32 == 0)
 				break;
 			/* skip if the reservation is for the blob */
@@ -566,8 +566,8 @@ static void __init early_reserve_mem(void)
 	}
 #endif
 	while (1) {
-		base = *(reserve_map++);
-		size = *(reserve_map++);
+		base = be64_to_cpup(reserve_map++);
+		size = be64_to_cpup(reserve_map++);
 		if (size == 0)
 			break;
 		DBG("reserving: %llx -> %llx\n", base, size);
@@ -860,7 +860,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
 	hardid = get_hard_smp_processor_id(cpu);
 
 	for_each_node_by_type(np, "cpu") {
-		const u32 *intserv;
+		const __be32 *intserv;
 		unsigned int plen, t;
 
 		/* Check for ibm,ppc-interrupt-server#s. If it doesn't exist
@@ -869,10 +869,10 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
 		intserv = of_get_property(np, "ibm,ppc-interrupt-server#s",
 				&plen);
 		if (intserv == NULL) {
-			const u32 *reg = of_get_property(np, "reg", NULL);
+			const __be32 *reg = of_get_property(np, "reg", NULL);
 			if (reg == NULL)
 				continue;
-			if (*reg == hardid) {
+			if (be32_to_cpup(reg) == hardid) {
 				if (thread)
 					*thread = 0;
 				return np;
@@ -880,7 +880,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
 		} else {
 			plen /= sizeof(u32);
 			for (t = 0; t < plen; t++) {
-				if (hardid == intserv[t]) {
+				if (hardid == be32_to_cpu(intserv[t])) {
 					if (thread)
 						*thread = t;
 					return np;
@@ -900,7 +900,7 @@ static int __init export_flat_device_tree(void)
 	struct dentry *d;
 
 	flat_dt_blob.data = initial_boot_params;
-	flat_dt_blob.size = initial_boot_params->totalsize;
+	flat_dt_blob.size = be32_to_cpu(initial_boot_params->totalsize);
 
 	d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
 				powerpc_debugfs_root, &flat_dt_blob);
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 09/18] powerpc: Support device tree regardless of CPU endianness
@ 2010-10-01  7:06   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Michal Simek, devicetree-discuss, paulus, Ian Munsie, Jeremy Kerr

From: Ian Munsie <imunsie@au1.ibm.com>

On PowerPC the device tree is always big endian, but the CPU could be
either, so add be32_to_cpu where appropriate and change the types of
device tree data to __be32 etc to allow sparse to locate endian issues.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/kernel/prom.c |   60 ++++++++++++++++++++++----------------------
 1 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fed9bf6..9b9ebb2 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -188,16 +188,16 @@ static void __init check_cpu_pa_features(unsigned long node)
 #ifdef CONFIG_PPC_STD_MMU_64
 static void __init check_cpu_slb_size(unsigned long node)
 {
-	u32 *slb_size_ptr;
+	__be32 *slb_size_ptr;
 
 	slb_size_ptr = of_get_flat_dt_prop(node, "slb-size", NULL);
 	if (slb_size_ptr != NULL) {
-		mmu_slb_size = *slb_size_ptr;
+		mmu_slb_size = be32_to_cpup(slb_size_ptr);
 		return;
 	}
 	slb_size_ptr = of_get_flat_dt_prop(node, "ibm,slb-size", NULL);
 	if (slb_size_ptr != NULL) {
-		mmu_slb_size = *slb_size_ptr;
+		mmu_slb_size = be32_to_cpup(slb_size_ptr);
 	}
 }
 #else
@@ -252,11 +252,11 @@ static void __init check_cpu_feature_properties(unsigned long node)
 {
 	unsigned long i;
 	struct feature_property *fp = feature_properties;
-	const u32 *prop;
+	const __be32 *prop;
 
 	for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
 		prop = of_get_flat_dt_prop(node, fp->name, NULL);
-		if (prop && *prop >= fp->min_value) {
+		if (prop && be32_to_cpup(prop) >= fp->min_value) {
 			cur_cpu_spec->cpu_features |= fp->cpu_feature;
 			cur_cpu_spec->cpu_user_features |= fp->cpu_user_ftr;
 		}
@@ -269,8 +269,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
 {
 	static int logical_cpuid = 0;
 	char *type = of_get_flat_dt_prop(node, "device_type", NULL);
-	const u32 *prop;
-	const u32 *intserv;
+	const __be32 *prop;
+	const __be32 *intserv;
 	int i, nthreads;
 	unsigned long len;
 	int found = 0;
@@ -297,9 +297,9 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
 		 * version 2 of the kexec param format adds the phys cpuid of
 		 * booted proc.
 		 */
-		if (initial_boot_params && initial_boot_params->version >= 2) {
-			if (intserv[i] ==
-					initial_boot_params->boot_cpuid_phys) {
+		if (initial_boot_params && be32_to_cpu(initial_boot_params->version) >= 2) {
+			if (be32_to_cpu(intserv[i]) ==
+					be32_to_cpu(initial_boot_params->boot_cpuid_phys)) {
 				found = 1;
 				break;
 			}
@@ -324,9 +324,9 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
 
 	if (found) {
 		DBG("boot cpu: logical %d physical %d\n", logical_cpuid,
-			intserv[i]);
+			be32_to_cpu(intserv[i]));
 		boot_cpuid = logical_cpuid;
-		set_hard_smp_processor_id(boot_cpuid, intserv[i]);
+		set_hard_smp_processor_id(boot_cpuid, be32_to_cpu(intserv[i]));
 
 		/*
 		 * PAPR defines "logical" PVR values for cpus that
@@ -343,8 +343,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
 		 * it uses 0x0f000001.
 		 */
 		prop = of_get_flat_dt_prop(node, "cpu-version", NULL);
-		if (prop && (*prop & 0xff000000) == 0x0f000000)
-			identify_cpu(0, *prop);
+		if (prop && (be32_to_cpup(prop) & 0xff000000) == 0x0f000000)
+			identify_cpu(0, be32_to_cpup(prop));
 
 		identical_pvr_fixup(node);
 	}
@@ -365,7 +365,7 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
 
 void __init early_init_dt_scan_chosen_arch(unsigned long node)
 {
-	unsigned long *lprop;
+	unsigned long *lprop; /* All these set by kernel, so no need to convert endian */
 
 #ifdef CONFIG_PPC64
 	/* check if iommu is forced on or off */
@@ -524,16 +524,16 @@ void __init early_init_dt_setup_initrd_arch(unsigned long start,
 static void __init early_reserve_mem(void)
 {
 	u64 base, size;
-	u64 *reserve_map;
+	__be64 *reserve_map;
 	unsigned long self_base;
 	unsigned long self_size;
 
-	reserve_map = (u64 *)(((unsigned long)initial_boot_params) +
-					initial_boot_params->off_mem_rsvmap);
+	reserve_map = (__be64 *)(((unsigned long)initial_boot_params) +
+			be32_to_cpu(initial_boot_params->off_mem_rsvmap));
 
 	/* before we do anything, lets reserve the dt blob */
 	self_base = __pa((unsigned long)initial_boot_params);
-	self_size = initial_boot_params->totalsize;
+	self_size = be32_to_cpu(initial_boot_params->totalsize);
 	memblock_reserve(self_base, self_size);
 
 #ifdef CONFIG_BLK_DEV_INITRD
@@ -547,13 +547,13 @@ static void __init early_reserve_mem(void)
 	 * Handle the case where we might be booting from an old kexec
 	 * image that setup the mem_rsvmap as pairs of 32-bit values
 	 */
-	if (*reserve_map > 0xffffffffull) {
+	if (be64_to_cpup(reserve_map) > 0xffffffffull) {
 		u32 base_32, size_32;
-		u32 *reserve_map_32 = (u32 *)reserve_map;
+		__be32 *reserve_map_32 = (__be32 *)reserve_map;
 
 		while (1) {
-			base_32 = *(reserve_map_32++);
-			size_32 = *(reserve_map_32++);
+			base_32 = be32_to_cpup(reserve_map_32++);
+			size_32 = be32_to_cpup(reserve_map_32++);
 			if (size_32 == 0)
 				break;
 			/* skip if the reservation is for the blob */
@@ -566,8 +566,8 @@ static void __init early_reserve_mem(void)
 	}
 #endif
 	while (1) {
-		base = *(reserve_map++);
-		size = *(reserve_map++);
+		base = be64_to_cpup(reserve_map++);
+		size = be64_to_cpup(reserve_map++);
 		if (size == 0)
 			break;
 		DBG("reserving: %llx -> %llx\n", base, size);
@@ -860,7 +860,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
 	hardid = get_hard_smp_processor_id(cpu);
 
 	for_each_node_by_type(np, "cpu") {
-		const u32 *intserv;
+		const __be32 *intserv;
 		unsigned int plen, t;
 
 		/* Check for ibm,ppc-interrupt-server#s. If it doesn't exist
@@ -869,10 +869,10 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
 		intserv = of_get_property(np, "ibm,ppc-interrupt-server#s",
 				&plen);
 		if (intserv == NULL) {
-			const u32 *reg = of_get_property(np, "reg", NULL);
+			const __be32 *reg = of_get_property(np, "reg", NULL);
 			if (reg == NULL)
 				continue;
-			if (*reg == hardid) {
+			if (be32_to_cpup(reg) == hardid) {
 				if (thread)
 					*thread = 0;
 				return np;
@@ -880,7 +880,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
 		} else {
 			plen /= sizeof(u32);
 			for (t = 0; t < plen; t++) {
-				if (hardid == intserv[t]) {
+				if (hardid == be32_to_cpu(intserv[t])) {
 					if (thread)
 						*thread = t;
 					return np;
@@ -900,7 +900,7 @@ static int __init export_flat_device_tree(void)
 	struct dentry *d;
 
 	flat_dt_blob.data = initial_boot_params;
-	flat_dt_blob.size = initial_boot_params->totalsize;
+	flat_dt_blob.size = be32_to_cpu(initial_boot_params->totalsize);
 
 	d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
 				powerpc_debugfs_root, &flat_dt_blob);
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 10/18] powerpc: Support endian agnostic MMIO
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
                   ` (8 preceding siblings ...)
  2010-10-01  7:06   ` Ian Munsie
@ 2010-10-01  7:06 ` Ian Munsie
  2010-10-01  7:06   ` Ian Munsie
                   ` (9 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh; +Cc: paulus, Ian Munsie

From: Ian Munsie <imunsie@au1.ibm.com>

This patch maps the MMIO functions for 32bit PowerPC to their
appropriate instructions depending on CPU endianness.

The macros used to create the corresponding inline functions are also
renamed by this patch. Previously they had BE or LE in their names which
was misleading - they had nothing to do with endianness, but actually
created different instruction forms so their new names reflect the
instruction form they are creating (D-Form and X-Form).

Little endian 64bit PowerPC is not supported, so the lack of mappings
(and corresponding breakage) for that case is intentional to bring the
attention of anyone doing a 64bit little endian port. 64bit big endian
is unaffected.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/include/asm/io.h |   51 ++++++++++++++++++++++++++--------------
 1 files changed, 33 insertions(+), 18 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 001f2f1..fd8e922 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -97,7 +97,7 @@ extern resource_size_t isa_mem_base;
 
 /* gcc 4.0 and older doesn't have 'Z' constraint */
 #if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ == 0)
-#define DEF_MMIO_IN_LE(name, size, insn)				\
+#define DEF_MMIO_IN_X(name, size, insn)				\
 static inline u##size name(const volatile u##size __iomem *addr)	\
 {									\
 	u##size ret;							\
@@ -106,7 +106,7 @@ static inline u##size name(const volatile u##size __iomem *addr)	\
 	return ret;							\
 }
 
-#define DEF_MMIO_OUT_LE(name, size, insn) 				\
+#define DEF_MMIO_OUT_X(name, size, insn) 				\
 static inline void name(volatile u##size __iomem *addr, u##size val)	\
 {									\
 	__asm__ __volatile__("sync;"#insn" %1,0,%2"			\
@@ -114,7 +114,7 @@ static inline void name(volatile u##size __iomem *addr, u##size val)	\
 	IO_SET_SYNC_FLAG();						\
 }
 #else /* newer gcc */
-#define DEF_MMIO_IN_LE(name, size, insn)				\
+#define DEF_MMIO_IN_X(name, size, insn)				\
 static inline u##size name(const volatile u##size __iomem *addr)	\
 {									\
 	u##size ret;							\
@@ -123,7 +123,7 @@ static inline u##size name(const volatile u##size __iomem *addr)	\
 	return ret;							\
 }
 
-#define DEF_MMIO_OUT_LE(name, size, insn) 				\
+#define DEF_MMIO_OUT_X(name, size, insn) 				\
 static inline void name(volatile u##size __iomem *addr, u##size val)	\
 {									\
 	__asm__ __volatile__("sync;"#insn" %1,%y0"			\
@@ -132,7 +132,7 @@ static inline void name(volatile u##size __iomem *addr, u##size val)	\
 }
 #endif
 
-#define DEF_MMIO_IN_BE(name, size, insn)				\
+#define DEF_MMIO_IN_D(name, size, insn)				\
 static inline u##size name(const volatile u##size __iomem *addr)	\
 {									\
 	u##size ret;							\
@@ -141,7 +141,7 @@ static inline u##size name(const volatile u##size __iomem *addr)	\
 	return ret;							\
 }
 
-#define DEF_MMIO_OUT_BE(name, size, insn)				\
+#define DEF_MMIO_OUT_D(name, size, insn)				\
 static inline void name(volatile u##size __iomem *addr, u##size val)	\
 {									\
 	__asm__ __volatile__("sync;"#insn"%U0%X0 %1,%0"			\
@@ -149,22 +149,37 @@ static inline void name(volatile u##size __iomem *addr, u##size val)	\
 	IO_SET_SYNC_FLAG();						\
 }
 
+DEF_MMIO_IN_D(in_8,     8, lbz);
+DEF_MMIO_OUT_D(out_8,   8, stb);
 
-DEF_MMIO_IN_BE(in_8,     8, lbz);
-DEF_MMIO_IN_BE(in_be16, 16, lhz);
-DEF_MMIO_IN_BE(in_be32, 32, lwz);
-DEF_MMIO_IN_LE(in_le16, 16, lhbrx);
-DEF_MMIO_IN_LE(in_le32, 32, lwbrx);
+#ifdef __BIG_ENDIAN__
+DEF_MMIO_IN_D(in_be16, 16, lhz);
+DEF_MMIO_IN_D(in_be32, 32, lwz);
+DEF_MMIO_IN_X(in_le16, 16, lhbrx);
+DEF_MMIO_IN_X(in_le32, 32, lwbrx);
 
-DEF_MMIO_OUT_BE(out_8,     8, stb);
-DEF_MMIO_OUT_BE(out_be16, 16, sth);
-DEF_MMIO_OUT_BE(out_be32, 32, stw);
-DEF_MMIO_OUT_LE(out_le16, 16, sthbrx);
-DEF_MMIO_OUT_LE(out_le32, 32, stwbrx);
+DEF_MMIO_OUT_D(out_be16, 16, sth);
+DEF_MMIO_OUT_D(out_be32, 32, stw);
+DEF_MMIO_OUT_X(out_le16, 16, sthbrx);
+DEF_MMIO_OUT_X(out_le32, 32, stwbrx);
+#else
+DEF_MMIO_IN_X(in_be16, 16, lhbrx);
+DEF_MMIO_IN_X(in_be32, 32, lwbrx);
+DEF_MMIO_IN_D(in_le16, 16, lhz);
+DEF_MMIO_IN_D(in_le32, 32, lwz);
+
+DEF_MMIO_OUT_X(out_be16, 16, sthbrx);
+DEF_MMIO_OUT_X(out_be32, 32, stwbrx);
+DEF_MMIO_OUT_D(out_le16, 16, sth);
+DEF_MMIO_OUT_D(out_le32, 32, stw);
+#endif /* __BIG_ENDIAN */
 
 #ifdef __powerpc64__
-DEF_MMIO_OUT_BE(out_be64, 64, std);
-DEF_MMIO_IN_BE(in_be64, 64, ld);
+
+#ifndef __LITTLE_ENDIAN__
+DEF_MMIO_OUT_D(out_be64, 64, std);
+DEF_MMIO_IN_D(in_be64, 64, ld);
+#endif
 
 /* There is no asm instructions for 64 bits reverse loads and stores */
 static inline u64 in_le64(const volatile u64 __iomem *addr)
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 11/18] powerpc: Make assembly endian agnostic when accessing 64bit values
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:06   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Matthew McClintock, Torez Smith, Kumar Gala,
	Joakim Tjernlund

From: Ian Munsie <imunsie@au1.ibm.com>

The 32bit PowerPC ABI states that when passing arguments and return
values via registers a value of type long long is stored in pairs of
registers as follows:

The lower addressed word is stored in the next available odd numbered
register and the higher addressed value is stored in register+1.

i.e. the values will either be stored in the next available of:
r3/r4, r5/r6, r7/r8 or r9/r10

Since the lower addressed value must be in the lower register number we
have an endianness issue and need to treat this specially in any
assembly that is passed or returns a 64bit value.

This patch introduces some aliases in ppc_asm.h which will select the
appropriate register from the pair depending on the CPU endianness.
There are in the form of r34l for the low word from the r3/r4 pair and
r34h for the high word and so on for the remaining register pairs.

It also introduces p64l and p64h which can be used to select the
appropriate offset whenever loading a 32bit word while referring to the
address of a 64bit value. For instance if r3 contains the address of a
64bit value the following assembly would load the high word into r5 and
the low word into r6 regardless of endianness:
	lwz	r5,p64h(r3)
	lwz	r6,p64l(r3)

Finally, the patch also alters the functions in misc_32.S that take
64bit arguments to use these new accessors to work on the little endian
PowerPC architecture:

mulhdu, __div64_32, __ashrdi3, __ashldi3, __lshrdi3 and __ucmpdi2

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/include/asm/ppc_asm.h |   24 ++++++++++++
 arch/powerpc/kernel/misc_32.S      |   72 ++++++++++++++++++------------------
 arch/powerpc/lib/div64.S           |    8 ++--
 3 files changed, 64 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
index 9821006..6929483 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -510,6 +510,30 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
 #define	r30	30
 #define	r31	31
 
+/* Endian agnostic accessors for 64 bit values passed and returned in GPRs */
+#ifdef __BIG_ENDIAN__
+#define r34l	r4
+#define r34h	r3
+#define r56l	r6
+#define r56h	r5
+#define r78l	r8
+#define r78h	r7
+
+/* Endian agnostic accessors for pointer offsets to 64 bit values */
+#define p64l	4
+#define p64h	0
+#else
+#define r34l	r3
+#define r34h	r4
+#define r56l	r5
+#define r56h	r6
+#define r78l	r7
+#define r78h	r8
+
+#define p64l	0
+#define p64h	4
+#endif
+
 
 /* Floating Point Registers (FPRs) */
 
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index a7a570d..6c40079 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -60,27 +60,27 @@ _GLOBAL(call_handle_irq)
  * This returns the high 64 bits of the product of two 64-bit numbers.
  */
 _GLOBAL(mulhdu)
-	cmpwi	r6,0
-	cmpwi	cr1,r3,0
-	mr	r10,r4
-	mulhwu	r4,r4,r5
+	cmpwi	r56l,0
+	cmpwi	cr1,r34h,0
+	mr	r10,r34l
+	mulhwu	r34l,r34l,r56h
 	beq	1f
-	mulhwu	r0,r10,r6
-	mullw	r7,r10,r5
+	mulhwu	r0,r10,r56l
+	mullw	r7,r10,r56h
 	addc	r7,r0,r7
-	addze	r4,r4
+	addze	r34l,r34l
 1:	beqlr	cr1		/* all done if high part of A is 0 */
-	mr	r10,r3
-	mullw	r9,r3,r5
-	mulhwu	r3,r3,r5
+	mr	r10,r34h
+	mullw	r9,r34h,r56h
+	mulhwu	r34h,r34h,r56h
 	beq	2f
-	mullw	r0,r10,r6
-	mulhwu	r8,r10,r6
+	mullw	r0,r10,r56l
+	mulhwu	r8,r10,r56l
 	addc	r7,r0,r7
-	adde	r4,r4,r8
-	addze	r3,r3
-2:	addc	r4,r4,r9
-	addze	r3,r3
+	adde	r34l,r34l,r8
+	addze	r34h,r34h
+2:	addc	r34l,r34l,r9
+	addze	r34h,r34h
 	blr
 
 /*
@@ -606,37 +606,37 @@ _GLOBAL(atomic_set_mask)
  */
 _GLOBAL(__ashrdi3)
 	subfic	r6,r5,32
-	srw	r4,r4,r5	# LSW = count > 31 ? 0 : LSW >> count
+	srw	r34l,r34l,r5	# LSW = count > 31 ? 0 : LSW >> count
 	addi	r7,r5,32	# could be xori, or addi with -32
-	slw	r6,r3,r6	# t1 = count > 31 ? 0 : MSW << (32-count)
+	slw	r6,r34h,r6	# t1 = count > 31 ? 0 : MSW << (32-count)
 	rlwinm	r8,r7,0,32	# t3 = (count < 32) ? 32 : 0
-	sraw	r7,r3,r7	# t2 = MSW >> (count-32)
-	or	r4,r4,r6	# LSW |= t1
+	sraw	r7,r34h,r7	# t2 = MSW >> (count-32)
+	or	r34l,r34l,r6	# LSW |= t1
 	slw	r7,r7,r8	# t2 = (count < 32) ? 0 : t2
-	sraw	r3,r3,r5	# MSW = MSW >> count
-	or	r4,r4,r7	# LSW |= t2
+	sraw	r34h,r34h,r5	# MSW = MSW >> count
+	or	r34l,r34l,r7	# LSW |= t2
 	blr
 
 _GLOBAL(__ashldi3)
 	subfic	r6,r5,32
-	slw	r3,r3,r5	# MSW = count > 31 ? 0 : MSW << count
+	slw	r34h,r34h,r5	# MSW = count > 31 ? 0 : MSW << count
 	addi	r7,r5,32	# could be xori, or addi with -32
-	srw	r6,r4,r6	# t1 = count > 31 ? 0 : LSW >> (32-count)
-	slw	r7,r4,r7	# t2 = count < 32 ? 0 : LSW << (count-32)
-	or	r3,r3,r6	# MSW |= t1
-	slw	r4,r4,r5	# LSW = LSW << count
-	or	r3,r3,r7	# MSW |= t2
+	srw	r6,r34l,r6	# t1 = count > 31 ? 0 : LSW >> (32-count)
+	slw	r7,r34l,r7	# t2 = count < 32 ? 0 : LSW << (count-32)
+	or	r34h,r34h,r6	# MSW |= t1
+	slw	r34l,r34l,r5	# LSW = LSW << count
+	or	r34h,r34h,r7	# MSW |= t2
 	blr
 
 _GLOBAL(__lshrdi3)
 	subfic	r6,r5,32
-	srw	r4,r4,r5	# LSW = count > 31 ? 0 : LSW >> count
+	srw	r34l,r34l,r5	# LSW = count > 31 ? 0 : LSW >> count
 	addi	r7,r5,32	# could be xori, or addi with -32
-	slw	r6,r3,r6	# t1 = count > 31 ? 0 : MSW << (32-count)
-	srw	r7,r3,r7	# t2 = count < 32 ? 0 : MSW >> (count-32)
-	or	r4,r4,r6	# LSW |= t1
-	srw	r3,r3,r5	# MSW = MSW >> count
-	or	r4,r4,r7	# LSW |= t2
+	slw	r6,r34h,r6	# t1 = count > 31 ? 0 : MSW << (32-count)
+	srw	r7,r34h,r7	# t2 = count < 32 ? 0 : MSW >> (count-32)
+	or	r34l,r34l,r6	# LSW |= t1
+	srw	r34h,r34h,r5	# MSW = MSW >> count
+	or	r34l,r34l,r7	# LSW |= t2
 	blr
 
 /*
@@ -644,10 +644,10 @@ _GLOBAL(__lshrdi3)
  * Returns 0 if a < b, 1 if a == b, 2 if a > b.
  */
 _GLOBAL(__ucmpdi2)
-	cmplw	r3,r5
+	cmplw	r34h,r56h
 	li	r3,1
 	bne	1f
-	cmplw	r4,r6
+	cmplw	r34l,r56l
 	beqlr
 1:	li	r3,0
 	bltlr
diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
index 83d9832..12f2da4 100644
--- a/arch/powerpc/lib/div64.S
+++ b/arch/powerpc/lib/div64.S
@@ -17,8 +17,8 @@
 #include <asm/processor.h>
 
 _GLOBAL(__div64_32)
-	lwz	r5,0(r3)	# get the dividend into r5/r6
-	lwz	r6,4(r3)
+	lwz	r5,p64h(r3)	# get the dividend into r5/r6
+	lwz	r6,p64l(r3)
 	cmplw	r5,r4
 	li	r7,0
 	li	r8,0
@@ -53,7 +53,7 @@ _GLOBAL(__div64_32)
 	mullw	r10,r0,r4	# and get the remainder
 	add	r8,r8,r0
 	subf	r6,r10,r6
-4:	stw	r7,0(r3)	# return the quotient in *r3
-	stw	r8,4(r3)
+4:	stw	r7,p64h(r3)	# return the quotient in *r3
+	stw	r8,p64l(r3)
 	mr	r3,r6		# return the remainder in r3
 	blr
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 11/18] powerpc: Make assembly endian agnostic when accessing 64bit values
@ 2010-10-01  7:06   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Matthew McClintock, Torez Smith

From: Ian Munsie <imunsie@au1.ibm.com>

The 32bit PowerPC ABI states that when passing arguments and return
values via registers a value of type long long is stored in pairs of
registers as follows:

The lower addressed word is stored in the next available odd numbered
register and the higher addressed value is stored in register+1.

i.e. the values will either be stored in the next available of:
r3/r4, r5/r6, r7/r8 or r9/r10

Since the lower addressed value must be in the lower register number we
have an endianness issue and need to treat this specially in any
assembly that is passed or returns a 64bit value.

This patch introduces some aliases in ppc_asm.h which will select the
appropriate register from the pair depending on the CPU endianness.
There are in the form of r34l for the low word from the r3/r4 pair and
r34h for the high word and so on for the remaining register pairs.

It also introduces p64l and p64h which can be used to select the
appropriate offset whenever loading a 32bit word while referring to the
address of a 64bit value. For instance if r3 contains the address of a
64bit value the following assembly would load the high word into r5 and
the low word into r6 regardless of endianness:
	lwz	r5,p64h(r3)
	lwz	r6,p64l(r3)

Finally, the patch also alters the functions in misc_32.S that take
64bit arguments to use these new accessors to work on the little endian
PowerPC architecture:

mulhdu, __div64_32, __ashrdi3, __ashldi3, __lshrdi3 and __ucmpdi2

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/include/asm/ppc_asm.h |   24 ++++++++++++
 arch/powerpc/kernel/misc_32.S      |   72 ++++++++++++++++++------------------
 arch/powerpc/lib/div64.S           |    8 ++--
 3 files changed, 64 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
index 9821006..6929483 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -510,6 +510,30 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
 #define	r30	30
 #define	r31	31
 
+/* Endian agnostic accessors for 64 bit values passed and returned in GPRs */
+#ifdef __BIG_ENDIAN__
+#define r34l	r4
+#define r34h	r3
+#define r56l	r6
+#define r56h	r5
+#define r78l	r8
+#define r78h	r7
+
+/* Endian agnostic accessors for pointer offsets to 64 bit values */
+#define p64l	4
+#define p64h	0
+#else
+#define r34l	r3
+#define r34h	r4
+#define r56l	r5
+#define r56h	r6
+#define r78l	r7
+#define r78h	r8
+
+#define p64l	0
+#define p64h	4
+#endif
+
 
 /* Floating Point Registers (FPRs) */
 
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index a7a570d..6c40079 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -60,27 +60,27 @@ _GLOBAL(call_handle_irq)
  * This returns the high 64 bits of the product of two 64-bit numbers.
  */
 _GLOBAL(mulhdu)
-	cmpwi	r6,0
-	cmpwi	cr1,r3,0
-	mr	r10,r4
-	mulhwu	r4,r4,r5
+	cmpwi	r56l,0
+	cmpwi	cr1,r34h,0
+	mr	r10,r34l
+	mulhwu	r34l,r34l,r56h
 	beq	1f
-	mulhwu	r0,r10,r6
-	mullw	r7,r10,r5
+	mulhwu	r0,r10,r56l
+	mullw	r7,r10,r56h
 	addc	r7,r0,r7
-	addze	r4,r4
+	addze	r34l,r34l
 1:	beqlr	cr1		/* all done if high part of A is 0 */
-	mr	r10,r3
-	mullw	r9,r3,r5
-	mulhwu	r3,r3,r5
+	mr	r10,r34h
+	mullw	r9,r34h,r56h
+	mulhwu	r34h,r34h,r56h
 	beq	2f
-	mullw	r0,r10,r6
-	mulhwu	r8,r10,r6
+	mullw	r0,r10,r56l
+	mulhwu	r8,r10,r56l
 	addc	r7,r0,r7
-	adde	r4,r4,r8
-	addze	r3,r3
-2:	addc	r4,r4,r9
-	addze	r3,r3
+	adde	r34l,r34l,r8
+	addze	r34h,r34h
+2:	addc	r34l,r34l,r9
+	addze	r34h,r34h
 	blr
 
 /*
@@ -606,37 +606,37 @@ _GLOBAL(atomic_set_mask)
  */
 _GLOBAL(__ashrdi3)
 	subfic	r6,r5,32
-	srw	r4,r4,r5	# LSW = count > 31 ? 0 : LSW >> count
+	srw	r34l,r34l,r5	# LSW = count > 31 ? 0 : LSW >> count
 	addi	r7,r5,32	# could be xori, or addi with -32
-	slw	r6,r3,r6	# t1 = count > 31 ? 0 : MSW << (32-count)
+	slw	r6,r34h,r6	# t1 = count > 31 ? 0 : MSW << (32-count)
 	rlwinm	r8,r7,0,32	# t3 = (count < 32) ? 32 : 0
-	sraw	r7,r3,r7	# t2 = MSW >> (count-32)
-	or	r4,r4,r6	# LSW |= t1
+	sraw	r7,r34h,r7	# t2 = MSW >> (count-32)
+	or	r34l,r34l,r6	# LSW |= t1
 	slw	r7,r7,r8	# t2 = (count < 32) ? 0 : t2
-	sraw	r3,r3,r5	# MSW = MSW >> count
-	or	r4,r4,r7	# LSW |= t2
+	sraw	r34h,r34h,r5	# MSW = MSW >> count
+	or	r34l,r34l,r7	# LSW |= t2
 	blr
 
 _GLOBAL(__ashldi3)
 	subfic	r6,r5,32
-	slw	r3,r3,r5	# MSW = count > 31 ? 0 : MSW << count
+	slw	r34h,r34h,r5	# MSW = count > 31 ? 0 : MSW << count
 	addi	r7,r5,32	# could be xori, or addi with -32
-	srw	r6,r4,r6	# t1 = count > 31 ? 0 : LSW >> (32-count)
-	slw	r7,r4,r7	# t2 = count < 32 ? 0 : LSW << (count-32)
-	or	r3,r3,r6	# MSW |= t1
-	slw	r4,r4,r5	# LSW = LSW << count
-	or	r3,r3,r7	# MSW |= t2
+	srw	r6,r34l,r6	# t1 = count > 31 ? 0 : LSW >> (32-count)
+	slw	r7,r34l,r7	# t2 = count < 32 ? 0 : LSW << (count-32)
+	or	r34h,r34h,r6	# MSW |= t1
+	slw	r34l,r34l,r5	# LSW = LSW << count
+	or	r34h,r34h,r7	# MSW |= t2
 	blr
 
 _GLOBAL(__lshrdi3)
 	subfic	r6,r5,32
-	srw	r4,r4,r5	# LSW = count > 31 ? 0 : LSW >> count
+	srw	r34l,r34l,r5	# LSW = count > 31 ? 0 : LSW >> count
 	addi	r7,r5,32	# could be xori, or addi with -32
-	slw	r6,r3,r6	# t1 = count > 31 ? 0 : MSW << (32-count)
-	srw	r7,r3,r7	# t2 = count < 32 ? 0 : MSW >> (count-32)
-	or	r4,r4,r6	# LSW |= t1
-	srw	r3,r3,r5	# MSW = MSW >> count
-	or	r4,r4,r7	# LSW |= t2
+	slw	r6,r34h,r6	# t1 = count > 31 ? 0 : MSW << (32-count)
+	srw	r7,r34h,r7	# t2 = count < 32 ? 0 : MSW >> (count-32)
+	or	r34l,r34l,r6	# LSW |= t1
+	srw	r34h,r34h,r5	# MSW = MSW >> count
+	or	r34l,r34l,r7	# LSW |= t2
 	blr
 
 /*
@@ -644,10 +644,10 @@ _GLOBAL(__lshrdi3)
  * Returns 0 if a < b, 1 if a == b, 2 if a > b.
  */
 _GLOBAL(__ucmpdi2)
-	cmplw	r3,r5
+	cmplw	r34h,r56h
 	li	r3,1
 	bne	1f
-	cmplw	r4,r6
+	cmplw	r34l,r56l
 	beqlr
 1:	li	r3,0
 	bltlr
diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
index 83d9832..12f2da4 100644
--- a/arch/powerpc/lib/div64.S
+++ b/arch/powerpc/lib/div64.S
@@ -17,8 +17,8 @@
 #include <asm/processor.h>
 
 _GLOBAL(__div64_32)
-	lwz	r5,0(r3)	# get the dividend into r5/r6
-	lwz	r6,4(r3)
+	lwz	r5,p64h(r3)	# get the dividend into r5/r6
+	lwz	r6,p64l(r3)
 	cmplw	r5,r4
 	li	r7,0
 	li	r8,0
@@ -53,7 +53,7 @@ _GLOBAL(__div64_32)
 	mullw	r10,r0,r4	# and get the remainder
 	add	r8,r8,r0
 	subf	r6,r10,r6
-4:	stw	r7,0(r3)	# return the quotient in *r3
-	stw	r8,4(r3)
+4:	stw	r7,p64h(r3)	# return the quotient in *r3
+	stw	r8,p64l(r3)
 	mr	r3,r6		# return the remainder in r3
 	blr
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 12/18] powerpc 44x: Handle TLB miss regardless of endianness
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:06   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Dave Kleikamp, Josh Boyer, Torez Smith

From: Ian Munsie <imunsie@au1.ibm.com>

On the 44x we use 64bit page table entries, but the CPU is only 32bit.
When a PTE is loaded during a TLB miss each half is loaded into
different registers, so we need to reverse the offsets if the CPU is
running in little endian mode.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/kernel/head_44x.S |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 6198733..d4c144f 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -258,8 +258,8 @@ interrupt_base:
 
 	/* Compute pte address */
 	rlwimi  r12, r10, PPC44x_PTE_ADD_SHIFT, PPC44x_PTE_ADD_MASK_BIT, 28
-	lwz	r11, 0(r12)		/* Get high word of pte entry */
-	lwz	r12, 4(r12)		/* Get low word of pte entry */
+	lwz	r11, p64h(r12)		/* Get high word of pte entry */
+	lwz	r12, p64l(r12)		/* Get low word of pte entry */
 
 	lis	r10,tlb_44x_index@ha
 
@@ -354,8 +354,8 @@ tlb_44x_patch_hwater_D:
 
 	/* Compute pte address */
 	rlwimi	r12, r10, PPC44x_PTE_ADD_SHIFT, PPC44x_PTE_ADD_MASK_BIT, 28
-	lwz	r11, 0(r12)		/* Get high word of pte entry */
-	lwz	r12, 4(r12)		/* Get low word of pte entry */
+	lwz	r11, p64h(r12)		/* Get high word of pte entry */
+	lwz	r12, p64l(r12)		/* Get low word of pte entry */
 
 	lis	r10,tlb_44x_index@ha
 
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 12/18] powerpc 44x: Handle TLB miss regardless of endianness
@ 2010-10-01  7:06   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Dave Kleikamp, paulus, Ian Munsie, Torez Smith

From: Ian Munsie <imunsie@au1.ibm.com>

On the 44x we use 64bit page table entries, but the CPU is only 32bit.
When a PTE is loaded during a TLB miss each half is loaded into
different registers, so we need to reverse the offsets if the CPU is
running in little endian mode.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/kernel/head_44x.S |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 6198733..d4c144f 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -258,8 +258,8 @@ interrupt_base:
 
 	/* Compute pte address */
 	rlwimi  r12, r10, PPC44x_PTE_ADD_SHIFT, PPC44x_PTE_ADD_MASK_BIT, 28
-	lwz	r11, 0(r12)		/* Get high word of pte entry */
-	lwz	r12, 4(r12)		/* Get low word of pte entry */
+	lwz	r11, p64h(r12)		/* Get high word of pte entry */
+	lwz	r12, p64l(r12)		/* Get low word of pte entry */
 
 	lis	r10,tlb_44x_index@ha
 
@@ -354,8 +354,8 @@ tlb_44x_patch_hwater_D:
 
 	/* Compute pte address */
 	rlwimi	r12, r10, PPC44x_PTE_ADD_SHIFT, PPC44x_PTE_ADD_MASK_BIT, 28
-	lwz	r11, 0(r12)		/* Get high word of pte entry */
-	lwz	r12, 4(r12)		/* Get low word of pte entry */
+	lwz	r11, p64h(r12)		/* Get high word of pte entry */
+	lwz	r12, p64l(r12)		/* Get low word of pte entry */
 
 	lis	r10,tlb_44x_index@ha
 
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 13/18] powerpc 44x: Make DCR endianness agnostic
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:06   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Josh Boyer, Stefan Roese, Thomas Gleixner,
	Peter Zijlstra, Anton Blanchard, Geoff Levand, Grant Likely,
	devicetree-discuss

From: Ian Munsie <imunsie@au1.ibm.com>

The Device Control Register accesses parse the device tree and therefore
need to handle the possible differences of endianness between the CPU
and device tree.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/sysdev/dcr.c        |   18 +++++++++---------
 arch/powerpc/sysdev/ppc4xx_soc.c |   16 ++++++++--------
 arch/powerpc/sysdev/uic.c        |    6 +++---
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
index bb44aa9..7f91e8a 100644
--- a/arch/powerpc/sysdev/dcr.c
+++ b/arch/powerpc/sysdev/dcr.c
@@ -27,7 +27,7 @@
 static struct device_node *find_dcr_parent(struct device_node *node)
 {
 	struct device_node *par, *tmp;
-	const u32 *p;
+	const __be32 *p;
 
 	for (par = of_node_get(node); par;) {
 		if (of_get_property(par, "dcr-controller", NULL))
@@ -37,7 +37,7 @@ static struct device_node *find_dcr_parent(struct device_node *node)
 		if (p == NULL)
 			par = of_get_parent(par);
 		else
-			par = of_find_node_by_phandle(*p);
+			par = of_find_node_by_phandle(be32_to_cpup(p));
 		of_node_put(tmp);
 	}
 	return par;
@@ -128,24 +128,24 @@ unsigned int dcr_resource_start(const struct device_node *np,
 				unsigned int index)
 {
 	unsigned int ds;
-	const u32 *dr = of_get_property(np, "dcr-reg", &ds);
+	const __be32 *dr = of_get_property(np, "dcr-reg", &ds);
 
 	if (dr == NULL || ds & 1 || index >= (ds / 8))
 		return 0;
 
-	return dr[index * 2];
+	return be32_to_cpu(dr[index * 2]);
 }
 EXPORT_SYMBOL_GPL(dcr_resource_start);
 
 unsigned int dcr_resource_len(const struct device_node *np, unsigned int index)
 {
 	unsigned int ds;
-	const u32 *dr = of_get_property(np, "dcr-reg", &ds);
+	const __be32 *dr = of_get_property(np, "dcr-reg", &ds);
 
 	if (dr == NULL || ds & 1 || index >= (ds / 8))
 		return 0;
 
-	return dr[index * 2 + 1];
+	return be32_to_cpu(dr[index * 2 + 1]);
 }
 EXPORT_SYMBOL_GPL(dcr_resource_len);
 
@@ -156,7 +156,7 @@ u64 of_translate_dcr_address(struct device_node *dev,
 			     unsigned int *out_stride)
 {
 	struct device_node *dp;
-	const u32 *p;
+	const __be32 *p;
 	unsigned int stride;
 	u64 ret = OF_BAD_ADDR;
 
@@ -166,7 +166,7 @@ u64 of_translate_dcr_address(struct device_node *dev,
 
 	/* Stride is not properly defined yet, default to 0x10 for Axon */
 	p = of_get_property(dp, "dcr-mmio-stride", NULL);
-	stride = (p == NULL) ? 0x10 : *p;
+	stride = (p == NULL) ? 0x10 : be32_to_cpup(p);
 
 	/* XXX FIXME: Which property name is to use of the 2 following ? */
 	p = of_get_property(dp, "dcr-mmio-range", NULL);
@@ -176,7 +176,7 @@ u64 of_translate_dcr_address(struct device_node *dev,
 		goto done;
 
 	/* Maybe could do some better range checking here */
-	ret = of_translate_address(dp, p);
+	ret = of_translate_address(dp, be32_to_cpup(p));
 	if (ret != OF_BAD_ADDR)
 		ret += (u64)(stride) * (u64)dcr_n;
 	if (out_stride)
diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c b/arch/powerpc/sysdev/ppc4xx_soc.c
index d3d6ce3..e5a7554 100644
--- a/arch/powerpc/sysdev/ppc4xx_soc.c
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -76,10 +76,10 @@ static int __init ppc4xx_l2c_probe(void)
 	u32 r;
 	unsigned long flags;
 	int irq;
-	const u32 *dcrreg;
+	const __be32 *dcrreg;
 	u32 dcrbase_isram;
 	int len;
-	const u32 *prop;
+	const __be32 *prop;
 	u32 l2_size;
 
 	np = of_find_compatible_node(NULL, NULL, "ibm,l2-cache");
@@ -93,7 +93,7 @@ static int __init ppc4xx_l2c_probe(void)
 		of_node_put(np);
 		return -ENODEV;
 	}
-	l2_size = prop[0];
+	l2_size = be32_to_cpu(prop[0]);
 
 	/* Map DCRs */
 	dcrreg = of_get_property(np, "dcr-reg", &len);
@@ -103,8 +103,8 @@ static int __init ppc4xx_l2c_probe(void)
 		of_node_put(np);
 		return -ENODEV;
 	}
-	dcrbase_isram = dcrreg[0];
-	dcrbase_l2c = dcrreg[2];
+	dcrbase_isram = be32_to_cpu(dcrreg[0]);
+	dcrbase_l2c = be32_to_cpu(dcrreg[2]);
 
 	/* Get and map irq number from device tree */
 	irq = irq_of_parse_and_map(np, 0);
@@ -198,7 +198,7 @@ void ppc4xx_reset_system(char *cmd)
 {
 	struct device_node *np;
 	u32 reset_type = DBCR0_RST_SYSTEM;
-	const u32 *prop;
+	const __be32 *prop;
 
 	np = of_find_node_by_type(NULL, "cpu");
 	if (np) {
@@ -210,8 +210,8 @@ void ppc4xx_reset_system(char *cmd)
 		 * 2 - PPC4xx chip reset
 		 * 3 - PPC4xx system reset (default)
 		 */
-		if ((prop) && ((prop[0] >= 1) && (prop[0] <= 3)))
-			reset_type = prop[0] << 28;
+		if ((prop) && ((be32_to_cpu(prop[0]) >= 1) && (be32_to_cpu(prop[0]) <= 3)))
+			reset_type = be32_to_cpu(prop[0]) << 28;
 	}
 
 	mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | reset_type);
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index 0038fb7..e2f7de8 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -253,7 +253,7 @@ uic_irq_ret:
 static struct uic * __init uic_init_one(struct device_node *node)
 {
 	struct uic *uic;
-	const u32 *indexp, *dcrreg;
+	const __be32 *indexp, *dcrreg;
 	int len;
 
 	BUG_ON(! of_device_is_compatible(node, "ibm,uic"));
@@ -269,7 +269,7 @@ static struct uic * __init uic_init_one(struct device_node *node)
 		       "cell-index property\n", node->full_name);
 		return NULL;
 	}
-	uic->index = *indexp;
+	uic->index = be32_to_cpup(indexp);
 
 	dcrreg = of_get_property(node, "dcr-reg", &len);
 	if (!dcrreg || (len != 2*sizeof(u32))) {
@@ -277,7 +277,7 @@ static struct uic * __init uic_init_one(struct device_node *node)
 		       "dcr-reg property\n", node->full_name);
 		return NULL;
 	}
-	uic->dcrbase = *dcrreg;
+	uic->dcrbase = be32_to_cpup(dcrreg);
 
 	uic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
 				      NR_UIC_INTS, &uic_host_ops, -1);
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 13/18] powerpc 44x: Make DCR endianness agnostic
@ 2010-10-01  7:06   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Peter Zijlstra, devicetree-discuss, Ian Munsie, paulus,
	Thomas Gleixner, Stefan Roese, Anton Blanchard

From: Ian Munsie <imunsie@au1.ibm.com>

The Device Control Register accesses parse the device tree and therefore
need to handle the possible differences of endianness between the CPU
and device tree.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/sysdev/dcr.c        |   18 +++++++++---------
 arch/powerpc/sysdev/ppc4xx_soc.c |   16 ++++++++--------
 arch/powerpc/sysdev/uic.c        |    6 +++---
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
index bb44aa9..7f91e8a 100644
--- a/arch/powerpc/sysdev/dcr.c
+++ b/arch/powerpc/sysdev/dcr.c
@@ -27,7 +27,7 @@
 static struct device_node *find_dcr_parent(struct device_node *node)
 {
 	struct device_node *par, *tmp;
-	const u32 *p;
+	const __be32 *p;
 
 	for (par = of_node_get(node); par;) {
 		if (of_get_property(par, "dcr-controller", NULL))
@@ -37,7 +37,7 @@ static struct device_node *find_dcr_parent(struct device_node *node)
 		if (p == NULL)
 			par = of_get_parent(par);
 		else
-			par = of_find_node_by_phandle(*p);
+			par = of_find_node_by_phandle(be32_to_cpup(p));
 		of_node_put(tmp);
 	}
 	return par;
@@ -128,24 +128,24 @@ unsigned int dcr_resource_start(const struct device_node *np,
 				unsigned int index)
 {
 	unsigned int ds;
-	const u32 *dr = of_get_property(np, "dcr-reg", &ds);
+	const __be32 *dr = of_get_property(np, "dcr-reg", &ds);
 
 	if (dr == NULL || ds & 1 || index >= (ds / 8))
 		return 0;
 
-	return dr[index * 2];
+	return be32_to_cpu(dr[index * 2]);
 }
 EXPORT_SYMBOL_GPL(dcr_resource_start);
 
 unsigned int dcr_resource_len(const struct device_node *np, unsigned int index)
 {
 	unsigned int ds;
-	const u32 *dr = of_get_property(np, "dcr-reg", &ds);
+	const __be32 *dr = of_get_property(np, "dcr-reg", &ds);
 
 	if (dr == NULL || ds & 1 || index >= (ds / 8))
 		return 0;
 
-	return dr[index * 2 + 1];
+	return be32_to_cpu(dr[index * 2 + 1]);
 }
 EXPORT_SYMBOL_GPL(dcr_resource_len);
 
@@ -156,7 +156,7 @@ u64 of_translate_dcr_address(struct device_node *dev,
 			     unsigned int *out_stride)
 {
 	struct device_node *dp;
-	const u32 *p;
+	const __be32 *p;
 	unsigned int stride;
 	u64 ret = OF_BAD_ADDR;
 
@@ -166,7 +166,7 @@ u64 of_translate_dcr_address(struct device_node *dev,
 
 	/* Stride is not properly defined yet, default to 0x10 for Axon */
 	p = of_get_property(dp, "dcr-mmio-stride", NULL);
-	stride = (p == NULL) ? 0x10 : *p;
+	stride = (p == NULL) ? 0x10 : be32_to_cpup(p);
 
 	/* XXX FIXME: Which property name is to use of the 2 following ? */
 	p = of_get_property(dp, "dcr-mmio-range", NULL);
@@ -176,7 +176,7 @@ u64 of_translate_dcr_address(struct device_node *dev,
 		goto done;
 
 	/* Maybe could do some better range checking here */
-	ret = of_translate_address(dp, p);
+	ret = of_translate_address(dp, be32_to_cpup(p));
 	if (ret != OF_BAD_ADDR)
 		ret += (u64)(stride) * (u64)dcr_n;
 	if (out_stride)
diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c b/arch/powerpc/sysdev/ppc4xx_soc.c
index d3d6ce3..e5a7554 100644
--- a/arch/powerpc/sysdev/ppc4xx_soc.c
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -76,10 +76,10 @@ static int __init ppc4xx_l2c_probe(void)
 	u32 r;
 	unsigned long flags;
 	int irq;
-	const u32 *dcrreg;
+	const __be32 *dcrreg;
 	u32 dcrbase_isram;
 	int len;
-	const u32 *prop;
+	const __be32 *prop;
 	u32 l2_size;
 
 	np = of_find_compatible_node(NULL, NULL, "ibm,l2-cache");
@@ -93,7 +93,7 @@ static int __init ppc4xx_l2c_probe(void)
 		of_node_put(np);
 		return -ENODEV;
 	}
-	l2_size = prop[0];
+	l2_size = be32_to_cpu(prop[0]);
 
 	/* Map DCRs */
 	dcrreg = of_get_property(np, "dcr-reg", &len);
@@ -103,8 +103,8 @@ static int __init ppc4xx_l2c_probe(void)
 		of_node_put(np);
 		return -ENODEV;
 	}
-	dcrbase_isram = dcrreg[0];
-	dcrbase_l2c = dcrreg[2];
+	dcrbase_isram = be32_to_cpu(dcrreg[0]);
+	dcrbase_l2c = be32_to_cpu(dcrreg[2]);
 
 	/* Get and map irq number from device tree */
 	irq = irq_of_parse_and_map(np, 0);
@@ -198,7 +198,7 @@ void ppc4xx_reset_system(char *cmd)
 {
 	struct device_node *np;
 	u32 reset_type = DBCR0_RST_SYSTEM;
-	const u32 *prop;
+	const __be32 *prop;
 
 	np = of_find_node_by_type(NULL, "cpu");
 	if (np) {
@@ -210,8 +210,8 @@ void ppc4xx_reset_system(char *cmd)
 		 * 2 - PPC4xx chip reset
 		 * 3 - PPC4xx system reset (default)
 		 */
-		if ((prop) && ((prop[0] >= 1) && (prop[0] <= 3)))
-			reset_type = prop[0] << 28;
+		if ((prop) && ((be32_to_cpu(prop[0]) >= 1) && (be32_to_cpu(prop[0]) <= 3)))
+			reset_type = be32_to_cpu(prop[0]) << 28;
 	}
 
 	mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | reset_type);
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index 0038fb7..e2f7de8 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -253,7 +253,7 @@ uic_irq_ret:
 static struct uic * __init uic_init_one(struct device_node *node)
 {
 	struct uic *uic;
-	const u32 *indexp, *dcrreg;
+	const __be32 *indexp, *dcrreg;
 	int len;
 
 	BUG_ON(! of_device_is_compatible(node, "ibm,uic"));
@@ -269,7 +269,7 @@ static struct uic * __init uic_init_one(struct device_node *node)
 		       "cell-index property\n", node->full_name);
 		return NULL;
 	}
-	uic->index = *indexp;
+	uic->index = be32_to_cpup(indexp);
 
 	dcrreg = of_get_property(node, "dcr-reg", &len);
 	if (!dcrreg || (len != 2*sizeof(u32))) {
@@ -277,7 +277,7 @@ static struct uic * __init uic_init_one(struct device_node *node)
 		       "dcr-reg property\n", node->full_name);
 		return NULL;
 	}
-	uic->dcrbase = *dcrreg;
+	uic->dcrbase = be32_to_cpup(dcrreg);
 
 	uic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
 				      NR_UIC_INTS, &uic_host_ops, -1);
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:06   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Stefan Weil, Jiri Kosina, Grant Likely,
	Sean MacLennan, Greg Kroah-Hartman, Michal Simek,
	David S. Miller, devicetree-discuss

From: Ian Munsie <imunsie@au1.ibm.com>

The speed and clock of the serial ports is retrieved from the device
tree in both the PowerPC legacy serial code and the Open Firmware serial
driver, therefore they need to handle the fact that the device tree is
always big endian, while the CPU may not be.

Also fix other device tree references in the legacy serial code.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/kernel/legacy_serial.c |   22 +++++++++++-----------
 drivers/serial/of_serial.c          |   12 ++++++------
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index c1fd0f9..c834757 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
 				  phys_addr_t taddr, unsigned long irq,
 				  upf_t flags, int irq_check_parent)
 {
-	const u32 *clk, *spd;
+	const __be32 *clk, *spd;
 	u32 clock = BASE_BAUD * 16;
 	int index;
 
 	/* get clock freq. if present */
 	clk = of_get_property(np, "clock-frequency", NULL);
 	if (clk && *clk)
-		clock = *clk;
+		clock = be32_to_cpup(clk);
 
 	/* get default speed if present */
 	spd = of_get_property(np, "current-speed", NULL);
@@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
 	legacy_serial_infos[index].taddr = taddr;
 	legacy_serial_infos[index].np = of_node_get(np);
 	legacy_serial_infos[index].clock = clock;
-	legacy_serial_infos[index].speed = spd ? *spd : 0;
+	legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
 	legacy_serial_infos[index].irq_check_parent = irq_check_parent;
 
 	printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
@@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
 static int __init add_legacy_isa_port(struct device_node *np,
 				      struct device_node *isa_brg)
 {
-	const u32 *reg;
+	const __be32 *reg;
 	const char *typep;
 	int index = -1;
 	u64 taddr;
@@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
 		return -1;
 
 	/* Verify it's an IO port, we don't support anything else */
-	if (!(reg[0] & 0x00000001))
+	if (!(be32_to_cpu(reg[0]) & 0x00000001))
 		return -1;
 
 	/* Now look for an "ibm,aix-loc" property that gives us ordering
@@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
 		taddr = 0;
 
 	/* Add port, irq will be dealt with later */
-	return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
+	return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
 			       NO_IRQ, UPF_BOOT_AUTOCONF, 0);
 
 }
@@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
 	 * we get to their "reg" property
 	 */
 	if (np != pci_dev) {
-		const u32 *reg = of_get_property(np, "reg", NULL);
-		if (reg && (*reg < 4))
-			index = lindex = *reg;
+		const __be32 *reg = of_get_property(np, "reg", NULL);
+		if (reg && (be32_to_cpup(reg) < 4))
+			index = lindex = be32_to_cpup(reg);
 	}
 
 	/* Local index means it's the Nth port in the PCI chip. Unfortunately
@@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
 	struct device_node *prom_stdout = NULL;
 	int i, speed = 0, offset = 0;
 	const char *name;
-	const u32 *spd;
+	const __be32 *spd;
 
 	DBG(" -> check_legacy_serial_console()\n");
 
@@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
 	}
 	spd = of_get_property(prom_stdout, "current-speed", NULL);
 	if (spd)
-		speed = *spd;
+		speed = be32_to_cpup(spd);
 
 	if (strcmp(name, "serial") != 0)
 		goto not_found;
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 2af8fd1..17849dc 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
 {
 	struct resource resource;
 	struct device_node *np = ofdev->dev.of_node;
-	const unsigned int *clk, *spd;
-	const u32 *prop;
+	const __be32 *clk, *spd;
+	const __be32 *prop;
 	int ret, prop_size;
 
 	memset(port, 0, sizeof *port);
@@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
 	/* Check for shifted address mapping */
 	prop = of_get_property(np, "reg-offset", &prop_size);
 	if (prop && (prop_size == sizeof(u32)))
-		port->mapbase += *prop;
+		port->mapbase += be32_to_cpup(prop);
 
 	/* Check for registers offset within the devices address range */
 	prop = of_get_property(np, "reg-shift", &prop_size);
 	if (prop && (prop_size == sizeof(u32)))
-		port->regshift = *prop;
+		port->regshift = be32_to_cpup(prop);
 
 	port->irq = irq_of_parse_and_map(np, 0);
 	port->iotype = UPIO_MEM;
 	port->type = type;
-	port->uartclk = *clk;
+	port->uartclk = be32_to_cpup(clk);
 	port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
 		| UPF_FIXED_PORT | UPF_FIXED_TYPE;
 	port->dev = &ofdev->dev;
 	/* If current-speed was set, then try not to change it. */
 	if (spd)
-		port->custom_divisor = *clk / (16 * (*spd));
+		port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
 
 	return 0;
 }
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
@ 2010-10-01  7:06   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Michal Simek, Jiri Kosina, devicetree-discuss,
	Greg Kroah-Hartman, Stefan Weil, paulus, Ian Munsie,
	Sean MacLennan, David S. Miller

From: Ian Munsie <imunsie@au1.ibm.com>

The speed and clock of the serial ports is retrieved from the device
tree in both the PowerPC legacy serial code and the Open Firmware serial
driver, therefore they need to handle the fact that the device tree is
always big endian, while the CPU may not be.

Also fix other device tree references in the legacy serial code.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/kernel/legacy_serial.c |   22 +++++++++++-----------
 drivers/serial/of_serial.c          |   12 ++++++------
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index c1fd0f9..c834757 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
 				  phys_addr_t taddr, unsigned long irq,
 				  upf_t flags, int irq_check_parent)
 {
-	const u32 *clk, *spd;
+	const __be32 *clk, *spd;
 	u32 clock = BASE_BAUD * 16;
 	int index;
 
 	/* get clock freq. if present */
 	clk = of_get_property(np, "clock-frequency", NULL);
 	if (clk && *clk)
-		clock = *clk;
+		clock = be32_to_cpup(clk);
 
 	/* get default speed if present */
 	spd = of_get_property(np, "current-speed", NULL);
@@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
 	legacy_serial_infos[index].taddr = taddr;
 	legacy_serial_infos[index].np = of_node_get(np);
 	legacy_serial_infos[index].clock = clock;
-	legacy_serial_infos[index].speed = spd ? *spd : 0;
+	legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
 	legacy_serial_infos[index].irq_check_parent = irq_check_parent;
 
 	printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
@@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
 static int __init add_legacy_isa_port(struct device_node *np,
 				      struct device_node *isa_brg)
 {
-	const u32 *reg;
+	const __be32 *reg;
 	const char *typep;
 	int index = -1;
 	u64 taddr;
@@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
 		return -1;
 
 	/* Verify it's an IO port, we don't support anything else */
-	if (!(reg[0] & 0x00000001))
+	if (!(be32_to_cpu(reg[0]) & 0x00000001))
 		return -1;
 
 	/* Now look for an "ibm,aix-loc" property that gives us ordering
@@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
 		taddr = 0;
 
 	/* Add port, irq will be dealt with later */
-	return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
+	return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
 			       NO_IRQ, UPF_BOOT_AUTOCONF, 0);
 
 }
@@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
 	 * we get to their "reg" property
 	 */
 	if (np != pci_dev) {
-		const u32 *reg = of_get_property(np, "reg", NULL);
-		if (reg && (*reg < 4))
-			index = lindex = *reg;
+		const __be32 *reg = of_get_property(np, "reg", NULL);
+		if (reg && (be32_to_cpup(reg) < 4))
+			index = lindex = be32_to_cpup(reg);
 	}
 
 	/* Local index means it's the Nth port in the PCI chip. Unfortunately
@@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
 	struct device_node *prom_stdout = NULL;
 	int i, speed = 0, offset = 0;
 	const char *name;
-	const u32 *spd;
+	const __be32 *spd;
 
 	DBG(" -> check_legacy_serial_console()\n");
 
@@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
 	}
 	spd = of_get_property(prom_stdout, "current-speed", NULL);
 	if (spd)
-		speed = *spd;
+		speed = be32_to_cpup(spd);
 
 	if (strcmp(name, "serial") != 0)
 		goto not_found;
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 2af8fd1..17849dc 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
 {
 	struct resource resource;
 	struct device_node *np = ofdev->dev.of_node;
-	const unsigned int *clk, *spd;
-	const u32 *prop;
+	const __be32 *clk, *spd;
+	const __be32 *prop;
 	int ret, prop_size;
 
 	memset(port, 0, sizeof *port);
@@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
 	/* Check for shifted address mapping */
 	prop = of_get_property(np, "reg-offset", &prop_size);
 	if (prop && (prop_size == sizeof(u32)))
-		port->mapbase += *prop;
+		port->mapbase += be32_to_cpup(prop);
 
 	/* Check for registers offset within the devices address range */
 	prop = of_get_property(np, "reg-shift", &prop_size);
 	if (prop && (prop_size == sizeof(u32)))
-		port->regshift = *prop;
+		port->regshift = be32_to_cpup(prop);
 
 	port->irq = irq_of_parse_and_map(np, 0);
 	port->iotype = UPIO_MEM;
 	port->type = type;
-	port->uartclk = *clk;
+	port->uartclk = be32_to_cpup(clk);
 	port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
 		| UPF_FIXED_PORT | UPF_FIXED_TYPE;
 	port->dev = &ofdev->dev;
 	/* If current-speed was set, then try not to change it. */
 	if (spd)
-		port->custom_divisor = *clk / (16 * (*spd));
+		port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
 
 	return 0;
 }
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 15/18] mtd: Fix endianness issues from device tree
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
@ 2010-10-01  7:06   ` Ian Munsie
  2010-10-01  7:05 ` [PATCH 03/18] powerpc: Support parsing a little endian kernel from zImage wrapper Ian Munsie
                     ` (17 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, David Woodhouse, Grant Likely, Julia Lawall,
	Sean MacLennan, Jason Gunthorpe, Artem Bityutskiy,
	H Hartley Sweeten, Anatolij Gustschin, Steve Deiters,
	David S. Miller, Tejun Heo, linux-mtd

From: Ian Munsie <imunsie@au1.ibm.com>

This patch adds the appropriate conversions to correct the endianness
issues in the MTD driver whenever it accesses the device tree (which is
always big endian).

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 drivers/mtd/maps/physmap_of.c  |   14 +++++++-------
 drivers/mtd/nand/fsl_upm.c     |    8 ++++----
 drivers/mtd/nand/mpc5121_nfc.c |    4 ++--
 drivers/mtd/nand/ndfc.c        |    8 ++++----
 drivers/mtd/ofpart.c           |    6 +++---
 5 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index fe63f6b..ec4011c 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -50,7 +50,7 @@ static int parse_obsolete_partitions(struct platform_device *dev,
 {
 	int i, plen, nr_parts;
 	const struct {
-		u32 offset, len;
+		__be32 offset, len;
 	} *part;
 	const char *names;
 
@@ -69,9 +69,9 @@ static int parse_obsolete_partitions(struct platform_device *dev,
 	names = of_get_property(dp, "partition-names", &plen);
 
 	for (i = 0; i < nr_parts; i++) {
-		info->parts[i].offset = part->offset;
-		info->parts[i].size   = part->len & ~1;
-		if (part->len & 1) /* bit 0 set signifies read only partition */
+		info->parts[i].offset = be32_to_cpu(part->offset);
+		info->parts[i].size   = be32_to_cpu(part->len) & ~1;
+		if (be32_to_cpu(part->len) & 1) /* bit 0 set signifies read only partition */
 			info->parts[i].mask_flags = MTD_WRITEABLE;
 
 		if (names && (plen > 0)) {
@@ -226,11 +226,11 @@ static int __devinit of_flash_probe(struct platform_device *dev,
 	struct resource res;
 	struct of_flash *info;
 	const char *probe_type = match->data;
-	const u32 *width;
+	const __be32 *width;
 	int err;
 	int i;
 	int count;
-	const u32 *p;
+	const __be32 *p;
 	int reg_tuple_size;
 	struct mtd_info **mtd_list = NULL;
 	resource_size_t res_size;
@@ -294,7 +294,7 @@ static int __devinit of_flash_probe(struct platform_device *dev,
 		info->list[i].map.name = dev_name(&dev->dev);
 		info->list[i].map.phys = res.start;
 		info->list[i].map.size = res_size;
-		info->list[i].map.bankwidth = *width;
+		info->list[i].map.bankwidth = be32_to_cpup(width);
 
 		err = -ENOMEM;
 		info->list[i].map.virt = ioremap(info->list[i].map.phys,
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 4eff8b2..8da9014 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -222,7 +222,7 @@ static int __devinit fun_probe(struct platform_device *ofdev,
 {
 	struct fsl_upm_nand *fun;
 	struct resource io_res;
-	const uint32_t *prop;
+	const __be32 *prop;
 	int rnb_gpio;
 	int ret;
 	int size;
@@ -270,7 +270,7 @@ static int __devinit fun_probe(struct platform_device *ofdev,
 			goto err1;
 		}
 		for (i = 0; i < fun->mchip_count; i++)
-			fun->mchip_offsets[i] = prop[i];
+			fun->mchip_offsets[i] = be32_to_cpu(prop[i]);
 	} else {
 		fun->mchip_count = 1;
 	}
@@ -295,13 +295,13 @@ static int __devinit fun_probe(struct platform_device *ofdev,
 
 	prop = of_get_property(ofdev->dev.of_node, "chip-delay", NULL);
 	if (prop)
-		fun->chip_delay = *prop;
+		fun->chip_delay = be32_to_cpup(prop);
 	else
 		fun->chip_delay = 50;
 
 	prop = of_get_property(ofdev->dev.of_node, "fsl,upm-wait-flags", &size);
 	if (prop && size == sizeof(uint32_t))
-		fun->wait_flags = *prop;
+		fun->wait_flags = be32_to_cpup(prop);
 	else
 		fun->wait_flags = FSL_UPM_WAIT_RUN_PATTERN |
 				  FSL_UPM_WAIT_WRITE_BYTE;
diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index df0c1da..aeb27a1 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -660,7 +660,7 @@ static int __devinit mpc5121_nfc_probe(struct platform_device *op,
 #endif
 	struct nand_chip *chip;
 	unsigned long regs_paddr, regs_size;
-	const uint *chips_no;
+	const __be32 *chips_no;
 	int resettime = 0;
 	int retval = 0;
 	int rev, len;
@@ -803,7 +803,7 @@ static int __devinit mpc5121_nfc_probe(struct platform_device *op,
 	}
 
 	/* Detect NAND chips */
-	if (nand_scan(mtd, *chips_no)) {
+	if (nand_scan(mtd, be32_to_cpup(chips_no))) {
 		dev_err(dev, "NAND Flash not found !\n");
 		devm_free_irq(dev, prv->irq, mtd);
 		retval = -ENXIO;
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 510554e..c9ae0a5 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -229,7 +229,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 				const struct of_device_id *match)
 {
 	struct ndfc_controller *ndfc = &ndfc_ctrl;
-	const u32 *reg;
+	const __be32 *reg;
 	u32 ccr;
 	int err, len;
 
@@ -244,7 +244,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 		dev_err(&ofdev->dev, "unable read reg property (%d)\n", len);
 		return -ENOENT;
 	}
-	ndfc->chip_select = reg[0];
+	ndfc->chip_select = be32_to_cpu(reg[0]);
 
 	ndfc->ndfcbase = of_iomap(ofdev->dev.of_node, 0);
 	if (!ndfc->ndfcbase) {
@@ -257,7 +257,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 	/* It is ok if ccr does not exist - just default to 0 */
 	reg = of_get_property(ofdev->dev.of_node, "ccr", NULL);
 	if (reg)
-		ccr |= *reg;
+		ccr |= be32_to_cpup(reg);
 
 	out_be32(ndfc->ndfcbase + NDFC_CCR, ccr);
 
@@ -265,7 +265,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 	reg = of_get_property(ofdev->dev.of_node, "bank-settings", NULL);
 	if (reg) {
 		int offset = NDFC_BCFG0 + (ndfc->chip_select << 2);
-		out_be32(ndfc->ndfcbase + offset, *reg);
+		out_be32(ndfc->ndfcbase + offset, be32_to_cpup(reg));
 	}
 
 	err = ndfc_chip_init(ndfc, ofdev->dev.of_node);
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 8bf7dc6..a996718 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -44,7 +44,7 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
 	pp = NULL;
 	i = 0;
 	while ((pp = of_get_next_child(node, pp))) {
-		const u32 *reg;
+		const __be32 *reg;
 		int len;
 
 		reg = of_get_property(pp, "reg", &len);
@@ -53,8 +53,8 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
 			continue;
 		}
 
-		(*pparts)[i].offset = reg[0];
-		(*pparts)[i].size = reg[1];
+		(*pparts)[i].offset = be32_to_cpu(reg[0]);
+		(*pparts)[i].size = be32_to_cpu(reg[1]);
 
 		partname = of_get_property(pp, "label", &len);
 		if (!partname)
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 15/18] mtd: Fix endianness issues from device tree
@ 2010-10-01  7:06   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Jason Gunthorpe, Artem Bityutskiy, H Hartley Sweeten,
	Julia Lawall, Ian Munsie, linux-mtd, Sean MacLennan, Tejun Heo,
	paulus, Steve Deiters, Anatolij Gustschin, David Woodhouse,
	David S. Miller

From: Ian Munsie <imunsie@au1.ibm.com>

This patch adds the appropriate conversions to correct the endianness
issues in the MTD driver whenever it accesses the device tree (which is
always big endian).

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 drivers/mtd/maps/physmap_of.c  |   14 +++++++-------
 drivers/mtd/nand/fsl_upm.c     |    8 ++++----
 drivers/mtd/nand/mpc5121_nfc.c |    4 ++--
 drivers/mtd/nand/ndfc.c        |    8 ++++----
 drivers/mtd/ofpart.c           |    6 +++---
 5 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index fe63f6b..ec4011c 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -50,7 +50,7 @@ static int parse_obsolete_partitions(struct platform_device *dev,
 {
 	int i, plen, nr_parts;
 	const struct {
-		u32 offset, len;
+		__be32 offset, len;
 	} *part;
 	const char *names;
 
@@ -69,9 +69,9 @@ static int parse_obsolete_partitions(struct platform_device *dev,
 	names = of_get_property(dp, "partition-names", &plen);
 
 	for (i = 0; i < nr_parts; i++) {
-		info->parts[i].offset = part->offset;
-		info->parts[i].size   = part->len & ~1;
-		if (part->len & 1) /* bit 0 set signifies read only partition */
+		info->parts[i].offset = be32_to_cpu(part->offset);
+		info->parts[i].size   = be32_to_cpu(part->len) & ~1;
+		if (be32_to_cpu(part->len) & 1) /* bit 0 set signifies read only partition */
 			info->parts[i].mask_flags = MTD_WRITEABLE;
 
 		if (names && (plen > 0)) {
@@ -226,11 +226,11 @@ static int __devinit of_flash_probe(struct platform_device *dev,
 	struct resource res;
 	struct of_flash *info;
 	const char *probe_type = match->data;
-	const u32 *width;
+	const __be32 *width;
 	int err;
 	int i;
 	int count;
-	const u32 *p;
+	const __be32 *p;
 	int reg_tuple_size;
 	struct mtd_info **mtd_list = NULL;
 	resource_size_t res_size;
@@ -294,7 +294,7 @@ static int __devinit of_flash_probe(struct platform_device *dev,
 		info->list[i].map.name = dev_name(&dev->dev);
 		info->list[i].map.phys = res.start;
 		info->list[i].map.size = res_size;
-		info->list[i].map.bankwidth = *width;
+		info->list[i].map.bankwidth = be32_to_cpup(width);
 
 		err = -ENOMEM;
 		info->list[i].map.virt = ioremap(info->list[i].map.phys,
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 4eff8b2..8da9014 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -222,7 +222,7 @@ static int __devinit fun_probe(struct platform_device *ofdev,
 {
 	struct fsl_upm_nand *fun;
 	struct resource io_res;
-	const uint32_t *prop;
+	const __be32 *prop;
 	int rnb_gpio;
 	int ret;
 	int size;
@@ -270,7 +270,7 @@ static int __devinit fun_probe(struct platform_device *ofdev,
 			goto err1;
 		}
 		for (i = 0; i < fun->mchip_count; i++)
-			fun->mchip_offsets[i] = prop[i];
+			fun->mchip_offsets[i] = be32_to_cpu(prop[i]);
 	} else {
 		fun->mchip_count = 1;
 	}
@@ -295,13 +295,13 @@ static int __devinit fun_probe(struct platform_device *ofdev,
 
 	prop = of_get_property(ofdev->dev.of_node, "chip-delay", NULL);
 	if (prop)
-		fun->chip_delay = *prop;
+		fun->chip_delay = be32_to_cpup(prop);
 	else
 		fun->chip_delay = 50;
 
 	prop = of_get_property(ofdev->dev.of_node, "fsl,upm-wait-flags", &size);
 	if (prop && size == sizeof(uint32_t))
-		fun->wait_flags = *prop;
+		fun->wait_flags = be32_to_cpup(prop);
 	else
 		fun->wait_flags = FSL_UPM_WAIT_RUN_PATTERN |
 				  FSL_UPM_WAIT_WRITE_BYTE;
diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index df0c1da..aeb27a1 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -660,7 +660,7 @@ static int __devinit mpc5121_nfc_probe(struct platform_device *op,
 #endif
 	struct nand_chip *chip;
 	unsigned long regs_paddr, regs_size;
-	const uint *chips_no;
+	const __be32 *chips_no;
 	int resettime = 0;
 	int retval = 0;
 	int rev, len;
@@ -803,7 +803,7 @@ static int __devinit mpc5121_nfc_probe(struct platform_device *op,
 	}
 
 	/* Detect NAND chips */
-	if (nand_scan(mtd, *chips_no)) {
+	if (nand_scan(mtd, be32_to_cpup(chips_no))) {
 		dev_err(dev, "NAND Flash not found !\n");
 		devm_free_irq(dev, prv->irq, mtd);
 		retval = -ENXIO;
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 510554e..c9ae0a5 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -229,7 +229,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 				const struct of_device_id *match)
 {
 	struct ndfc_controller *ndfc = &ndfc_ctrl;
-	const u32 *reg;
+	const __be32 *reg;
 	u32 ccr;
 	int err, len;
 
@@ -244,7 +244,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 		dev_err(&ofdev->dev, "unable read reg property (%d)\n", len);
 		return -ENOENT;
 	}
-	ndfc->chip_select = reg[0];
+	ndfc->chip_select = be32_to_cpu(reg[0]);
 
 	ndfc->ndfcbase = of_iomap(ofdev->dev.of_node, 0);
 	if (!ndfc->ndfcbase) {
@@ -257,7 +257,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 	/* It is ok if ccr does not exist - just default to 0 */
 	reg = of_get_property(ofdev->dev.of_node, "ccr", NULL);
 	if (reg)
-		ccr |= *reg;
+		ccr |= be32_to_cpup(reg);
 
 	out_be32(ndfc->ndfcbase + NDFC_CCR, ccr);
 
@@ -265,7 +265,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 	reg = of_get_property(ofdev->dev.of_node, "bank-settings", NULL);
 	if (reg) {
 		int offset = NDFC_BCFG0 + (ndfc->chip_select << 2);
-		out_be32(ndfc->ndfcbase + offset, *reg);
+		out_be32(ndfc->ndfcbase + offset, be32_to_cpup(reg));
 	}
 
 	err = ndfc_chip_init(ndfc, ofdev->dev.of_node);
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 8bf7dc6..a996718 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -44,7 +44,7 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
 	pp = NULL;
 	i = 0;
 	while ((pp = of_get_next_child(node, pp))) {
-		const u32 *reg;
+		const __be32 *reg;
 		int len;
 
 		reg = of_get_property(pp, "reg", &len);
@@ -53,8 +53,8 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
 			continue;
 		}
 
-		(*pparts)[i].offset = reg[0];
-		(*pparts)[i].size = reg[1];
+		(*pparts)[i].offset = be32_to_cpu(reg[0]);
+		(*pparts)[i].size = be32_to_cpu(reg[1]);
 
 		partname = of_get_property(pp, "label", &len);
 		if (!partname)
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 15/18] mtd: Fix endianness issues from device tree
@ 2010-10-01  7:06   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Jason Gunthorpe, Artem Bityutskiy, Grant Likely,
	H Hartley Sweeten, Julia Lawall, Ian Munsie, linux-mtd,
	Sean MacLennan, Tejun Heo, paulus, Steve Deiters,
	Anatolij Gustschin, David Woodhouse, David S. Miller

From: Ian Munsie <imunsie@au1.ibm.com>

This patch adds the appropriate conversions to correct the endianness
issues in the MTD driver whenever it accesses the device tree (which is
always big endian).

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 drivers/mtd/maps/physmap_of.c  |   14 +++++++-------
 drivers/mtd/nand/fsl_upm.c     |    8 ++++----
 drivers/mtd/nand/mpc5121_nfc.c |    4 ++--
 drivers/mtd/nand/ndfc.c        |    8 ++++----
 drivers/mtd/ofpart.c           |    6 +++---
 5 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index fe63f6b..ec4011c 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -50,7 +50,7 @@ static int parse_obsolete_partitions(struct platform_device *dev,
 {
 	int i, plen, nr_parts;
 	const struct {
-		u32 offset, len;
+		__be32 offset, len;
 	} *part;
 	const char *names;
 
@@ -69,9 +69,9 @@ static int parse_obsolete_partitions(struct platform_device *dev,
 	names = of_get_property(dp, "partition-names", &plen);
 
 	for (i = 0; i < nr_parts; i++) {
-		info->parts[i].offset = part->offset;
-		info->parts[i].size   = part->len & ~1;
-		if (part->len & 1) /* bit 0 set signifies read only partition */
+		info->parts[i].offset = be32_to_cpu(part->offset);
+		info->parts[i].size   = be32_to_cpu(part->len) & ~1;
+		if (be32_to_cpu(part->len) & 1) /* bit 0 set signifies read only partition */
 			info->parts[i].mask_flags = MTD_WRITEABLE;
 
 		if (names && (plen > 0)) {
@@ -226,11 +226,11 @@ static int __devinit of_flash_probe(struct platform_device *dev,
 	struct resource res;
 	struct of_flash *info;
 	const char *probe_type = match->data;
-	const u32 *width;
+	const __be32 *width;
 	int err;
 	int i;
 	int count;
-	const u32 *p;
+	const __be32 *p;
 	int reg_tuple_size;
 	struct mtd_info **mtd_list = NULL;
 	resource_size_t res_size;
@@ -294,7 +294,7 @@ static int __devinit of_flash_probe(struct platform_device *dev,
 		info->list[i].map.name = dev_name(&dev->dev);
 		info->list[i].map.phys = res.start;
 		info->list[i].map.size = res_size;
-		info->list[i].map.bankwidth = *width;
+		info->list[i].map.bankwidth = be32_to_cpup(width);
 
 		err = -ENOMEM;
 		info->list[i].map.virt = ioremap(info->list[i].map.phys,
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index 4eff8b2..8da9014 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -222,7 +222,7 @@ static int __devinit fun_probe(struct platform_device *ofdev,
 {
 	struct fsl_upm_nand *fun;
 	struct resource io_res;
-	const uint32_t *prop;
+	const __be32 *prop;
 	int rnb_gpio;
 	int ret;
 	int size;
@@ -270,7 +270,7 @@ static int __devinit fun_probe(struct platform_device *ofdev,
 			goto err1;
 		}
 		for (i = 0; i < fun->mchip_count; i++)
-			fun->mchip_offsets[i] = prop[i];
+			fun->mchip_offsets[i] = be32_to_cpu(prop[i]);
 	} else {
 		fun->mchip_count = 1;
 	}
@@ -295,13 +295,13 @@ static int __devinit fun_probe(struct platform_device *ofdev,
 
 	prop = of_get_property(ofdev->dev.of_node, "chip-delay", NULL);
 	if (prop)
-		fun->chip_delay = *prop;
+		fun->chip_delay = be32_to_cpup(prop);
 	else
 		fun->chip_delay = 50;
 
 	prop = of_get_property(ofdev->dev.of_node, "fsl,upm-wait-flags", &size);
 	if (prop && size == sizeof(uint32_t))
-		fun->wait_flags = *prop;
+		fun->wait_flags = be32_to_cpup(prop);
 	else
 		fun->wait_flags = FSL_UPM_WAIT_RUN_PATTERN |
 				  FSL_UPM_WAIT_WRITE_BYTE;
diff --git a/drivers/mtd/nand/mpc5121_nfc.c b/drivers/mtd/nand/mpc5121_nfc.c
index df0c1da..aeb27a1 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -660,7 +660,7 @@ static int __devinit mpc5121_nfc_probe(struct platform_device *op,
 #endif
 	struct nand_chip *chip;
 	unsigned long regs_paddr, regs_size;
-	const uint *chips_no;
+	const __be32 *chips_no;
 	int resettime = 0;
 	int retval = 0;
 	int rev, len;
@@ -803,7 +803,7 @@ static int __devinit mpc5121_nfc_probe(struct platform_device *op,
 	}
 
 	/* Detect NAND chips */
-	if (nand_scan(mtd, *chips_no)) {
+	if (nand_scan(mtd, be32_to_cpup(chips_no))) {
 		dev_err(dev, "NAND Flash not found !\n");
 		devm_free_irq(dev, prv->irq, mtd);
 		retval = -ENXIO;
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 510554e..c9ae0a5 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -229,7 +229,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 				const struct of_device_id *match)
 {
 	struct ndfc_controller *ndfc = &ndfc_ctrl;
-	const u32 *reg;
+	const __be32 *reg;
 	u32 ccr;
 	int err, len;
 
@@ -244,7 +244,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 		dev_err(&ofdev->dev, "unable read reg property (%d)\n", len);
 		return -ENOENT;
 	}
-	ndfc->chip_select = reg[0];
+	ndfc->chip_select = be32_to_cpu(reg[0]);
 
 	ndfc->ndfcbase = of_iomap(ofdev->dev.of_node, 0);
 	if (!ndfc->ndfcbase) {
@@ -257,7 +257,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 	/* It is ok if ccr does not exist - just default to 0 */
 	reg = of_get_property(ofdev->dev.of_node, "ccr", NULL);
 	if (reg)
-		ccr |= *reg;
+		ccr |= be32_to_cpup(reg);
 
 	out_be32(ndfc->ndfcbase + NDFC_CCR, ccr);
 
@@ -265,7 +265,7 @@ static int __devinit ndfc_probe(struct platform_device *ofdev,
 	reg = of_get_property(ofdev->dev.of_node, "bank-settings", NULL);
 	if (reg) {
 		int offset = NDFC_BCFG0 + (ndfc->chip_select << 2);
-		out_be32(ndfc->ndfcbase + offset, *reg);
+		out_be32(ndfc->ndfcbase + offset, be32_to_cpup(reg));
 	}
 
 	err = ndfc_chip_init(ndfc, ofdev->dev.of_node);
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 8bf7dc6..a996718 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -44,7 +44,7 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
 	pp = NULL;
 	i = 0;
 	while ((pp = of_get_next_child(node, pp))) {
-		const u32 *reg;
+		const __be32 *reg;
 		int len;
 
 		reg = of_get_property(pp, "reg", &len);
@@ -53,8 +53,8 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
 			continue;
 		}
 
-		(*pparts)[i].offset = reg[0];
-		(*pparts)[i].size = reg[1];
+		(*pparts)[i].offset = be32_to_cpu(reg[0]);
+		(*pparts)[i].size = be32_to_cpu(reg[1]);
 
 		partname = of_get_property(pp, "label", &len);
 		if (!partname)
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 16/18] powerpc: Fix endianness issues in alignment handler
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:06   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Michael Neuling, Anton Blanchard, Andreas Schwab

From: Ian Munsie <imunsie@au1.ibm.com>

This patch reverses the order of the high and low bits in the alignment
handler on little endian, which should be enough to fix any alignment
exceptions.

Please note that this patch is largely untested.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/kernel/align.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index 8184ee9..fc357c6 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -712,12 +712,22 @@ int fix_alignment(struct pt_regs *regs)
 		double dd;
 		unsigned char v[8];
 		struct {
+#ifdef __LITTLE_ENDIAN__
+			int	 low32;
+			unsigned hi32;
+#else
 			unsigned hi32;
 			int	 low32;
+#endif
 		} x32;
 		struct {
+#ifdef __LITTLE_ENDIAN__
+			short	      low16;
+			unsigned char hi48[6];
+#else
 			unsigned char hi48[6];
 			short	      low16;
+#endif
 		} x16;
 	} data;
 
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 16/18] powerpc: Fix endianness issues in alignment handler
@ 2010-10-01  7:06   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Andreas Schwab, Michael Neuling, paulus, Ian Munsie, Anton Blanchard

From: Ian Munsie <imunsie@au1.ibm.com>

This patch reverses the order of the high and low bits in the alignment
handler on little endian, which should be enough to fix any alignment
exceptions.

Please note that this patch is largely untested.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/kernel/align.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index 8184ee9..fc357c6 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -712,12 +712,22 @@ int fix_alignment(struct pt_regs *regs)
 		double dd;
 		unsigned char v[8];
 		struct {
+#ifdef __LITTLE_ENDIAN__
+			int	 low32;
+			unsigned hi32;
+#else
 			unsigned hi32;
 			int	 low32;
+#endif
 		} x32;
 		struct {
+#ifdef __LITTLE_ENDIAN__
+			short	      low16;
+			unsigned char hi48[6];
+#else
 			unsigned char hi48[6];
 			short	      low16;
+#endif
 		} x16;
 	} data;
 
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 17/18] net: Fix endianess issues in IBM newemac driver
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:06   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, David S. Miller, Grant Likely, Jiri Pirko,
	Sean MacLennan, Tejun Heo, netdev, devicetree-discuss

From: Ian Munsie <imunsie@au1.ibm.com>

This patch fixes all the device tree and ring buffer accesses in the IBM
newemac driver.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 drivers/net/ibm_newemac/core.c |   68 ++++++++++++++++++++--------------------
 drivers/net/ibm_newemac/mal.c  |    6 ++--
 drivers/net/ibm_newemac/mal.h  |    6 ++--
 3 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 3506fd6..67238b8 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -981,12 +981,12 @@ static int emac_resize_rx_ring(struct emac_instance *dev, int new_mtu)
 	 * to simplify error recovery in the case of allocation failure later.
 	 */
 	for (i = 0; i < NUM_RX_BUFF; ++i) {
-		if (dev->rx_desc[i].ctrl & MAL_RX_CTRL_FIRST)
+		if (dev->rx_desc[i].ctrl & cpu_to_be16(MAL_RX_CTRL_FIRST))
 			++dev->estats.rx_dropped_resize;
 
 		dev->rx_desc[i].data_len = 0;
-		dev->rx_desc[i].ctrl = MAL_RX_CTRL_EMPTY |
-		    (i == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0);
+		dev->rx_desc[i].ctrl = cpu_to_be16(MAL_RX_CTRL_EMPTY |
+		    (i == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0));
 	}
 
 	/* Reallocate RX ring only if bigger skb buffers are required */
@@ -1005,9 +1005,9 @@ static int emac_resize_rx_ring(struct emac_instance *dev, int new_mtu)
 		dev_kfree_skb(dev->rx_skb[i]);
 
 		skb_reserve(skb, EMAC_RX_SKB_HEADROOM + 2);
-		dev->rx_desc[i].data_ptr =
+		dev->rx_desc[i].data_ptr = cpu_to_be32(
 		    dma_map_single(&dev->ofdev->dev, skb->data - 2, rx_sync_size,
-				   DMA_FROM_DEVICE) + 2;
+				   DMA_FROM_DEVICE) + 2);
 		dev->rx_skb[i] = skb;
 	}
  skip:
@@ -1067,7 +1067,7 @@ static void emac_clean_tx_ring(struct emac_instance *dev)
 		if (dev->tx_skb[i]) {
 			dev_kfree_skb(dev->tx_skb[i]);
 			dev->tx_skb[i] = NULL;
-			if (dev->tx_desc[i].ctrl & MAL_TX_CTRL_READY)
+			if (dev->tx_desc[i].ctrl & cpu_to_be16(MAL_TX_CTRL_READY))
 				++dev->estats.tx_dropped;
 		}
 		dev->tx_desc[i].ctrl = 0;
@@ -1104,12 +1104,12 @@ static inline int emac_alloc_rx_skb(struct emac_instance *dev, int slot,
 	dev->rx_desc[slot].data_len = 0;
 
 	skb_reserve(skb, EMAC_RX_SKB_HEADROOM + 2);
-	dev->rx_desc[slot].data_ptr =
+	dev->rx_desc[slot].data_ptr = cpu_to_be32(
 	    dma_map_single(&dev->ofdev->dev, skb->data - 2, dev->rx_sync_size,
-			   DMA_FROM_DEVICE) + 2;
+			   DMA_FROM_DEVICE) + 2);
 	wmb();
-	dev->rx_desc[slot].ctrl = MAL_RX_CTRL_EMPTY |
-	    (slot == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0);
+	dev->rx_desc[slot].ctrl = cpu_to_be16(MAL_RX_CTRL_EMPTY |
+	    (slot == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0));
 
 	return 0;
 }
@@ -1373,12 +1373,12 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
 	DBG2(dev, "xmit(%u) %d" NL, len, slot);
 
 	dev->tx_skb[slot] = skb;
-	dev->tx_desc[slot].data_ptr = dma_map_single(&dev->ofdev->dev,
+	dev->tx_desc[slot].data_ptr = cpu_to_be32(dma_map_single(&dev->ofdev->dev,
 						     skb->data, len,
-						     DMA_TO_DEVICE);
-	dev->tx_desc[slot].data_len = (u16) len;
+						     DMA_TO_DEVICE));
+	dev->tx_desc[slot].data_len = cpu_to_be16(len);
 	wmb();
-	dev->tx_desc[slot].ctrl = ctrl;
+	dev->tx_desc[slot].ctrl = cpu_to_be16(ctrl);
 
 	return emac_xmit_finish(dev, len);
 }
@@ -1399,9 +1399,9 @@ static inline int emac_xmit_split(struct emac_instance *dev, int slot,
 			ctrl |= MAL_TX_CTRL_WRAP;
 
 		dev->tx_skb[slot] = NULL;
-		dev->tx_desc[slot].data_ptr = pd;
-		dev->tx_desc[slot].data_len = (u16) chunk;
-		dev->tx_desc[slot].ctrl = ctrl;
+		dev->tx_desc[slot].data_ptr = cpu_to_be32(pd);
+		dev->tx_desc[slot].data_len = cpu_to_be16(chunk);
+		dev->tx_desc[slot].ctrl = cpu_to_be16(ctrl);
 		++dev->tx_cnt;
 
 		if (!len)
@@ -1442,9 +1442,9 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
 	/* skb data */
 	dev->tx_skb[slot] = NULL;
 	chunk = min(len, MAL_MAX_TX_SIZE);
-	dev->tx_desc[slot].data_ptr = pd =
-	    dma_map_single(&dev->ofdev->dev, skb->data, len, DMA_TO_DEVICE);
-	dev->tx_desc[slot].data_len = (u16) chunk;
+	dev->tx_desc[slot].data_ptr = cpu_to_be32(pd =
+	    dma_map_single(&dev->ofdev->dev, skb->data, len, DMA_TO_DEVICE));
+	dev->tx_desc[slot].data_len = cpu_to_be16(chunk);
 	len -= chunk;
 	if (unlikely(len))
 		slot = emac_xmit_split(dev, slot, pd + chunk, len, !nr_frags,
@@ -1473,7 +1473,7 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
 	if (dev->tx_slot == NUM_TX_BUFF - 1)
 		ctrl |= MAL_TX_CTRL_WRAP;
 	wmb();
-	dev->tx_desc[dev->tx_slot].ctrl = ctrl;
+	dev->tx_desc[dev->tx_slot].ctrl = cpu_to_be16(ctrl);
 	dev->tx_slot = (slot + 1) % NUM_TX_BUFF;
 
 	return emac_xmit_finish(dev, skb->len);
@@ -1541,7 +1541,7 @@ static void emac_poll_tx(void *param)
 		u16 ctrl;
 		int slot = dev->ack_slot, n = 0;
 	again:
-		ctrl = dev->tx_desc[slot].ctrl;
+		ctrl = be16_to_cpu(dev->tx_desc[slot].ctrl);
 		if (!(ctrl & MAL_TX_CTRL_READY)) {
 			struct sk_buff *skb = dev->tx_skb[slot];
 			++n;
@@ -1583,8 +1583,8 @@ static inline void emac_recycle_rx_skb(struct emac_instance *dev, int slot,
 
 	dev->rx_desc[slot].data_len = 0;
 	wmb();
-	dev->rx_desc[slot].ctrl = MAL_RX_CTRL_EMPTY |
-	    (slot == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0);
+	dev->rx_desc[slot].ctrl = cpu_to_be16(MAL_RX_CTRL_EMPTY |
+	    (slot == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0));
 }
 
 static void emac_parse_rx_error(struct emac_instance *dev, u16 ctrl)
@@ -1628,7 +1628,7 @@ static inline void emac_rx_csum(struct emac_instance *dev,
 static inline int emac_rx_sg_append(struct emac_instance *dev, int slot)
 {
 	if (likely(dev->rx_sg_skb != NULL)) {
-		int len = dev->rx_desc[slot].data_len;
+		int len = be16_to_cpu(dev->rx_desc[slot].data_len);
 		int tot_len = dev->rx_sg_skb->len + len;
 
 		if (unlikely(tot_len + 2 > dev->rx_skb_size)) {
@@ -1659,14 +1659,14 @@ static int emac_poll_rx(void *param, int budget)
 	while (budget > 0) {
 		int len;
 		struct sk_buff *skb;
-		u16 ctrl = dev->rx_desc[slot].ctrl;
+		u16 ctrl = be16_to_cpu(dev->rx_desc[slot].ctrl);
 
 		if (ctrl & MAL_RX_CTRL_EMPTY)
 			break;
 
 		skb = dev->rx_skb[slot];
 		mb();
-		len = dev->rx_desc[slot].data_len;
+		len = be16_to_cpu(dev->rx_desc[slot].data_len);
 
 		if (unlikely(!MAL_IS_SINGLE_RX(ctrl)))
 			goto sg;
@@ -1757,7 +1757,7 @@ static int emac_poll_rx(void *param, int budget)
 
 	if (unlikely(budget && test_bit(MAL_COMMAC_RX_STOPPED, &dev->commac.flags))) {
 		mb();
-		if (!(dev->rx_desc[slot].ctrl & MAL_RX_CTRL_EMPTY)) {
+		if (!(dev->rx_desc[slot].ctrl & cpu_to_be16(MAL_RX_CTRL_EMPTY))) {
 			DBG2(dev, "rx restart" NL);
 			received = 0;
 			goto again;
@@ -1783,7 +1783,7 @@ static int emac_peek_rx(void *param)
 {
 	struct emac_instance *dev = param;
 
-	return !(dev->rx_desc[dev->rx_slot].ctrl & MAL_RX_CTRL_EMPTY);
+	return !(dev->rx_desc[dev->rx_slot].ctrl & cpu_to_be16(MAL_RX_CTRL_EMPTY));
 }
 
 /* NAPI poll context */
@@ -1793,7 +1793,7 @@ static int emac_peek_rx_sg(void *param)
 
 	int slot = dev->rx_slot;
 	while (1) {
-		u16 ctrl = dev->rx_desc[slot].ctrl;
+		u16 ctrl = be16_to_cpu(dev->rx_desc[slot].ctrl);
 		if (ctrl & MAL_RX_CTRL_EMPTY)
 			return 0;
 		else if (ctrl & MAL_RX_CTRL_LAST)
@@ -2367,14 +2367,14 @@ static int __devinit emac_read_uint_prop(struct device_node *np, const char *nam
 					 u32 *val, int fatal)
 {
 	int len;
-	const u32 *prop = of_get_property(np, name, &len);
+	const __be32 *prop = of_get_property(np, name, &len);
 	if (prop == NULL || len < sizeof(u32)) {
 		if (fatal)
 			printk(KERN_ERR "%s: missing %s property\n",
 			       np->full_name, name);
 		return -ENODEV;
 	}
-	*val = *prop;
+	*val = be32_to_cpup(prop);
 	return 0;
 }
 
@@ -3013,7 +3013,7 @@ static void __init emac_make_bootlist(void)
 
 	/* Collect EMACs */
 	while((np = of_find_all_nodes(np)) != NULL) {
-		const u32 *idx;
+		const __be32 *idx;
 
 		if (of_match_node(emac_match, np) == NULL)
 			continue;
@@ -3022,7 +3022,7 @@ static void __init emac_make_bootlist(void)
 		idx = of_get_property(np, "cell-index", NULL);
 		if (idx == NULL)
 			continue;
-		cell_indices[i] = *idx;
+		cell_indices[i] = be32_to_cpup(idx);
 		emac_boot_list[i++] = of_node_get(np);
 		if (i >= EMAC_BOOT_LIST_SIZE) {
 			of_node_put(np);
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index d5717e2..9e4939e 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -524,7 +524,7 @@ static int __devinit mal_probe(struct platform_device *ofdev,
 	int err = 0, i, bd_size;
 	int index = mal_count++;
 	unsigned int dcr_base;
-	const u32 *prop;
+	const __be32 *prop;
 	u32 cfg;
 	unsigned long irqflags;
 	irq_handler_t hdlr_serr, hdlr_txde, hdlr_rxde;
@@ -550,7 +550,7 @@ static int __devinit mal_probe(struct platform_device *ofdev,
 		err = -ENODEV;
 		goto fail;
 	}
-	mal->num_tx_chans = prop[0];
+	mal->num_tx_chans = be32_to_cpu(prop[0]);
 
 	prop = of_get_property(ofdev->dev.of_node, "num-rx-chans", NULL);
 	if (prop == NULL) {
@@ -560,7 +560,7 @@ static int __devinit mal_probe(struct platform_device *ofdev,
 		err = -ENODEV;
 		goto fail;
 	}
-	mal->num_rx_chans = prop[0];
+	mal->num_rx_chans = be32_to_cpu(prop[0]);
 
 	dcr_base = dcr_resource_start(ofdev->dev.of_node, 0);
 	if (dcr_base == 0) {
diff --git a/drivers/net/ibm_newemac/mal.h b/drivers/net/ibm_newemac/mal.h
index 6608421..b8ee413 100644
--- a/drivers/net/ibm_newemac/mal.h
+++ b/drivers/net/ibm_newemac/mal.h
@@ -147,9 +147,9 @@ static inline int mal_tx_chunks(int len)
 
 /* MAL Buffer Descriptor structure */
 struct mal_descriptor {
-	u16 ctrl;		/* MAL / Commac status control bits */
-	u16 data_len;		/* Max length is 4K-1 (12 bits)     */
-	u32 data_ptr;		/* pointer to actual data buffer    */
+	__be16 ctrl;		/* MAL / Commac status control bits */
+	__be16 data_len;	/* Max length is 4K-1 (12 bits)     */
+	__be32 data_ptr;	/* pointer to actual data buffer    */
 };
 
 /* the following defines are for the MadMAL status and control registers. */
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 17/18] net: Fix endianess issues in IBM newemac driver
@ 2010-10-01  7:06   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Jiri Pirko, netdev, devicetree-discuss, paulus, Ian Munsie,
	Sean MacLennan, Tejun Heo, David S. Miller

From: Ian Munsie <imunsie@au1.ibm.com>

This patch fixes all the device tree and ring buffer accesses in the IBM
newemac driver.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 drivers/net/ibm_newemac/core.c |   68 ++++++++++++++++++++--------------------
 drivers/net/ibm_newemac/mal.c  |    6 ++--
 drivers/net/ibm_newemac/mal.h  |    6 ++--
 3 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 3506fd6..67238b8 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -981,12 +981,12 @@ static int emac_resize_rx_ring(struct emac_instance *dev, int new_mtu)
 	 * to simplify error recovery in the case of allocation failure later.
 	 */
 	for (i = 0; i < NUM_RX_BUFF; ++i) {
-		if (dev->rx_desc[i].ctrl & MAL_RX_CTRL_FIRST)
+		if (dev->rx_desc[i].ctrl & cpu_to_be16(MAL_RX_CTRL_FIRST))
 			++dev->estats.rx_dropped_resize;
 
 		dev->rx_desc[i].data_len = 0;
-		dev->rx_desc[i].ctrl = MAL_RX_CTRL_EMPTY |
-		    (i == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0);
+		dev->rx_desc[i].ctrl = cpu_to_be16(MAL_RX_CTRL_EMPTY |
+		    (i == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0));
 	}
 
 	/* Reallocate RX ring only if bigger skb buffers are required */
@@ -1005,9 +1005,9 @@ static int emac_resize_rx_ring(struct emac_instance *dev, int new_mtu)
 		dev_kfree_skb(dev->rx_skb[i]);
 
 		skb_reserve(skb, EMAC_RX_SKB_HEADROOM + 2);
-		dev->rx_desc[i].data_ptr =
+		dev->rx_desc[i].data_ptr = cpu_to_be32(
 		    dma_map_single(&dev->ofdev->dev, skb->data - 2, rx_sync_size,
-				   DMA_FROM_DEVICE) + 2;
+				   DMA_FROM_DEVICE) + 2);
 		dev->rx_skb[i] = skb;
 	}
  skip:
@@ -1067,7 +1067,7 @@ static void emac_clean_tx_ring(struct emac_instance *dev)
 		if (dev->tx_skb[i]) {
 			dev_kfree_skb(dev->tx_skb[i]);
 			dev->tx_skb[i] = NULL;
-			if (dev->tx_desc[i].ctrl & MAL_TX_CTRL_READY)
+			if (dev->tx_desc[i].ctrl & cpu_to_be16(MAL_TX_CTRL_READY))
 				++dev->estats.tx_dropped;
 		}
 		dev->tx_desc[i].ctrl = 0;
@@ -1104,12 +1104,12 @@ static inline int emac_alloc_rx_skb(struct emac_instance *dev, int slot,
 	dev->rx_desc[slot].data_len = 0;
 
 	skb_reserve(skb, EMAC_RX_SKB_HEADROOM + 2);
-	dev->rx_desc[slot].data_ptr =
+	dev->rx_desc[slot].data_ptr = cpu_to_be32(
 	    dma_map_single(&dev->ofdev->dev, skb->data - 2, dev->rx_sync_size,
-			   DMA_FROM_DEVICE) + 2;
+			   DMA_FROM_DEVICE) + 2);
 	wmb();
-	dev->rx_desc[slot].ctrl = MAL_RX_CTRL_EMPTY |
-	    (slot == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0);
+	dev->rx_desc[slot].ctrl = cpu_to_be16(MAL_RX_CTRL_EMPTY |
+	    (slot == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0));
 
 	return 0;
 }
@@ -1373,12 +1373,12 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
 	DBG2(dev, "xmit(%u) %d" NL, len, slot);
 
 	dev->tx_skb[slot] = skb;
-	dev->tx_desc[slot].data_ptr = dma_map_single(&dev->ofdev->dev,
+	dev->tx_desc[slot].data_ptr = cpu_to_be32(dma_map_single(&dev->ofdev->dev,
 						     skb->data, len,
-						     DMA_TO_DEVICE);
-	dev->tx_desc[slot].data_len = (u16) len;
+						     DMA_TO_DEVICE));
+	dev->tx_desc[slot].data_len = cpu_to_be16(len);
 	wmb();
-	dev->tx_desc[slot].ctrl = ctrl;
+	dev->tx_desc[slot].ctrl = cpu_to_be16(ctrl);
 
 	return emac_xmit_finish(dev, len);
 }
@@ -1399,9 +1399,9 @@ static inline int emac_xmit_split(struct emac_instance *dev, int slot,
 			ctrl |= MAL_TX_CTRL_WRAP;
 
 		dev->tx_skb[slot] = NULL;
-		dev->tx_desc[slot].data_ptr = pd;
-		dev->tx_desc[slot].data_len = (u16) chunk;
-		dev->tx_desc[slot].ctrl = ctrl;
+		dev->tx_desc[slot].data_ptr = cpu_to_be32(pd);
+		dev->tx_desc[slot].data_len = cpu_to_be16(chunk);
+		dev->tx_desc[slot].ctrl = cpu_to_be16(ctrl);
 		++dev->tx_cnt;
 
 		if (!len)
@@ -1442,9 +1442,9 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
 	/* skb data */
 	dev->tx_skb[slot] = NULL;
 	chunk = min(len, MAL_MAX_TX_SIZE);
-	dev->tx_desc[slot].data_ptr = pd =
-	    dma_map_single(&dev->ofdev->dev, skb->data, len, DMA_TO_DEVICE);
-	dev->tx_desc[slot].data_len = (u16) chunk;
+	dev->tx_desc[slot].data_ptr = cpu_to_be32(pd =
+	    dma_map_single(&dev->ofdev->dev, skb->data, len, DMA_TO_DEVICE));
+	dev->tx_desc[slot].data_len = cpu_to_be16(chunk);
 	len -= chunk;
 	if (unlikely(len))
 		slot = emac_xmit_split(dev, slot, pd + chunk, len, !nr_frags,
@@ -1473,7 +1473,7 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
 	if (dev->tx_slot == NUM_TX_BUFF - 1)
 		ctrl |= MAL_TX_CTRL_WRAP;
 	wmb();
-	dev->tx_desc[dev->tx_slot].ctrl = ctrl;
+	dev->tx_desc[dev->tx_slot].ctrl = cpu_to_be16(ctrl);
 	dev->tx_slot = (slot + 1) % NUM_TX_BUFF;
 
 	return emac_xmit_finish(dev, skb->len);
@@ -1541,7 +1541,7 @@ static void emac_poll_tx(void *param)
 		u16 ctrl;
 		int slot = dev->ack_slot, n = 0;
 	again:
-		ctrl = dev->tx_desc[slot].ctrl;
+		ctrl = be16_to_cpu(dev->tx_desc[slot].ctrl);
 		if (!(ctrl & MAL_TX_CTRL_READY)) {
 			struct sk_buff *skb = dev->tx_skb[slot];
 			++n;
@@ -1583,8 +1583,8 @@ static inline void emac_recycle_rx_skb(struct emac_instance *dev, int slot,
 
 	dev->rx_desc[slot].data_len = 0;
 	wmb();
-	dev->rx_desc[slot].ctrl = MAL_RX_CTRL_EMPTY |
-	    (slot == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0);
+	dev->rx_desc[slot].ctrl = cpu_to_be16(MAL_RX_CTRL_EMPTY |
+	    (slot == (NUM_RX_BUFF - 1) ? MAL_RX_CTRL_WRAP : 0));
 }
 
 static void emac_parse_rx_error(struct emac_instance *dev, u16 ctrl)
@@ -1628,7 +1628,7 @@ static inline void emac_rx_csum(struct emac_instance *dev,
 static inline int emac_rx_sg_append(struct emac_instance *dev, int slot)
 {
 	if (likely(dev->rx_sg_skb != NULL)) {
-		int len = dev->rx_desc[slot].data_len;
+		int len = be16_to_cpu(dev->rx_desc[slot].data_len);
 		int tot_len = dev->rx_sg_skb->len + len;
 
 		if (unlikely(tot_len + 2 > dev->rx_skb_size)) {
@@ -1659,14 +1659,14 @@ static int emac_poll_rx(void *param, int budget)
 	while (budget > 0) {
 		int len;
 		struct sk_buff *skb;
-		u16 ctrl = dev->rx_desc[slot].ctrl;
+		u16 ctrl = be16_to_cpu(dev->rx_desc[slot].ctrl);
 
 		if (ctrl & MAL_RX_CTRL_EMPTY)
 			break;
 
 		skb = dev->rx_skb[slot];
 		mb();
-		len = dev->rx_desc[slot].data_len;
+		len = be16_to_cpu(dev->rx_desc[slot].data_len);
 
 		if (unlikely(!MAL_IS_SINGLE_RX(ctrl)))
 			goto sg;
@@ -1757,7 +1757,7 @@ static int emac_poll_rx(void *param, int budget)
 
 	if (unlikely(budget && test_bit(MAL_COMMAC_RX_STOPPED, &dev->commac.flags))) {
 		mb();
-		if (!(dev->rx_desc[slot].ctrl & MAL_RX_CTRL_EMPTY)) {
+		if (!(dev->rx_desc[slot].ctrl & cpu_to_be16(MAL_RX_CTRL_EMPTY))) {
 			DBG2(dev, "rx restart" NL);
 			received = 0;
 			goto again;
@@ -1783,7 +1783,7 @@ static int emac_peek_rx(void *param)
 {
 	struct emac_instance *dev = param;
 
-	return !(dev->rx_desc[dev->rx_slot].ctrl & MAL_RX_CTRL_EMPTY);
+	return !(dev->rx_desc[dev->rx_slot].ctrl & cpu_to_be16(MAL_RX_CTRL_EMPTY));
 }
 
 /* NAPI poll context */
@@ -1793,7 +1793,7 @@ static int emac_peek_rx_sg(void *param)
 
 	int slot = dev->rx_slot;
 	while (1) {
-		u16 ctrl = dev->rx_desc[slot].ctrl;
+		u16 ctrl = be16_to_cpu(dev->rx_desc[slot].ctrl);
 		if (ctrl & MAL_RX_CTRL_EMPTY)
 			return 0;
 		else if (ctrl & MAL_RX_CTRL_LAST)
@@ -2367,14 +2367,14 @@ static int __devinit emac_read_uint_prop(struct device_node *np, const char *nam
 					 u32 *val, int fatal)
 {
 	int len;
-	const u32 *prop = of_get_property(np, name, &len);
+	const __be32 *prop = of_get_property(np, name, &len);
 	if (prop == NULL || len < sizeof(u32)) {
 		if (fatal)
 			printk(KERN_ERR "%s: missing %s property\n",
 			       np->full_name, name);
 		return -ENODEV;
 	}
-	*val = *prop;
+	*val = be32_to_cpup(prop);
 	return 0;
 }
 
@@ -3013,7 +3013,7 @@ static void __init emac_make_bootlist(void)
 
 	/* Collect EMACs */
 	while((np = of_find_all_nodes(np)) != NULL) {
-		const u32 *idx;
+		const __be32 *idx;
 
 		if (of_match_node(emac_match, np) == NULL)
 			continue;
@@ -3022,7 +3022,7 @@ static void __init emac_make_bootlist(void)
 		idx = of_get_property(np, "cell-index", NULL);
 		if (idx == NULL)
 			continue;
-		cell_indices[i] = *idx;
+		cell_indices[i] = be32_to_cpup(idx);
 		emac_boot_list[i++] = of_node_get(np);
 		if (i >= EMAC_BOOT_LIST_SIZE) {
 			of_node_put(np);
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index d5717e2..9e4939e 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -524,7 +524,7 @@ static int __devinit mal_probe(struct platform_device *ofdev,
 	int err = 0, i, bd_size;
 	int index = mal_count++;
 	unsigned int dcr_base;
-	const u32 *prop;
+	const __be32 *prop;
 	u32 cfg;
 	unsigned long irqflags;
 	irq_handler_t hdlr_serr, hdlr_txde, hdlr_rxde;
@@ -550,7 +550,7 @@ static int __devinit mal_probe(struct platform_device *ofdev,
 		err = -ENODEV;
 		goto fail;
 	}
-	mal->num_tx_chans = prop[0];
+	mal->num_tx_chans = be32_to_cpu(prop[0]);
 
 	prop = of_get_property(ofdev->dev.of_node, "num-rx-chans", NULL);
 	if (prop == NULL) {
@@ -560,7 +560,7 @@ static int __devinit mal_probe(struct platform_device *ofdev,
 		err = -ENODEV;
 		goto fail;
 	}
-	mal->num_rx_chans = prop[0];
+	mal->num_rx_chans = be32_to_cpu(prop[0]);
 
 	dcr_base = dcr_resource_start(ofdev->dev.of_node, 0);
 	if (dcr_base == 0) {
diff --git a/drivers/net/ibm_newemac/mal.h b/drivers/net/ibm_newemac/mal.h
index 6608421..b8ee413 100644
--- a/drivers/net/ibm_newemac/mal.h
+++ b/drivers/net/ibm_newemac/mal.h
@@ -147,9 +147,9 @@ static inline int mal_tx_chunks(int len)
 
 /* MAL Buffer Descriptor structure */
 struct mal_descriptor {
-	u16 ctrl;		/* MAL / Commac status control bits */
-	u16 data_len;		/* Max length is 4K-1 (12 bits)     */
-	u32 data_ptr;		/* pointer to actual data buffer    */
+	__be16 ctrl;		/* MAL / Commac status control bits */
+	__be16 data_len;	/* Max length is 4K-1 (12 bits)     */
+	__be32 data_ptr;	/* pointer to actual data buffer    */
 };
 
 /* the following defines are for the MadMAL status and control registers. */
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 18/18] powerpc: Fix jiffies variable on little endian
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  7:06   ` Ian Munsie
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: paulus, Ian Munsie, Denys Vlasenko, Michal Marek, Tim Abbott,
	Sean MacLennan, Rusty Russell

From: Ian Munsie <imunsie@au1.ibm.com>

The vmlinux linker script sets the jiffies variable to the low word of
the jiffies_64 variable. This patch corrects which word is used on
little endian.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/kernel/vmlinux.lds.S |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 8a0deef..7a9010f 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -34,8 +34,12 @@ OUTPUT_ARCH(powerpc:common64)
 jiffies = jiffies_64;
 #else
 OUTPUT_ARCH(powerpc:common)
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+jiffies = jiffies_64;
+#else
 jiffies = jiffies_64 + 4;
 #endif
+#endif
 SECTIONS
 {
 	. = 0;
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 101+ messages in thread

* [PATCH 18/18] powerpc: Fix jiffies variable on little endian
@ 2010-10-01  7:06   ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:06 UTC (permalink / raw)
  To: linux-kernel, linuxppc-dev, benh
  Cc: Michal Marek, Denys Vlasenko, Rusty Russell, Tim Abbott, paulus,
	Ian Munsie, Sean MacLennan

From: Ian Munsie <imunsie@au1.ibm.com>

The vmlinux linker script sets the jiffies variable to the low word of
the jiffies_64 variable. This patch corrects which word is used on
little endian.

Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
 arch/powerpc/kernel/vmlinux.lds.S |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 8a0deef..7a9010f 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -34,8 +34,12 @@ OUTPUT_ARCH(powerpc:common64)
 jiffies = jiffies_64;
 #else
 OUTPUT_ARCH(powerpc:common)
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+jiffies = jiffies_64;
+#else
 jiffies = jiffies_64 + 4;
 #endif
+#endif
 SECTIONS
 {
 	. = 0;
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 101+ messages in thread

* Re: [PATCH 02/18] powerpc: Add CROSSBE_COMPILE to build big endian boot wrapper
  2010-10-01  7:05   ` Ian Munsie
@ 2010-10-01  7:13     ` Geert Uytterhoeven
  -1 siblings, 0 replies; 101+ messages in thread
From: Geert Uytterhoeven @ 2010-10-01  7:13 UTC (permalink / raw)
  To: Ian Munsie
  Cc: linux-kernel, linuxppc-dev, benh, Michal Marek, Albert Herranz,
	paulus, Andrew Morton, Sam Ravnborg

On Fri, Oct 1, 2010 at 09:05, Ian Munsie <imunsie@au1.ibm.com> wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> Since the boot wrapper must be built by a big endian 32bit toolchain
> regardless of what the rest of the kernel is using introduce a new
> parameter to specify that toolchain - CROSSBE_COMPILE.
>
> We already have CROSS32_COMPILE which is already used for the boot
> wrapper, but it is also used to build the 32bit vdso which should be
> build in the same endianness as the rest of the kernel, so it is
> necessary to be able to specify the toolchain to build the boot wrapper
> separately from that used to build the vdso and again separately from
> that used to build the main kernel.
>
> CROSSBE_COMPILE should be pointed to a toolchain capable of targeting
> 32bit big endian powerpc, either specifically targetted at 32bit or
> bi-arch 64 and 32bit. If CROSSBE_COMPILE is not specified it will fall
> back to CROSS32_COMPILE to maintain compatibility with big endian
> targets.

Shouldn't the help text added by [PATCH 01/18]:

+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY
       bool

 endmenu
+
+config ARCH_SUPPORTS_LITTLE_ENDIAN
+       bool
+
+config CPU_LITTLE_ENDIAN
+       bool "Build little endian kernel"
+       depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL
+       default n
+       help
+         This option selects whether a big endian or little endian kernel will
+         be built.
+
+         Note that if building a little endian kernel, CROSS_COMPILE must
+         point to a toolchain capable of targetting little endian powerpc,
+         while the toolchain specified by CROSS32_COMPILE must be capable of
+         targetting *BIG* endian PowerPC.

be updated here as well?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 02/18] powerpc: Add CROSSBE_COMPILE to build big endian boot wrapper
@ 2010-10-01  7:13     ` Geert Uytterhoeven
  0 siblings, 0 replies; 101+ messages in thread
From: Geert Uytterhoeven @ 2010-10-01  7:13 UTC (permalink / raw)
  To: Ian Munsie
  Cc: Michal Marek, Sam Ravnborg, Albert Herranz, linux-kernel, paulus,
	Andrew Morton, linuxppc-dev

On Fri, Oct 1, 2010 at 09:05, Ian Munsie <imunsie@au1.ibm.com> wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> Since the boot wrapper must be built by a big endian 32bit toolchain
> regardless of what the rest of the kernel is using introduce a new
> parameter to specify that toolchain - CROSSBE_COMPILE.
>
> We already have CROSS32_COMPILE which is already used for the boot
> wrapper, but it is also used to build the 32bit vdso which should be
> build in the same endianness as the rest of the kernel, so it is
> necessary to be able to specify the toolchain to build the boot wrapper
> separately from that used to build the vdso and again separately from
> that used to build the main kernel.
>
> CROSSBE_COMPILE should be pointed to a toolchain capable of targeting
> 32bit big endian powerpc, either specifically targetted at 32bit or
> bi-arch 64 and 32bit. If CROSSBE_COMPILE is not specified it will fall
> back to CROSS32_COMPILE to maintain compatibility with big endian
> targets.

Shouldn't the help text added by [PATCH 01/18]:

+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY
       bool

 endmenu
+
+config ARCH_SUPPORTS_LITTLE_ENDIAN
+       bool
+
+config CPU_LITTLE_ENDIAN
+       bool "Build little endian kernel"
+       depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL
+       default n
+       help
+         This option selects whether a big endian or little endian kernel =
will
+         be built.
+
+         Note that if building a little endian kernel, CROSS_COMPILE must
+         point to a toolchain capable of targetting little endian powerpc,
+         while the toolchain specified by CROSS32_COMPILE must be capable =
of
+         targetting *BIG* endian PowerPC.

be updated here as well?

Gr{oetje,eeting}s,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org

In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 02/18] powerpc: Add CROSSBE_COMPILE to build big endian boot wrapper
  2010-10-01  7:13     ` Geert Uytterhoeven
@ 2010-10-01  7:19       ` Ian Munsie
  -1 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:19 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: linux-kernel, linuxppc-dev, benh, Michal Marek, Albert Herranz,
	paulus, Andrew Morton, Sam Ravnborg

Excerpts from Geert Uytterhoeven's message of Fri Oct 01 17:13:19 +1000 2010:
> Shouldn't the help text added by [PATCH 01/18]:
....
> be updated here as well?

Yep, you're right. Thanks for pointing that out, I'll fix it for the next
revision.

Cheers,
-Ian

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 02/18] powerpc: Add CROSSBE_COMPILE to build big endian boot wrapper
@ 2010-10-01  7:19       ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-01  7:19 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Michal Marek, Sam Ravnborg, Albert Herranz, linux-kernel, paulus,
	Andrew Morton, linuxppc-dev

Excerpts from Geert Uytterhoeven's message of Fri Oct 01 17:13:19 +1000 2010:
> Shouldn't the help text added by [PATCH 01/18]:
....
> be updated here as well?

Yep, you're right. Thanks for pointing that out, I'll fix it for the next
revision.

Cheers,
-Ian

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01  9:02   ` Kumar Gala
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Kumar Gala @ 2010-10-01  9:02 UTC (permalink / raw)
  To: Ian Munsie; +Cc: linux-kernel, linuxppc-dev, benh, paulus


On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:

> Some PowerPC processors can be run in either big or little endian modes, some
> others can map selected pages of memory as little endian, which allows the same
> thing. Until now we have only supported the default big endian mode in Linux.
> This patch set introduces little endian support for the 44x family of PowerPC
> processors.

>From a community aspect is anyone actually going to use this?  Is this going to be the equivalent of voyager on x86?  I've got nothing against some of the endian clean ups this introduces.  However the changes to misc_32.S are a bit ugly from a readability point of view.  Just seems like this is likely to bit-rot pretty quickly.

- k


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01  9:02   ` Kumar Gala
  0 siblings, 0 replies; 101+ messages in thread
From: Kumar Gala @ 2010-10-01  9:02 UTC (permalink / raw)
  To: Ian Munsie; +Cc: linuxppc-dev, linux-kernel, paulus


On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:

> Some PowerPC processors can be run in either big or little endian =
modes, some
> others can map selected pages of memory as little endian, which allows =
the same
> thing. Until now we have only supported the default big endian mode in =
Linux.
> This patch set introduces little endian support for the 44x family of =
PowerPC
> processors.

=46rom a community aspect is anyone actually going to use this?  Is this =
going to be the equivalent of voyager on x86?  I've got nothing against =
some of the endian clean ups this introduces.  However the changes to =
misc_32.S are a bit ugly from a readability point of view.  Just seems =
like this is likely to bit-rot pretty quickly.

- k

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
  2010-10-01  7:05   ` Ian Munsie
@ 2010-10-01  9:18     ` Kumar Gala
  -1 siblings, 0 replies; 101+ messages in thread
From: Kumar Gala @ 2010-10-01  9:18 UTC (permalink / raw)
  To: Ian Munsie
  Cc: linux-kernel, linuxppc-dev, benh, paulus, Michal Marek,
	Sam Ravnborg, Andrew Morton, Albert Herranz, Grant Likely,
	Segher Boessenkool, Andreas Schwab, Torez Smith


On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:

> 
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index d361f81..074ff12 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY
> 	bool
> 
> endmenu
> +
> +config ARCH_SUPPORTS_LITTLE_ENDIAN
> +	bool
> +
> +config CPU_LITTLE_ENDIAN
> +	bool "Build little endian kernel"
> +	depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL
> +	default n
> +	help
> +	  This option selects whether a big endian or little endian kernel will
> +	  be built.
> +
> +	  Note that if building a little endian kernel, CROSS_COMPILE must
> +	  point to a toolchain capable of targetting little endian powerpc,
> +	  while the toolchain specified by CROSS32_COMPILE must be capable of
> +	  targetting *BIG* endian PowerPC.
> -- 
> 1.7.1

Shouldn't we have something that limits to the sub-arch'es that actually support it?  I doubt I'm ever going to make FSL-Book-e support LE.

- k

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
@ 2010-10-01  9:18     ` Kumar Gala
  0 siblings, 0 replies; 101+ messages in thread
From: Kumar Gala @ 2010-10-01  9:18 UTC (permalink / raw)
  To: Ian Munsie
  Cc: Michal Marek, Albert Herranz, linuxppc-dev, linux-kernel, paulus,
	Andreas Schwab, Andrew Morton, Sam Ravnborg, Torez Smith


On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:

>=20
> diff --git a/arch/powerpc/platforms/Kconfig.cputype =
b/arch/powerpc/platforms/Kconfig.cputype
> index d361f81..074ff12 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY
> 	bool
>=20
> endmenu
> +
> +config ARCH_SUPPORTS_LITTLE_ENDIAN
> +	bool
> +
> +config CPU_LITTLE_ENDIAN
> +	bool "Build little endian kernel"
> +	depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL
> +	default n
> +	help
> +	  This option selects whether a big endian or little endian =
kernel will
> +	  be built.
> +
> +	  Note that if building a little endian kernel, CROSS_COMPILE =
must
> +	  point to a toolchain capable of targetting little endian =
powerpc,
> +	  while the toolchain specified by CROSS32_COMPILE must be =
capable of
> +	  targetting *BIG* endian PowerPC.
> --=20
> 1.7.1

Shouldn't we have something that limits to the sub-arch'es that actually =
support it?  I doubt I'm ever going to make FSL-Book-e support LE.

- k=

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
  2010-10-01  7:05 ` [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets Ian Munsie
@ 2010-10-01 11:27     ` Josh Boyer
  0 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-01 11:27 UTC (permalink / raw)
  To: Ian Munsie; +Cc: linux-kernel, linuxppc-dev, benh, paulus

On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie <imunsie@au1.ibm.com> wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> I haven't tested booting a little endian kernel on any of these targets,
> but they all claim to be 44x so my little endian trampoline should work
> on all of them, so wire it up on:
>
> bamboo
> katmai
> kilauea
> rainer
> sam440ep
> sequoia
> warp
> yosemite
> ebony
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>

I see no reason to do this at all.  If you haven't tested them and
there is no demand, there's no reason to wire them up.  Some might
actively want to disallow LE mode anyway, like the Warp or Sam440EP.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
@ 2010-10-01 11:27     ` Josh Boyer
  0 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-01 11:27 UTC (permalink / raw)
  To: Ian Munsie; +Cc: linuxppc-dev, linux-kernel, paulus

On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie <imunsie@au1.ibm.com> wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> I haven't tested booting a little endian kernel on any of these targets,
> but they all claim to be 44x so my little endian trampoline should work
> on all of them, so wire it up on:
>
> bamboo
> katmai
> kilauea
> rainer
> sam440ep
> sequoia
> warp
> yosemite
> ebony
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>

I see no reason to do this at all.  If you haven't tested them and
there is no demand, there's no reason to wire them up.  Some might
actively want to disallow LE mode anyway, like the Warp or Sam440EP.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
  2010-10-01  9:18     ` Kumar Gala
@ 2010-10-01 11:28       ` Josh Boyer
  -1 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-01 11:28 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Ian Munsie, Michal Marek, Albert Herranz, linuxppc-dev,
	linux-kernel, paulus, Andreas Schwab, Andrew Morton,
	Sam Ravnborg, Torez Smith

On Fri, Oct 1, 2010 at 5:18 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:
>
>>
>> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
>> index d361f81..074ff12 100644
>> --- a/arch/powerpc/platforms/Kconfig.cputype
>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>> @@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY
>>       bool
>>
>> endmenu
>> +
>> +config ARCH_SUPPORTS_LITTLE_ENDIAN
>> +     bool
>> +
>> +config CPU_LITTLE_ENDIAN
>> +     bool "Build little endian kernel"
>> +     depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL
>> +     default n
>> +     help
>> +       This option selects whether a big endian or little endian kernel will
>> +       be built.
>> +
>> +       Note that if building a little endian kernel, CROSS_COMPILE must
>> +       point to a toolchain capable of targetting little endian powerpc,
>> +       while the toolchain specified by CROSS32_COMPILE must be capable of
>> +       targetting *BIG* endian PowerPC.
>> --
>> 1.7.1
>
> Shouldn't we have something that limits to the sub-arch'es that actually support it?  I doubt I'm ever going to make FSL-Book-e support LE.

Yes, it should.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
@ 2010-10-01 11:28       ` Josh Boyer
  0 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-01 11:28 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Michal Marek, Sam Ravnborg, Albert Herranz, linux-kernel, paulus,
	Ian Munsie, Andreas Schwab, Andrew Morton, linuxppc-dev,
	Torez Smith

On Fri, Oct 1, 2010 at 5:18 AM, Kumar Gala <galak@kernel.crashing.org> wrot=
e:
>
> On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:
>
>>
>> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platf=
orms/Kconfig.cputype
>> index d361f81..074ff12 100644
>> --- a/arch/powerpc/platforms/Kconfig.cputype
>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>> @@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY
>> =A0 =A0 =A0 bool
>>
>> endmenu
>> +
>> +config ARCH_SUPPORTS_LITTLE_ENDIAN
>> + =A0 =A0 bool
>> +
>> +config CPU_LITTLE_ENDIAN
>> + =A0 =A0 bool "Build little endian kernel"
>> + =A0 =A0 depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL
>> + =A0 =A0 default n
>> + =A0 =A0 help
>> + =A0 =A0 =A0 This option selects whether a big endian or little endian =
kernel will
>> + =A0 =A0 =A0 be built.
>> +
>> + =A0 =A0 =A0 Note that if building a little endian kernel, CROSS_COMPIL=
E must
>> + =A0 =A0 =A0 point to a toolchain capable of targetting little endian p=
owerpc,
>> + =A0 =A0 =A0 while the toolchain specified by CROSS32_COMPILE must be c=
apable of
>> + =A0 =A0 =A0 targetting *BIG* endian PowerPC.
>> --
>> 1.7.1
>
> Shouldn't we have something that limits to the sub-arch'es that actually =
support it? =A0I doubt I'm ever going to make FSL-Book-e support LE.

Yes, it should.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01  9:02   ` Kumar Gala
@ 2010-10-01 11:30     ` Josh Boyer
  -1 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-01 11:30 UTC (permalink / raw)
  To: Kumar Gala; +Cc: Ian Munsie, linuxppc-dev, linux-kernel, paulus

On Fri, Oct 1, 2010 at 5:02 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:
>
>> Some PowerPC processors can be run in either big or little endian modes, some
>> others can map selected pages of memory as little endian, which allows the same
>> thing. Until now we have only supported the default big endian mode in Linux.
>> This patch set introduces little endian support for the 44x family of PowerPC
>> processors.
>
> From a community aspect is anyone actually going to use this?  Is this going to be the equivalent of voyager on x86?  I've got nothing against some of the endian clean ups this introduces.  However the changes to misc_32.S are a bit ugly from a readability point of view.  Just seems like this is likely to bit-rot pretty quickly.

I'm with Kumar on this one.  Why would we want to support this?  I
can't say I would be very willing to help anyone run in LE mode, let
alone have it randomly selectable.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 11:30     ` Josh Boyer
  0 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-01 11:30 UTC (permalink / raw)
  To: Kumar Gala; +Cc: paulus, linuxppc-dev, Ian Munsie, linux-kernel

On Fri, Oct 1, 2010 at 5:02 AM, Kumar Gala <galak@kernel.crashing.org> wrot=
e:
>
> On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:
>
>> Some PowerPC processors can be run in either big or little endian modes,=
 some
>> others can map selected pages of memory as little endian, which allows t=
he same
>> thing. Until now we have only supported the default big endian mode in L=
inux.
>> This patch set introduces little endian support for the 44x family of Po=
werPC
>> processors.
>
> From a community aspect is anyone actually going to use this? =A0Is this =
going to be the equivalent of voyager on x86? =A0I've got nothing against s=
ome of the endian clean ups this introduces. =A0However the changes to misc=
_32.S are a bit ugly from a readability point of view. =A0Just seems like t=
his is likely to bit-rot pretty quickly.

I'm with Kumar on this one.  Why would we want to support this?  I
can't say I would be very willing to help anyone run in LE mode, let
alone have it randomly selectable.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
@ 2010-10-01 11:36   ` Josh Boyer
  2010-10-01  7:05   ` Ian Munsie
                     ` (18 subsequent siblings)
  19 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-01 11:36 UTC (permalink / raw)
  To: Ian Munsie; +Cc: linux-kernel, linuxppc-dev, benh, paulus

On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie <imunsie@au1.ibm.com> wrote:
> This patch set in combination with a patched GCC, binutils, uClibc and
> buildroot has allowed for a full proof of concept little endian environment on
> a 440 Taishan board, which was able to successfully run busybox, OpenSSH and a
> handful of other userspace programs without problems.

Aside from my general "uh, why?" stance, I'm very very hesitant to
integrate anything in the kernel that doesn'.t have released patches
on the toolchain side.

Also, which uClibc?  The old and crusty uClibc that uses the horrible
linuxthreads, or the somewhat less crusty that just switched to NPTL
(which hasn't been verified on normal PowerPC that I recall).  Why not
use glibc...

> This is not yet complete support for little endian PowerPC, some outstanding
> issues that I am aware of are:
>  * We only support 32bit PowerPC for now (and indeed, only 44x)
>  * The vdso has not been fixed to be endian agnostic - any userspace program
>   accessing it will get an unexpected result.
>  * I have not touched PCI at all
>  * Remaining device tree accesses still need to be examined to ensure they are
>   correctly handling the endianess of the device tree.
>  * Any other driver that uses the device tree is likely be broken for the same reason.
>  * I've included a patch for the alignment handler, however it is as yet
>   completely untested due to a property of the hardware I've been using for
>   testing.

I'm not meeting to detract here, but the Kconfig should be dependent
on && BROKEN until the above is fixed.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 11:36   ` Josh Boyer
  0 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-01 11:36 UTC (permalink / raw)
  To: Ian Munsie; +Cc: linuxppc-dev, linux-kernel, paulus

On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie <imunsie@au1.ibm.com> wrote:
> This patch set in combination with a patched GCC, binutils, uClibc and
> buildroot has allowed for a full proof of concept little endian environme=
nt on
> a 440 Taishan board, which was able to successfully run busybox, OpenSSH =
and a
> handful of other userspace programs without problems.

Aside from my general "uh, why?" stance, I'm very very hesitant to
integrate anything in the kernel that doesn'.t have released patches
on the toolchain side.

Also, which uClibc?  The old and crusty uClibc that uses the horrible
linuxthreads, or the somewhat less crusty that just switched to NPTL
(which hasn't been verified on normal PowerPC that I recall).  Why not
use glibc...

> This is not yet complete support for little endian PowerPC, some outstand=
ing
> issues that I am aware of are:
> =A0* We only support 32bit PowerPC for now (and indeed, only 44x)
> =A0* The vdso has not been fixed to be endian agnostic - any userspace pr=
ogram
> =A0 accessing it will get an unexpected result.
> =A0* I have not touched PCI at all
> =A0* Remaining device tree accesses still need to be examined to ensure t=
hey are
> =A0 correctly handling the endianess of the device tree.
> =A0* Any other driver that uses the device tree is likely be broken for t=
he same reason.
> =A0* I've included a patch for the alignment handler, however it is as ye=
t
> =A0 completely untested due to a property of the hardware I've been using=
 for
> =A0 testing.

I'm not meeting to detract here, but the Kconfig should be dependent
on && BROKEN until the above is fixed.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
  2010-10-01  7:05   ` Ian Munsie
@ 2010-10-01 11:40     ` Josh Boyer
  -1 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-01 11:40 UTC (permalink / raw)
  To: Ian Munsie
  Cc: linux-kernel, linuxppc-dev, benh, Michal Marek, Albert Herranz,
	paulus, Andreas Schwab, Andrew Morton, Sam Ravnborg, Torez Smith

On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie <imunsie@au1.ibm.com> wrote:
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index d361f81..074ff12 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY
>        bool
>
>  endmenu
> +
> +config ARCH_SUPPORTS_LITTLE_ENDIAN
> +       bool
> +
> +config CPU_LITTLE_ENDIAN
> +       bool "Build little endian kernel"
> +       depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL
> +       default n
> +       help
> +         This option selects whether a big endian or little endian kernel will
> +         be built.
> +
> +         Note that if building a little endian kernel, CROSS_COMPILE must
> +         point to a toolchain capable of targetting little endian powerpc,
> +         while the toolchain specified by CROSS32_COMPILE must be capable of
> +         targetting *BIG* endian PowerPC.

Have you tested this support with a userspace containing floating
point instructions?  I wonder if CONFIG_MATH_EMULATION is going to
need work at all, and if the boards with an actual FPU (440EP, 440EPx,
460EX, etc) would have issues.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
@ 2010-10-01 11:40     ` Josh Boyer
  0 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-01 11:40 UTC (permalink / raw)
  To: Ian Munsie
  Cc: Michal Marek, Sam Ravnborg, Albert Herranz, linux-kernel, paulus,
	Andreas Schwab, Andrew Morton, linuxppc-dev, Torez Smith

On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie <imunsie@au1.ibm.com> wrote:
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platfo=
rms/Kconfig.cputype
> index d361f81..074ff12 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -329,3 +329,19 @@ config CHECK_CACHE_COHERENCY
> =A0 =A0 =A0 =A0bool
>
> =A0endmenu
> +
> +config ARCH_SUPPORTS_LITTLE_ENDIAN
> + =A0 =A0 =A0 bool
> +
> +config CPU_LITTLE_ENDIAN
> + =A0 =A0 =A0 bool "Build little endian kernel"
> + =A0 =A0 =A0 depends on ARCH_SUPPORTS_LITTLE_ENDIAN && EXPERIMENTAL
> + =A0 =A0 =A0 default n
> + =A0 =A0 =A0 help
> + =A0 =A0 =A0 =A0 This option selects whether a big endian or little endi=
an kernel will
> + =A0 =A0 =A0 =A0 be built.
> +
> + =A0 =A0 =A0 =A0 Note that if building a little endian kernel, CROSS_COM=
PILE must
> + =A0 =A0 =A0 =A0 point to a toolchain capable of targetting little endia=
n powerpc,
> + =A0 =A0 =A0 =A0 while the toolchain specified by CROSS32_COMPILE must b=
e capable of
> + =A0 =A0 =A0 =A0 targetting *BIG* endian PowerPC.

Have you tested this support with a userspace containing floating
point instructions?  I wonder if CONFIG_MATH_EMULATION is going to
need work at all, and if the boards with an actual FPU (440EP, 440EPx,
460EX, etc) would have issues.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 11:30     ` Josh Boyer
@ 2010-10-01 11:55       ` Gary Thomas
  -1 siblings, 0 replies; 101+ messages in thread
From: Gary Thomas @ 2010-10-01 11:55 UTC (permalink / raw)
  To: Josh Boyer; +Cc: Kumar Gala, paulus, linuxppc-dev, Ian Munsie, linux-kernel

On 10/01/2010 05:30 AM, Josh Boyer wrote:
> On Fri, Oct 1, 2010 at 5:02 AM, Kumar Gala<galak@kernel.crashing.org>  wrote:
>>
>> On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:
>>
>>> Some PowerPC processors can be run in either big or little endian modes, some
>>> others can map selected pages of memory as little endian, which allows the same
>>> thing. Until now we have only supported the default big endian mode in Linux.
>>> This patch set introduces little endian support for the 44x family of PowerPC
>>> processors.
>>
>>  From a community aspect is anyone actually going to use this?  Is this going to be the equivalent of voyager on x86?  I've got nothing against some of the endian clean ups this introduces.  However the changes to misc_32.S are a bit ugly from a readability point of view.  Just seems like this is likely to bit-rot pretty quickly.
>
> I'm with Kumar on this one.  Why would we want to support this?  I
> can't say I would be very willing to help anyone run in LE mode, let
> alone have it randomly selectable.

Indeed, I thought we had killed that Windows-NT dog ~15 years ago :-)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 11:55       ` Gary Thomas
  0 siblings, 0 replies; 101+ messages in thread
From: Gary Thomas @ 2010-10-01 11:55 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev, paulus, linux-kernel, Ian Munsie

On 10/01/2010 05:30 AM, Josh Boyer wrote:
> On Fri, Oct 1, 2010 at 5:02 AM, Kumar Gala<galak@kernel.crashing.org>  wrote:
>>
>> On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:
>>
>>> Some PowerPC processors can be run in either big or little endian modes, some
>>> others can map selected pages of memory as little endian, which allows the same
>>> thing. Until now we have only supported the default big endian mode in Linux.
>>> This patch set introduces little endian support for the 44x family of PowerPC
>>> processors.
>>
>>  From a community aspect is anyone actually going to use this?  Is this going to be the equivalent of voyager on x86?  I've got nothing against some of the endian clean ups this introduces.  However the changes to misc_32.S are a bit ugly from a readability point of view.  Just seems like this is likely to bit-rot pretty quickly.
>
> I'm with Kumar on this one.  Why would we want to support this?  I
> can't say I would be very willing to help anyone run in LE mode, let
> alone have it randomly selectable.

Indeed, I thought we had killed that Windows-NT dog ~15 years ago :-)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
  2010-10-01 11:28       ` Josh Boyer
@ 2010-10-01 12:09         ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 12:09 UTC (permalink / raw)
  To: Josh Boyer
  Cc: Kumar Gala, Michal Marek, Sam Ravnborg, Albert Herranz,
	linux-kernel, paulus, Ian Munsie, Andreas Schwab, Andrew Morton,
	linuxppc-dev, Torez Smith

On Fri, 2010-10-01 at 07:28 -0400, Josh Boyer wrote:
> > Shouldn't we have something that limits to the sub-arch'es that
> actually support it?  I doubt I'm ever going to make FSL-Book-e
> support LE.
> 
> Yes, it should. 

Sure, that's only WIP patches :-)

Tho FSL BookE would be relatively easy...

Cheers,
Ben.



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
@ 2010-10-01 12:09         ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 12:09 UTC (permalink / raw)
  To: Josh Boyer
  Cc: Michal Marek, linuxppc-dev, Albert Herranz, linux-kernel, paulus,
	Ian Munsie, Andreas Schwab, Andrew Morton, Sam Ravnborg,
	Torez Smith

On Fri, 2010-10-01 at 07:28 -0400, Josh Boyer wrote:
> > Shouldn't we have something that limits to the sub-arch'es that
> actually support it?  I doubt I'm ever going to make FSL-Book-e
> support LE.
> 
> Yes, it should. 

Sure, that's only WIP patches :-)

Tho FSL BookE would be relatively easy...

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 11:30     ` Josh Boyer
@ 2010-10-01 12:14       ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 12:14 UTC (permalink / raw)
  To: Josh Boyer; +Cc: Kumar Gala, paulus, linuxppc-dev, Ian Munsie, linux-kernel

On Fri, 2010-10-01 at 07:30 -0400, Josh Boyer wrote:
> 
> > From a community aspect is anyone actually going to use this?  Is
> this going to be the equivalent of voyager on x86?  I've got nothing
> against some of the endian clean ups this introduces.  However the
> changes to misc_32.S are a bit ugly from a readability point of view.
>  Just seems like this is likely to bit-rot pretty quickly.
> 
> I'm with Kumar on this one.  Why would we want to support this?  I
> can't say I would be very willing to help anyone run in LE mode, let
> alone have it randomly selectable. 

There's some good reasons on the field ... sadly.

At this stage this is mostly an experiment, which went pretty well in
the sense that it's actually quite easy and a lot of the "fixes" are
actually reasonable cleanups to carry.

Now, the main reasons in practice are anything touching graphics.

There's quite a few IP cores out there for SoCs that don't have HW
swappers, and -tons- of more or less ugly code that can't deal with non
native pixel ordering (hell, even Xorg isn't good at it, we really only
support cards that have HW swappers today).

There's an even bigger pile of application code that deals with graphics
without any regard for endianness and is essentially unfixable.

So it becomes a matter of potential customers that will take it if it
does LE and won't if it doesn't ...

Now, I don't have a problem supporting that as the maintainer, as I
said, from a kernel standpoint, it's all quite easy to deal with. Some
of the most gory aspects in misc_32.S could probably be done in a way
that is slightly more readable, but the approach is actually good, I
think, to have macros to represent the high/low parts of register pairs.

So at this stage, I'd say, let's not dismiss it just because we all come
from a long education of hating LE for the sake of it :-)

It makes -some- sense, even if it's not necessarily on the markets
targeted by FSL today for example. At least from the kernel POV, it
doesn't seem to me to be a significant support burden at all.

Cheers,
Ben.



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 12:14       ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 12:14 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev, paulus, linux-kernel, Ian Munsie

On Fri, 2010-10-01 at 07:30 -0400, Josh Boyer wrote:
> 
> > From a community aspect is anyone actually going to use this?  Is
> this going to be the equivalent of voyager on x86?  I've got nothing
> against some of the endian clean ups this introduces.  However the
> changes to misc_32.S are a bit ugly from a readability point of view.
>  Just seems like this is likely to bit-rot pretty quickly.
> 
> I'm with Kumar on this one.  Why would we want to support this?  I
> can't say I would be very willing to help anyone run in LE mode, let
> alone have it randomly selectable. 

There's some good reasons on the field ... sadly.

At this stage this is mostly an experiment, which went pretty well in
the sense that it's actually quite easy and a lot of the "fixes" are
actually reasonable cleanups to carry.

Now, the main reasons in practice are anything touching graphics.

There's quite a few IP cores out there for SoCs that don't have HW
swappers, and -tons- of more or less ugly code that can't deal with non
native pixel ordering (hell, even Xorg isn't good at it, we really only
support cards that have HW swappers today).

There's an even bigger pile of application code that deals with graphics
without any regard for endianness and is essentially unfixable.

So it becomes a matter of potential customers that will take it if it
does LE and won't if it doesn't ...

Now, I don't have a problem supporting that as the maintainer, as I
said, from a kernel standpoint, it's all quite easy to deal with. Some
of the most gory aspects in misc_32.S could probably be done in a way
that is slightly more readable, but the approach is actually good, I
think, to have macros to represent the high/low parts of register pairs.

So at this stage, I'd say, let's not dismiss it just because we all come
from a long education of hating LE for the sake of it :-)

It makes -some- sense, even if it's not necessarily on the markets
targeted by FSL today for example. At least from the kernel POV, it
doesn't seem to me to be a significant support burden at all.

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 11:55       ` Gary Thomas
@ 2010-10-01 12:15         ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 12:15 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Josh Boyer, linuxppc-dev, paulus, linux-kernel, Ian Munsie

On Fri, 2010-10-01 at 05:55 -0600, Gary Thomas wrote:
> On 10/01/2010 05:30 AM, Josh Boyer wrote:
> > On Fri, Oct 1, 2010 at 5:02 AM, Kumar Gala<galak@kernel.crashing.org>  wrote:
> >>
> >> On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:
> >>
> >>> Some PowerPC processors can be run in either big or little endian modes, some
> >>> others can map selected pages of memory as little endian, which allows the same
> >>> thing. Until now we have only supported the default big endian mode in Linux.
> >>> This patch set introduces little endian support for the 44x family of PowerPC
> >>> processors.
> >>
> >>  From a community aspect is anyone actually going to use this?  Is this going to be the equivalent of voyager on x86?  I've got nothing against some of the endian clean ups this introduces.  However the changes to misc_32.S are a bit ugly from a readability point of view.  Just seems like this is likely to bit-rot pretty quickly.
> >
> > I'm with Kumar on this one.  Why would we want to support this?  I
> > can't say I would be very willing to help anyone run in LE mode, let
> > alone have it randomly selectable.
> 
> Indeed, I thought we had killed that Windows-NT dog ~15 years ago :-)

Actually this has more to do with having to deal with code written for
ARM LE :-)

Cheers,
Ben.



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 12:15         ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 12:15 UTC (permalink / raw)
  To: Gary Thomas; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie

On Fri, 2010-10-01 at 05:55 -0600, Gary Thomas wrote:
> On 10/01/2010 05:30 AM, Josh Boyer wrote:
> > On Fri, Oct 1, 2010 at 5:02 AM, Kumar Gala<galak@kernel.crashing.org>  wrote:
> >>
> >> On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:
> >>
> >>> Some PowerPC processors can be run in either big or little endian modes, some
> >>> others can map selected pages of memory as little endian, which allows the same
> >>> thing. Until now we have only supported the default big endian mode in Linux.
> >>> This patch set introduces little endian support for the 44x family of PowerPC
> >>> processors.
> >>
> >>  From a community aspect is anyone actually going to use this?  Is this going to be the equivalent of voyager on x86?  I've got nothing against some of the endian clean ups this introduces.  However the changes to misc_32.S are a bit ugly from a readability point of view.  Just seems like this is likely to bit-rot pretty quickly.
> >
> > I'm with Kumar on this one.  Why would we want to support this?  I
> > can't say I would be very willing to help anyone run in LE mode, let
> > alone have it randomly selectable.
> 
> Indeed, I thought we had killed that Windows-NT dog ~15 years ago :-)

Actually this has more to do with having to deal with code written for
ARM LE :-)

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 11:36   ` Josh Boyer
@ 2010-10-01 12:21     ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 12:21 UTC (permalink / raw)
  To: Josh Boyer; +Cc: Ian Munsie, linux-kernel, linuxppc-dev, paulus

On Fri, 2010-10-01 at 07:36 -0400, Josh Boyer wrote:
> On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie <imunsie@au1.ibm.com> wrote:
> > This patch set in combination with a patched GCC, binutils, uClibc and
> > buildroot has allowed for a full proof of concept little endian environment on
> > a 440 Taishan board, which was able to successfully run busybox, OpenSSH and a
> > handful of other userspace programs without problems.
> 
> Aside from my general "uh, why?" stance, I'm very very hesitant to
> integrate anything in the kernel that doesn'.t have released patches
> on the toolchain side.

We aren't yet talking about merging that as-is, though I beleive at
least -some- of the patches have merit on their own, such as the proper
accessors for device-tree properties. At the very least, it would make
it less painful for archs like ARM to borrow code in that area and will
make it cleaner for sparse when we generalize endian annotations.

The toolchain work was done as a quick & dirty experiment. Whether some
"proper" work there will happen remains to be decided.

> Also, which uClibc?  The old and crusty uClibc that uses the horrible
> linuxthreads, or the somewhat less crusty that just switched to NPTL
> (which hasn't been verified on normal PowerPC that I recall).  Why not
> use glibc...

Because this was a proof of concept and as such, it was easier to deal
with uclibc initially to get busybox going :-)

> > This is not yet complete support for little endian PowerPC, some outstanding
> > issues that I am aware of are:
> >  * We only support 32bit PowerPC for now (and indeed, only 44x)
> >  * The vdso has not been fixed to be endian agnostic - any userspace program
> >   accessing it will get an unexpected result.
> >  * I have not touched PCI at all
> >  * Remaining device tree accesses still need to be examined to ensure they are
> >   correctly handling the endianess of the device tree.
> >  * Any other driver that uses the device tree is likely be broken for the same reason.
> >  * I've included a patch for the alignment handler, however it is as yet
> >   completely untested due to a property of the hardware I've been using for
> >   testing.
> 
> I'm not meeting to detract here, but the Kconfig should be dependent
> on && BROKEN until the above is fixed.

Right.

I think Ian wasn't clear enough on the fact that those patches aren't
meant to be merged in the next merge window :-) I told him to shoot them
to the list for review, comments and discussions, but if we decide to
move along with integrating that, there's definitely more work to do.

Cheers,
Ben.


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 12:21     ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 12:21 UTC (permalink / raw)
  To: Josh Boyer; +Cc: paulus, linuxppc-dev, Ian Munsie, linux-kernel

On Fri, 2010-10-01 at 07:36 -0400, Josh Boyer wrote:
> On Fri, Oct 1, 2010 at 3:05 AM, Ian Munsie <imunsie@au1.ibm.com> wrote:
> > This patch set in combination with a patched GCC, binutils, uClibc and
> > buildroot has allowed for a full proof of concept little endian environment on
> > a 440 Taishan board, which was able to successfully run busybox, OpenSSH and a
> > handful of other userspace programs without problems.
> 
> Aside from my general "uh, why?" stance, I'm very very hesitant to
> integrate anything in the kernel that doesn'.t have released patches
> on the toolchain side.

We aren't yet talking about merging that as-is, though I beleive at
least -some- of the patches have merit on their own, such as the proper
accessors for device-tree properties. At the very least, it would make
it less painful for archs like ARM to borrow code in that area and will
make it cleaner for sparse when we generalize endian annotations.

The toolchain work was done as a quick & dirty experiment. Whether some
"proper" work there will happen remains to be decided.

> Also, which uClibc?  The old and crusty uClibc that uses the horrible
> linuxthreads, or the somewhat less crusty that just switched to NPTL
> (which hasn't been verified on normal PowerPC that I recall).  Why not
> use glibc...

Because this was a proof of concept and as such, it was easier to deal
with uclibc initially to get busybox going :-)

> > This is not yet complete support for little endian PowerPC, some outstanding
> > issues that I am aware of are:
> >  * We only support 32bit PowerPC for now (and indeed, only 44x)
> >  * The vdso has not been fixed to be endian agnostic - any userspace program
> >   accessing it will get an unexpected result.
> >  * I have not touched PCI at all
> >  * Remaining device tree accesses still need to be examined to ensure they are
> >   correctly handling the endianess of the device tree.
> >  * Any other driver that uses the device tree is likely be broken for the same reason.
> >  * I've included a patch for the alignment handler, however it is as yet
> >   completely untested due to a property of the hardware I've been using for
> >   testing.
> 
> I'm not meeting to detract here, but the Kconfig should be dependent
> on && BROKEN until the above is fixed.

Right.

I think Ian wasn't clear enough on the fact that those patches aren't
meant to be merged in the next merge window :-) I told him to shoot them
to the list for review, comments and discussions, but if we decide to
move along with integrating that, there's definitely more work to do.

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
  2010-10-01 11:40     ` Josh Boyer
@ 2010-10-01 12:22       ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 12:22 UTC (permalink / raw)
  To: Josh Boyer
  Cc: Ian Munsie, linux-kernel, linuxppc-dev, Michal Marek,
	Albert Herranz, paulus, Andreas Schwab, Andrew Morton,
	Sam Ravnborg, Torez Smith

On Fri, 2010-10-01 at 07:40 -0400, Josh Boyer wrote:
> Have you tested this support with a userspace containing floating
> point instructions?  I wonder if CONFIG_MATH_EMULATION is going to
> need work at all, and if the boards with an actual FPU (440EP, 440EPx,
> 460EX, etc) would have issues. 

That's one of the things on the TODO list. We've tested that on a 44x
with no FPU so far and made sure we built without math emu.

Cheers,
Ben.



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 01/18] powerpc: Add ability to build little endian kernels
@ 2010-10-01 12:22       ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 12:22 UTC (permalink / raw)
  To: Josh Boyer
  Cc: Michal Marek, Sam Ravnborg, Albert Herranz, linux-kernel, paulus,
	Ian Munsie, Andreas Schwab, Andrew Morton, linuxppc-dev,
	Torez Smith

On Fri, 2010-10-01 at 07:40 -0400, Josh Boyer wrote:
> Have you tested this support with a userspace containing floating
> point instructions?  I wonder if CONFIG_MATH_EMULATION is going to
> need work at all, and if the boards with an actual FPU (440EP, 440EPx,
> 460EX, etc) would have issues. 

That's one of the things on the TODO list. We've tested that on a 44x
with no FPU so far and made sure we built without math emu.

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 12:15         ` Benjamin Herrenschmidt
@ 2010-10-01 12:37           ` Gary Thomas
  -1 siblings, 0 replies; 101+ messages in thread
From: Gary Thomas @ 2010-10-01 12:37 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Josh Boyer, linuxppc-dev, paulus, linux-kernel, Ian Munsie

On 10/01/2010 06:15 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2010-10-01 at 05:55 -0600, Gary Thomas wrote:
>> On 10/01/2010 05:30 AM, Josh Boyer wrote:
>>> On Fri, Oct 1, 2010 at 5:02 AM, Kumar Gala<galak@kernel.crashing.org>   wrote:
>>>>
>>>> On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:
>>>>
>>>>> Some PowerPC processors can be run in either big or little endian modes, some
>>>>> others can map selected pages of memory as little endian, which allows the same
>>>>> thing. Until now we have only supported the default big endian mode in Linux.
>>>>> This patch set introduces little endian support for the 44x family of PowerPC
>>>>> processors.
>>>>
>>>>    From a community aspect is anyone actually going to use this?  Is this going to be the equivalent of voyager on x86?  I've got nothing against some of the endian clean ups this introduces.  However the changes to misc_32.S are a bit ugly from a readability point of view.  Just seems like this is likely to bit-rot pretty quickly.
>>>
>>> I'm with Kumar on this one.  Why would we want to support this?  I
>>> can't say I would be very willing to help anyone run in LE mode, let
>>> alone have it randomly selectable.
>>
>> Indeed, I thought we had killed that Windows-NT dog ~15 years ago :-)
>
> Actually this has more to do with having to deal with code written for
> ARM LE :-)

The comment was mostly aimed as a remnder of the main reason this was considered
a long time ago.

I understand that the world has moved on, and sadly the vast majority
of hardware is now little endian (although it still baffles me why anyone
would think that way...)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 12:37           ` Gary Thomas
  0 siblings, 0 replies; 101+ messages in thread
From: Gary Thomas @ 2010-10-01 12:37 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie

On 10/01/2010 06:15 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2010-10-01 at 05:55 -0600, Gary Thomas wrote:
>> On 10/01/2010 05:30 AM, Josh Boyer wrote:
>>> On Fri, Oct 1, 2010 at 5:02 AM, Kumar Gala<galak@kernel.crashing.org>   wrote:
>>>>
>>>> On Oct 1, 2010, at 2:05 AM, Ian Munsie wrote:
>>>>
>>>>> Some PowerPC processors can be run in either big or little endian modes, some
>>>>> others can map selected pages of memory as little endian, which allows the same
>>>>> thing. Until now we have only supported the default big endian mode in Linux.
>>>>> This patch set introduces little endian support for the 44x family of PowerPC
>>>>> processors.
>>>>
>>>>    From a community aspect is anyone actually going to use this?  Is this going to be the equivalent of voyager on x86?  I've got nothing against some of the endian clean ups this introduces.  However the changes to misc_32.S are a bit ugly from a readability point of view.  Just seems like this is likely to bit-rot pretty quickly.
>>>
>>> I'm with Kumar on this one.  Why would we want to support this?  I
>>> can't say I would be very willing to help anyone run in LE mode, let
>>> alone have it randomly selectable.
>>
>> Indeed, I thought we had killed that Windows-NT dog ~15 years ago :-)
>
> Actually this has more to do with having to deal with code written for
> ARM LE :-)

The comment was mostly aimed as a remnder of the main reason this was considered
a long time ago.

I understand that the world has moved on, and sadly the vast majority
of hardware is now little endian (although it still baffles me why anyone
would think that way...)

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 12:14       ` Benjamin Herrenschmidt
@ 2010-10-01 16:20         ` Michel Dänzer
  -1 siblings, 0 replies; 101+ messages in thread
From: Michel Dänzer @ 2010-10-01 16:20 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Josh Boyer, linuxppc-dev, paulus, linux-kernel, Ian Munsie

On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote: 
> 
> Now, the main reasons in practice are anything touching graphics.
> 
> There's quite a few IP cores out there for SoCs that don't have HW
> swappers, and -tons- of more or less ugly code that can't deal with non
> native pixel ordering (hell, even Xorg isn't good at it, we really only
> support cards that have HW swappers today).

That's not true. Even the radeon driver doesn't really need the HW
swappers anymore with KMS.


> There's an even bigger pile of application code that deals with graphics
> without any regard for endianness and is essentially unfixable.

Out of curiosity, what kind of APIs are those apps using? X11 and OpenGL
have well-defined semantics wrt endianness, allowing the drivers to
handle any necessary byte swapping internally, and IME the vast majority
of apps handle this correctly.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 16:20         ` Michel Dänzer
  0 siblings, 0 replies; 101+ messages in thread
From: Michel Dänzer @ 2010-10-01 16:20 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie

On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote:=20
>=20
> Now, the main reasons in practice are anything touching graphics.
>=20
> There's quite a few IP cores out there for SoCs that don't have HW
> swappers, and -tons- of more or less ugly code that can't deal with non
> native pixel ordering (hell, even Xorg isn't good at it, we really only
> support cards that have HW swappers today).

That's not true. Even the radeon driver doesn't really need the HW
swappers anymore with KMS.


> There's an even bigger pile of application code that deals with graphics
> without any regard for endianness and is essentially unfixable.

Out of curiosity, what kind of APIs are those apps using? X11 and OpenGL
have well-defined semantics wrt endianness, allowing the drivers to
handle any necessary byte swapping internally, and IME the vast majority
of apps handle this correctly.


--=20
Earthling Michel D=C3=A4nzer           |                http://www.vmware.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 12:14       ` Benjamin Herrenschmidt
@ 2010-10-01 17:59         ` Kumar Gala
  -1 siblings, 0 replies; 101+ messages in thread
From: Kumar Gala @ 2010-10-01 17:59 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Josh Boyer, paulus, linuxppc-dev, Ian Munsie, linux-kernel


On Oct 1, 2010, at 7:14 AM, Benjamin Herrenschmidt wrote:

> On Fri, 2010-10-01 at 07:30 -0400, Josh Boyer wrote:
>> 
>>> From a community aspect is anyone actually going to use this?  Is
>> this going to be the equivalent of voyager on x86?  I've got nothing
>> against some of the endian clean ups this introduces.  However the
>> changes to misc_32.S are a bit ugly from a readability point of view.
>> Just seems like this is likely to bit-rot pretty quickly.
>> 
>> I'm with Kumar on this one.  Why would we want to support this?  I
>> can't say I would be very willing to help anyone run in LE mode, let
>> alone have it randomly selectable. 
> 
> There's some good reasons on the field ... sadly.
> 
> At this stage this is mostly an experiment, which went pretty well in
> the sense that it's actually quite easy and a lot of the "fixes" are
> actually reasonable cleanups to carry.
> 
> Now, the main reasons in practice are anything touching graphics.
> 
> There's quite a few IP cores out there for SoCs that don't have HW
> swappers, and -tons- of more or less ugly code that can't deal with non
> native pixel ordering (hell, even Xorg isn't good at it, we really only
> support cards that have HW swappers today).
> 
> There's an even bigger pile of application code that deals with graphics
> without any regard for endianness and is essentially unfixable.
> 
> So it becomes a matter of potential customers that will take it if it
> does LE and won't if it doesn't ...
> 
> Now, I don't have a problem supporting that as the maintainer, as I
> said, from a kernel standpoint, it's all quite easy to deal with. Some
> of the most gory aspects in misc_32.S could probably be done in a way
> that is slightly more readable, but the approach is actually good, I
> think, to have macros to represent the high/low parts of register pairs.
> 
> So at this stage, I'd say, let's not dismiss it just because we all come
> from a long education of hating LE for the sake of it :-)
> 
> It makes -some- sense, even if it's not necessarily on the markets
> targeted by FSL today for example. At least from the kernel POV, it
> doesn't seem to me to be a significant support burden at all.
> 
> Cheers,
> Ben.

I'm not against it, and I agree some of the patches seem like good clean up.  I'm concerned about this bit rotting pretty quickly.

- k


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 17:59         ` Kumar Gala
  0 siblings, 0 replies; 101+ messages in thread
From: Kumar Gala @ 2010-10-01 17:59 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, Ian Munsie, linux-kernel


On Oct 1, 2010, at 7:14 AM, Benjamin Herrenschmidt wrote:

> On Fri, 2010-10-01 at 07:30 -0400, Josh Boyer wrote:
>>=20
>>> =46rom a community aspect is anyone actually going to use this?  Is
>> this going to be the equivalent of voyager on x86?  I've got nothing
>> against some of the endian clean ups this introduces.  However the
>> changes to misc_32.S are a bit ugly from a readability point of view.
>> Just seems like this is likely to bit-rot pretty quickly.
>>=20
>> I'm with Kumar on this one.  Why would we want to support this?  I
>> can't say I would be very willing to help anyone run in LE mode, let
>> alone have it randomly selectable.=20
>=20
> There's some good reasons on the field ... sadly.
>=20
> At this stage this is mostly an experiment, which went pretty well in
> the sense that it's actually quite easy and a lot of the "fixes" are
> actually reasonable cleanups to carry.
>=20
> Now, the main reasons in practice are anything touching graphics.
>=20
> There's quite a few IP cores out there for SoCs that don't have HW
> swappers, and -tons- of more or less ugly code that can't deal with =
non
> native pixel ordering (hell, even Xorg isn't good at it, we really =
only
> support cards that have HW swappers today).
>=20
> There's an even bigger pile of application code that deals with =
graphics
> without any regard for endianness and is essentially unfixable.
>=20
> So it becomes a matter of potential customers that will take it if it
> does LE and won't if it doesn't ...
>=20
> Now, I don't have a problem supporting that as the maintainer, as I
> said, from a kernel standpoint, it's all quite easy to deal with. Some
> of the most gory aspects in misc_32.S could probably be done in a way
> that is slightly more readable, but the approach is actually good, I
> think, to have macros to represent the high/low parts of register =
pairs.
>=20
> So at this stage, I'd say, let's not dismiss it just because we all =
come
> from a long education of hating LE for the sake of it :-)
>=20
> It makes -some- sense, even if it's not necessarily on the markets
> targeted by FSL today for example. At least from the kernel POV, it
> doesn't seem to me to be a significant support burden at all.
>=20
> Cheers,
> Ben.

I'm not against it, and I agree some of the patches seem like good clean =
up.  I'm concerned about this bit rotting pretty quickly.

- k

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 15/18] mtd: Fix endianness issues from device tree
  2010-10-01  7:06   ` Ian Munsie
  (?)
@ 2010-10-01 19:29     ` Artem Bityutskiy
  -1 siblings, 0 replies; 101+ messages in thread
From: Artem Bityutskiy @ 2010-10-01 19:29 UTC (permalink / raw)
  To: Ian Munsie
  Cc: linux-kernel, linuxppc-dev, benh, paulus, David Woodhouse,
	Grant Likely, Julia Lawall, Sean MacLennan, Jason Gunthorpe,
	Artem Bityutskiy, H Hartley Sweeten, Anatolij Gustschin,
	Steve Deiters, David S. Miller, Tejun Heo, linux-mtd

On Fri, 2010-10-01 at 17:06 +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
> 
> This patch adds the appropriate conversions to correct the endianness
> issues in the MTD driver whenever it accesses the device tree (which is
> always big endian).
> 
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>

Pushed to l2-mtd-2.6.git, thanks!

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 15/18] mtd: Fix endianness issues from device tree
@ 2010-10-01 19:29     ` Artem Bityutskiy
  0 siblings, 0 replies; 101+ messages in thread
From: Artem Bityutskiy @ 2010-10-01 19:29 UTC (permalink / raw)
  To: Ian Munsie
  Cc: Jason Gunthorpe, Artem Bityutskiy, linuxppc-dev, linux-kernel,
	H Hartley Sweeten, paulus, linux-mtd, Sean MacLennan, Tejun Heo,
	Julia Lawall, Steve Deiters, Anatolij Gustschin, David Woodhouse,
	David S. Miller

On Fri, 2010-10-01 at 17:06 +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
> 
> This patch adds the appropriate conversions to correct the endianness
> issues in the MTD driver whenever it accesses the device tree (which is
> always big endian).
> 
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>

Pushed to l2-mtd-2.6.git, thanks!

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 15/18] mtd: Fix endianness issues from device tree
@ 2010-10-01 19:29     ` Artem Bityutskiy
  0 siblings, 0 replies; 101+ messages in thread
From: Artem Bityutskiy @ 2010-10-01 19:29 UTC (permalink / raw)
  To: Ian Munsie
  Cc: Jason Gunthorpe, Artem Bityutskiy, benh, linuxppc-dev,
	linux-kernel, Grant Likely, H Hartley Sweeten, paulus, linux-mtd,
	Sean MacLennan, Tejun Heo, Julia Lawall, Steve Deiters,
	Anatolij Gustschin, David Woodhouse, David S. Miller

On Fri, 2010-10-01 at 17:06 +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
> 
> This patch adds the appropriate conversions to correct the endianness
> issues in the MTD driver whenever it accesses the device tree (which is
> always big endian).
> 
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>

Pushed to l2-mtd-2.6.git, thanks!

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 16:20         ` Michel Dänzer
@ 2010-10-01 20:50           ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 20:50 UTC (permalink / raw)
  To: Michel Dänzer
  Cc: Josh Boyer, linuxppc-dev, paulus, linux-kernel, Ian Munsie

On Fri, 2010-10-01 at 18:20 +0200, Michel Dänzer wrote:
> On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote: 
> > 
> > Now, the main reasons in practice are anything touching graphics.
> > 
> > There's quite a few IP cores out there for SoCs that don't have HW
> > swappers, and -tons- of more or less ugly code that can't deal with non
> > native pixel ordering (hell, even Xorg isn't good at it, we really only
> > support cards that have HW swappers today).
> 
> That's not true. Even the radeon driver doesn't really need the HW
> swappers anymore with KMS.

And last I looked X still pukes if you give it a pixmap in non native
byte order but that might have been fixed. In any case, X is far from
the target here. More like existing stacks for embedded SoCs, including
codecs etc... all written for LE.

> > There's an even bigger pile of application code that deals with graphics
> > without any regard for endianness and is essentially unfixable.
> 
> Out of curiosity, what kind of APIs are those apps using? X11 and OpenGL
> have well-defined semantics wrt endianness, allowing the drivers to
> handle any necessary byte swapping internally, and IME the vast majority
> of apps handle this correctly.

So why is it so hard to get any video card working on ppc ? :-) I
haven't even started to look at r6xx which -does- have HW swapping
capabilities...

In this case tho, see above. I don't even need to care much about the
details, customers are making the point over and over again. It might be
fixable, but either they don't have the resources to fix it or don't
want to fix it, or their -own- customers won't chose their product if
it's BE for "perceived" difficulty of porting reason, whether they are
valid or not.

So it boils down to do we want to be another Amiga sinking into oblivion
but keeping our purity intact, or do we make that "reasonably easy"
thing to support LE at least at the kernel level for now, and -possibly-
give powerpc a bit more juice on the market for a while longer ?

Cheers,
Ben.



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 20:50           ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 20:50 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie

On Fri, 2010-10-01 at 18:20 +0200, Michel Dänzer wrote:
> On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote: 
> > 
> > Now, the main reasons in practice are anything touching graphics.
> > 
> > There's quite a few IP cores out there for SoCs that don't have HW
> > swappers, and -tons- of more or less ugly code that can't deal with non
> > native pixel ordering (hell, even Xorg isn't good at it, we really only
> > support cards that have HW swappers today).
> 
> That's not true. Even the radeon driver doesn't really need the HW
> swappers anymore with KMS.

And last I looked X still pukes if you give it a pixmap in non native
byte order but that might have been fixed. In any case, X is far from
the target here. More like existing stacks for embedded SoCs, including
codecs etc... all written for LE.

> > There's an even bigger pile of application code that deals with graphics
> > without any regard for endianness and is essentially unfixable.
> 
> Out of curiosity, what kind of APIs are those apps using? X11 and OpenGL
> have well-defined semantics wrt endianness, allowing the drivers to
> handle any necessary byte swapping internally, and IME the vast majority
> of apps handle this correctly.

So why is it so hard to get any video card working on ppc ? :-) I
haven't even started to look at r6xx which -does- have HW swapping
capabilities...

In this case tho, see above. I don't even need to care much about the
details, customers are making the point over and over again. It might be
fixable, but either they don't have the resources to fix it or don't
want to fix it, or their -own- customers won't chose their product if
it's BE for "perceived" difficulty of porting reason, whether they are
valid or not.

So it boils down to do we want to be another Amiga sinking into oblivion
but keeping our purity intact, or do we make that "reasonably easy"
thing to support LE at least at the kernel level for now, and -possibly-
give powerpc a bit more juice on the market for a while longer ?

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 17:59         ` Kumar Gala
@ 2010-10-01 20:51           ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 20:51 UTC (permalink / raw)
  To: Kumar Gala; +Cc: Josh Boyer, paulus, linuxppc-dev, Ian Munsie, linux-kernel

On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
> I'm not against it, and I agree some of the patches seem like good
> clean up.  I'm concerned about this bit rotting pretty quickly.

Maybe. Most of it doesn't seem to be that bit-rottable.

The changes to the asm stuff in misc_32.S for example are functions we
never ever touch once written (libgcc replacements) so I don't see them
rotting more with LE support than they did with BE :-)

What might rot is that we might introduce new LE breakage, true, and I
suppose it's going to be to some extent my job to at least every now and
then shoot that thing on a 44x to see if it still flies.

Cheers,
Ben.


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 20:51           ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 20:51 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, paulus, Ian Munsie, linux-kernel

On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
> I'm not against it, and I agree some of the patches seem like good
> clean up.  I'm concerned about this bit rotting pretty quickly.

Maybe. Most of it doesn't seem to be that bit-rottable.

The changes to the asm stuff in misc_32.S for example are functions we
never ever touch once written (libgcc replacements) so I don't see them
rotting more with LE support than they did with BE :-)

What might rot is that we might introduce new LE breakage, true, and I
suppose it's going to be to some extent my job to at least every now and
then shoot that thing on a 44x to see if it still flies.

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 20:51           ` Benjamin Herrenschmidt
@ 2010-10-01 22:03             ` Olof Johansson
  -1 siblings, 0 replies; 101+ messages in thread
From: Olof Johansson @ 2010-10-01 22:03 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Kumar Gala, linuxppc-dev, paulus, Ian Munsie, linux-kernel

On Sat, Oct 02, 2010 at 06:51:55AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
> > I'm not against it, and I agree some of the patches seem like good
> > clean up.  I'm concerned about this bit rotting pretty quickly.
> 
> Maybe. Most of it doesn't seem to be that bit-rottable.
> 
> The changes to the asm stuff in misc_32.S for example are functions we
> never ever touch once written (libgcc replacements) so I don't see them
> rotting more with LE support than they did with BE :-)

Does KVM/qemu support running LE guest on BE host? That'd help keeping
the bitrot lower. :)



-Olof

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 22:03             ` Olof Johansson
  0 siblings, 0 replies; 101+ messages in thread
From: Olof Johansson @ 2010-10-01 22:03 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie

On Sat, Oct 02, 2010 at 06:51:55AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
> > I'm not against it, and I agree some of the patches seem like good
> > clean up.  I'm concerned about this bit rotting pretty quickly.
> 
> Maybe. Most of it doesn't seem to be that bit-rottable.
> 
> The changes to the asm stuff in misc_32.S for example are functions we
> never ever touch once written (libgcc replacements) so I don't see them
> rotting more with LE support than they did with BE :-)

Does KVM/qemu support running LE guest on BE host? That'd help keeping
the bitrot lower. :)



-Olof

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 22:03             ` Olof Johansson
@ 2010-10-01 22:28               ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 22:28 UTC (permalink / raw)
  To: Olof Johansson; +Cc: Kumar Gala, linuxppc-dev, paulus, Ian Munsie, linux-kernel

On Fri, 2010-10-01 at 17:03 -0500, Olof Johansson wrote:
> > Maybe. Most of it doesn't seem to be that bit-rottable.
> > 
> > The changes to the asm stuff in misc_32.S for example are functions we
> > never ever touch once written (libgcc replacements) so I don't see them
> > rotting more with LE support than they did with BE :-)
> 
> Does KVM/qemu support running LE guest on BE host? That'd help keeping
> the bitrot lower. :) 

Not yet I suppose :-) But then, I'm not sure it would make a big
difference, if you have a 440 board in the first place, you can boot
either LE or BE, no need for a special FW or anything.

What we've done is basically keep the zImage wrapper BE (for now at
least), and have it trampoline to LE when executing the actual kernel
(using a cuImage, of course a device-tree enabled u-Boot would probably
need something akin to a proper ePAPR zImage to do that but that's
reasonably easy to do nowadays).


Cheers,
Ben.



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-01 22:28               ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-01 22:28 UTC (permalink / raw)
  To: Olof Johansson; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie

On Fri, 2010-10-01 at 17:03 -0500, Olof Johansson wrote:
> > Maybe. Most of it doesn't seem to be that bit-rottable.
> > 
> > The changes to the asm stuff in misc_32.S for example are functions we
> > never ever touch once written (libgcc replacements) so I don't see them
> > rotting more with LE support than they did with BE :-)
> 
> Does KVM/qemu support running LE guest on BE host? That'd help keeping
> the bitrot lower. :) 

Not yet I suppose :-) But then, I'm not sure it would make a big
difference, if you have a 440 board in the first place, you can boot
either LE or BE, no need for a special FW or anything.

What we've done is basically keep the zImage wrapper BE (for now at
least), and have it trampoline to LE when executing the actual kernel
(using a cuImage, of course a device-tree enabled u-Boot would probably
need something akin to a proper ePAPR zImage to do that but that's
reasonably easy to do nowadays).


Cheers,
Ben.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 09/18] powerpc: Support device tree regardless of CPU endianness
  2010-10-01  7:06   ` Ian Munsie
@ 2010-10-03  3:15     ` Grant Likely
  -1 siblings, 0 replies; 101+ messages in thread
From: Grant Likely @ 2010-10-03  3:15 UTC (permalink / raw)
  To: Ian Munsie
  Cc: linux-kernel, linuxppc-dev, benh, paulus, Wolfram Sang,
	Michal Simek, Jeremy Kerr, devicetree-discuss

On Fri, Oct 01, 2010 at 05:06:02PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
> 
> On PowerPC the device tree is always big endian, but the CPU could be
> either, so add be32_to_cpu where appropriate and change the types of
> device tree data to __be32 etc to allow sparse to locate endian issues.
> 
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>

Acked-by: Grant Likely <grant.likely@secretlab.ca>

But I won't merge this through my tree unless Ben asks me to.

g.

> ---
>  arch/powerpc/kernel/prom.c |   60 ++++++++++++++++++++++----------------------
>  1 files changed, 30 insertions(+), 30 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index fed9bf6..9b9ebb2 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -188,16 +188,16 @@ static void __init check_cpu_pa_features(unsigned long node)
>  #ifdef CONFIG_PPC_STD_MMU_64
>  static void __init check_cpu_slb_size(unsigned long node)
>  {
> -	u32 *slb_size_ptr;
> +	__be32 *slb_size_ptr;
>  
>  	slb_size_ptr = of_get_flat_dt_prop(node, "slb-size", NULL);
>  	if (slb_size_ptr != NULL) {
> -		mmu_slb_size = *slb_size_ptr;
> +		mmu_slb_size = be32_to_cpup(slb_size_ptr);
>  		return;
>  	}
>  	slb_size_ptr = of_get_flat_dt_prop(node, "ibm,slb-size", NULL);
>  	if (slb_size_ptr != NULL) {
> -		mmu_slb_size = *slb_size_ptr;
> +		mmu_slb_size = be32_to_cpup(slb_size_ptr);
>  	}
>  }
>  #else
> @@ -252,11 +252,11 @@ static void __init check_cpu_feature_properties(unsigned long node)
>  {
>  	unsigned long i;
>  	struct feature_property *fp = feature_properties;
> -	const u32 *prop;
> +	const __be32 *prop;
>  
>  	for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
>  		prop = of_get_flat_dt_prop(node, fp->name, NULL);
> -		if (prop && *prop >= fp->min_value) {
> +		if (prop && be32_to_cpup(prop) >= fp->min_value) {
>  			cur_cpu_spec->cpu_features |= fp->cpu_feature;
>  			cur_cpu_spec->cpu_user_features |= fp->cpu_user_ftr;
>  		}
> @@ -269,8 +269,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>  {
>  	static int logical_cpuid = 0;
>  	char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> -	const u32 *prop;
> -	const u32 *intserv;
> +	const __be32 *prop;
> +	const __be32 *intserv;
>  	int i, nthreads;
>  	unsigned long len;
>  	int found = 0;
> @@ -297,9 +297,9 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>  		 * version 2 of the kexec param format adds the phys cpuid of
>  		 * booted proc.
>  		 */
> -		if (initial_boot_params && initial_boot_params->version >= 2) {
> -			if (intserv[i] ==
> -					initial_boot_params->boot_cpuid_phys) {
> +		if (initial_boot_params && be32_to_cpu(initial_boot_params->version) >= 2) {
> +			if (be32_to_cpu(intserv[i]) ==
> +					be32_to_cpu(initial_boot_params->boot_cpuid_phys)) {
>  				found = 1;
>  				break;
>  			}
> @@ -324,9 +324,9 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>  
>  	if (found) {
>  		DBG("boot cpu: logical %d physical %d\n", logical_cpuid,
> -			intserv[i]);
> +			be32_to_cpu(intserv[i]));
>  		boot_cpuid = logical_cpuid;
> -		set_hard_smp_processor_id(boot_cpuid, intserv[i]);
> +		set_hard_smp_processor_id(boot_cpuid, be32_to_cpu(intserv[i]));
>  
>  		/*
>  		 * PAPR defines "logical" PVR values for cpus that
> @@ -343,8 +343,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>  		 * it uses 0x0f000001.
>  		 */
>  		prop = of_get_flat_dt_prop(node, "cpu-version", NULL);
> -		if (prop && (*prop & 0xff000000) == 0x0f000000)
> -			identify_cpu(0, *prop);
> +		if (prop && (be32_to_cpup(prop) & 0xff000000) == 0x0f000000)
> +			identify_cpu(0, be32_to_cpup(prop));
>  
>  		identical_pvr_fixup(node);
>  	}
> @@ -365,7 +365,7 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>  
>  void __init early_init_dt_scan_chosen_arch(unsigned long node)
>  {
> -	unsigned long *lprop;
> +	unsigned long *lprop; /* All these set by kernel, so no need to convert endian */
>  
>  #ifdef CONFIG_PPC64
>  	/* check if iommu is forced on or off */
> @@ -524,16 +524,16 @@ void __init early_init_dt_setup_initrd_arch(unsigned long start,
>  static void __init early_reserve_mem(void)
>  {
>  	u64 base, size;
> -	u64 *reserve_map;
> +	__be64 *reserve_map;
>  	unsigned long self_base;
>  	unsigned long self_size;
>  
> -	reserve_map = (u64 *)(((unsigned long)initial_boot_params) +
> -					initial_boot_params->off_mem_rsvmap);
> +	reserve_map = (__be64 *)(((unsigned long)initial_boot_params) +
> +			be32_to_cpu(initial_boot_params->off_mem_rsvmap));
>  
>  	/* before we do anything, lets reserve the dt blob */
>  	self_base = __pa((unsigned long)initial_boot_params);
> -	self_size = initial_boot_params->totalsize;
> +	self_size = be32_to_cpu(initial_boot_params->totalsize);
>  	memblock_reserve(self_base, self_size);
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> @@ -547,13 +547,13 @@ static void __init early_reserve_mem(void)
>  	 * Handle the case where we might be booting from an old kexec
>  	 * image that setup the mem_rsvmap as pairs of 32-bit values
>  	 */
> -	if (*reserve_map > 0xffffffffull) {
> +	if (be64_to_cpup(reserve_map) > 0xffffffffull) {
>  		u32 base_32, size_32;
> -		u32 *reserve_map_32 = (u32 *)reserve_map;
> +		__be32 *reserve_map_32 = (__be32 *)reserve_map;
>  
>  		while (1) {
> -			base_32 = *(reserve_map_32++);
> -			size_32 = *(reserve_map_32++);
> +			base_32 = be32_to_cpup(reserve_map_32++);
> +			size_32 = be32_to_cpup(reserve_map_32++);
>  			if (size_32 == 0)
>  				break;
>  			/* skip if the reservation is for the blob */
> @@ -566,8 +566,8 @@ static void __init early_reserve_mem(void)
>  	}
>  #endif
>  	while (1) {
> -		base = *(reserve_map++);
> -		size = *(reserve_map++);
> +		base = be64_to_cpup(reserve_map++);
> +		size = be64_to_cpup(reserve_map++);
>  		if (size == 0)
>  			break;
>  		DBG("reserving: %llx -> %llx\n", base, size);
> @@ -860,7 +860,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
>  	hardid = get_hard_smp_processor_id(cpu);
>  
>  	for_each_node_by_type(np, "cpu") {
> -		const u32 *intserv;
> +		const __be32 *intserv;
>  		unsigned int plen, t;
>  
>  		/* Check for ibm,ppc-interrupt-server#s. If it doesn't exist
> @@ -869,10 +869,10 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
>  		intserv = of_get_property(np, "ibm,ppc-interrupt-server#s",
>  				&plen);
>  		if (intserv == NULL) {
> -			const u32 *reg = of_get_property(np, "reg", NULL);
> +			const __be32 *reg = of_get_property(np, "reg", NULL);
>  			if (reg == NULL)
>  				continue;
> -			if (*reg == hardid) {
> +			if (be32_to_cpup(reg) == hardid) {
>  				if (thread)
>  					*thread = 0;
>  				return np;
> @@ -880,7 +880,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
>  		} else {
>  			plen /= sizeof(u32);
>  			for (t = 0; t < plen; t++) {
> -				if (hardid == intserv[t]) {
> +				if (hardid == be32_to_cpu(intserv[t])) {
>  					if (thread)
>  						*thread = t;
>  					return np;
> @@ -900,7 +900,7 @@ static int __init export_flat_device_tree(void)
>  	struct dentry *d;
>  
>  	flat_dt_blob.data = initial_boot_params;
> -	flat_dt_blob.size = initial_boot_params->totalsize;
> +	flat_dt_blob.size = be32_to_cpu(initial_boot_params->totalsize);
>  
>  	d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
>  				powerpc_debugfs_root, &flat_dt_blob);
> -- 
> 1.7.1
> 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 09/18] powerpc: Support device tree regardless of CPU endianness
@ 2010-10-03  3:15     ` Grant Likely
  0 siblings, 0 replies; 101+ messages in thread
From: Grant Likely @ 2010-10-03  3:15 UTC (permalink / raw)
  To: Ian Munsie
  Cc: Michal Simek, devicetree-discuss, linux-kernel, paulus,
	Jeremy Kerr, linuxppc-dev

On Fri, Oct 01, 2010 at 05:06:02PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
> 
> On PowerPC the device tree is always big endian, but the CPU could be
> either, so add be32_to_cpu where appropriate and change the types of
> device tree data to __be32 etc to allow sparse to locate endian issues.
> 
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>

Acked-by: Grant Likely <grant.likely@secretlab.ca>

But I won't merge this through my tree unless Ben asks me to.

g.

> ---
>  arch/powerpc/kernel/prom.c |   60 ++++++++++++++++++++++----------------------
>  1 files changed, 30 insertions(+), 30 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index fed9bf6..9b9ebb2 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -188,16 +188,16 @@ static void __init check_cpu_pa_features(unsigned long node)
>  #ifdef CONFIG_PPC_STD_MMU_64
>  static void __init check_cpu_slb_size(unsigned long node)
>  {
> -	u32 *slb_size_ptr;
> +	__be32 *slb_size_ptr;
>  
>  	slb_size_ptr = of_get_flat_dt_prop(node, "slb-size", NULL);
>  	if (slb_size_ptr != NULL) {
> -		mmu_slb_size = *slb_size_ptr;
> +		mmu_slb_size = be32_to_cpup(slb_size_ptr);
>  		return;
>  	}
>  	slb_size_ptr = of_get_flat_dt_prop(node, "ibm,slb-size", NULL);
>  	if (slb_size_ptr != NULL) {
> -		mmu_slb_size = *slb_size_ptr;
> +		mmu_slb_size = be32_to_cpup(slb_size_ptr);
>  	}
>  }
>  #else
> @@ -252,11 +252,11 @@ static void __init check_cpu_feature_properties(unsigned long node)
>  {
>  	unsigned long i;
>  	struct feature_property *fp = feature_properties;
> -	const u32 *prop;
> +	const __be32 *prop;
>  
>  	for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
>  		prop = of_get_flat_dt_prop(node, fp->name, NULL);
> -		if (prop && *prop >= fp->min_value) {
> +		if (prop && be32_to_cpup(prop) >= fp->min_value) {
>  			cur_cpu_spec->cpu_features |= fp->cpu_feature;
>  			cur_cpu_spec->cpu_user_features |= fp->cpu_user_ftr;
>  		}
> @@ -269,8 +269,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>  {
>  	static int logical_cpuid = 0;
>  	char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> -	const u32 *prop;
> -	const u32 *intserv;
> +	const __be32 *prop;
> +	const __be32 *intserv;
>  	int i, nthreads;
>  	unsigned long len;
>  	int found = 0;
> @@ -297,9 +297,9 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>  		 * version 2 of the kexec param format adds the phys cpuid of
>  		 * booted proc.
>  		 */
> -		if (initial_boot_params && initial_boot_params->version >= 2) {
> -			if (intserv[i] ==
> -					initial_boot_params->boot_cpuid_phys) {
> +		if (initial_boot_params && be32_to_cpu(initial_boot_params->version) >= 2) {
> +			if (be32_to_cpu(intserv[i]) ==
> +					be32_to_cpu(initial_boot_params->boot_cpuid_phys)) {
>  				found = 1;
>  				break;
>  			}
> @@ -324,9 +324,9 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>  
>  	if (found) {
>  		DBG("boot cpu: logical %d physical %d\n", logical_cpuid,
> -			intserv[i]);
> +			be32_to_cpu(intserv[i]));
>  		boot_cpuid = logical_cpuid;
> -		set_hard_smp_processor_id(boot_cpuid, intserv[i]);
> +		set_hard_smp_processor_id(boot_cpuid, be32_to_cpu(intserv[i]));
>  
>  		/*
>  		 * PAPR defines "logical" PVR values for cpus that
> @@ -343,8 +343,8 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>  		 * it uses 0x0f000001.
>  		 */
>  		prop = of_get_flat_dt_prop(node, "cpu-version", NULL);
> -		if (prop && (*prop & 0xff000000) == 0x0f000000)
> -			identify_cpu(0, *prop);
> +		if (prop && (be32_to_cpup(prop) & 0xff000000) == 0x0f000000)
> +			identify_cpu(0, be32_to_cpup(prop));
>  
>  		identical_pvr_fixup(node);
>  	}
> @@ -365,7 +365,7 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
>  
>  void __init early_init_dt_scan_chosen_arch(unsigned long node)
>  {
> -	unsigned long *lprop;
> +	unsigned long *lprop; /* All these set by kernel, so no need to convert endian */
>  
>  #ifdef CONFIG_PPC64
>  	/* check if iommu is forced on or off */
> @@ -524,16 +524,16 @@ void __init early_init_dt_setup_initrd_arch(unsigned long start,
>  static void __init early_reserve_mem(void)
>  {
>  	u64 base, size;
> -	u64 *reserve_map;
> +	__be64 *reserve_map;
>  	unsigned long self_base;
>  	unsigned long self_size;
>  
> -	reserve_map = (u64 *)(((unsigned long)initial_boot_params) +
> -					initial_boot_params->off_mem_rsvmap);
> +	reserve_map = (__be64 *)(((unsigned long)initial_boot_params) +
> +			be32_to_cpu(initial_boot_params->off_mem_rsvmap));
>  
>  	/* before we do anything, lets reserve the dt blob */
>  	self_base = __pa((unsigned long)initial_boot_params);
> -	self_size = initial_boot_params->totalsize;
> +	self_size = be32_to_cpu(initial_boot_params->totalsize);
>  	memblock_reserve(self_base, self_size);
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> @@ -547,13 +547,13 @@ static void __init early_reserve_mem(void)
>  	 * Handle the case where we might be booting from an old kexec
>  	 * image that setup the mem_rsvmap as pairs of 32-bit values
>  	 */
> -	if (*reserve_map > 0xffffffffull) {
> +	if (be64_to_cpup(reserve_map) > 0xffffffffull) {
>  		u32 base_32, size_32;
> -		u32 *reserve_map_32 = (u32 *)reserve_map;
> +		__be32 *reserve_map_32 = (__be32 *)reserve_map;
>  
>  		while (1) {
> -			base_32 = *(reserve_map_32++);
> -			size_32 = *(reserve_map_32++);
> +			base_32 = be32_to_cpup(reserve_map_32++);
> +			size_32 = be32_to_cpup(reserve_map_32++);
>  			if (size_32 == 0)
>  				break;
>  			/* skip if the reservation is for the blob */
> @@ -566,8 +566,8 @@ static void __init early_reserve_mem(void)
>  	}
>  #endif
>  	while (1) {
> -		base = *(reserve_map++);
> -		size = *(reserve_map++);
> +		base = be64_to_cpup(reserve_map++);
> +		size = be64_to_cpup(reserve_map++);
>  		if (size == 0)
>  			break;
>  		DBG("reserving: %llx -> %llx\n", base, size);
> @@ -860,7 +860,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
>  	hardid = get_hard_smp_processor_id(cpu);
>  
>  	for_each_node_by_type(np, "cpu") {
> -		const u32 *intserv;
> +		const __be32 *intserv;
>  		unsigned int plen, t;
>  
>  		/* Check for ibm,ppc-interrupt-server#s. If it doesn't exist
> @@ -869,10 +869,10 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
>  		intserv = of_get_property(np, "ibm,ppc-interrupt-server#s",
>  				&plen);
>  		if (intserv == NULL) {
> -			const u32 *reg = of_get_property(np, "reg", NULL);
> +			const __be32 *reg = of_get_property(np, "reg", NULL);
>  			if (reg == NULL)
>  				continue;
> -			if (*reg == hardid) {
> +			if (be32_to_cpup(reg) == hardid) {
>  				if (thread)
>  					*thread = 0;
>  				return np;
> @@ -880,7 +880,7 @@ struct device_node *of_get_cpu_node(int cpu, unsigned int *thread)
>  		} else {
>  			plen /= sizeof(u32);
>  			for (t = 0; t < plen; t++) {
> -				if (hardid == intserv[t]) {
> +				if (hardid == be32_to_cpu(intserv[t])) {
>  					if (thread)
>  						*thread = t;
>  					return np;
> @@ -900,7 +900,7 @@ static int __init export_flat_device_tree(void)
>  	struct dentry *d;
>  
>  	flat_dt_blob.data = initial_boot_params;
> -	flat_dt_blob.size = initial_boot_params->totalsize;
> +	flat_dt_blob.size = be32_to_cpu(initial_boot_params->totalsize);
>  
>  	d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
>  				powerpc_debugfs_root, &flat_dt_blob);
> -- 
> 1.7.1
> 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 09/18] powerpc: Support device tree regardless of CPU endianness
  2010-10-03  3:15     ` Grant Likely
@ 2010-10-03  6:22       ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-03  6:22 UTC (permalink / raw)
  To: Grant Likely
  Cc: Ian Munsie, linux-kernel, linuxppc-dev, paulus, Wolfram Sang,
	Michal Simek, Jeremy Kerr, devicetree-discuss

On Sat, 2010-10-02 at 21:15 -0600, Grant Likely wrote:
> 
> But I won't merge this through my tree unless Ben asks me to. 

Being careful heh ? :-)

I'll take care of these.

Cheers,
Ben.



^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 09/18] powerpc: Support device tree regardless of CPU endianness
@ 2010-10-03  6:22       ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-03  6:22 UTC (permalink / raw)
  To: Grant Likely
  Cc: Michal Simek, devicetree-discuss, linux-kernel, paulus,
	Ian Munsie, Jeremy Kerr, linuxppc-dev

On Sat, 2010-10-02 at 21:15 -0600, Grant Likely wrote:
> 
> But I won't merge this through my tree unless Ben asks me to. 

Being careful heh ? :-)

I'll take care of these.

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 20:50           ` Benjamin Herrenschmidt
@ 2010-10-04 10:30             ` Michel Dänzer
  -1 siblings, 0 replies; 101+ messages in thread
From: Michel Dänzer @ 2010-10-04 10:30 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Josh Boyer, linuxppc-dev, paulus, linux-kernel, Ian Munsie

On Sam, 2010-10-02 at 06:50 +1000, Benjamin Herrenschmidt wrote: 
> On Fri, 2010-10-01 at 18:20 +0200, Michel Dänzer wrote:
> > On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote: 
> > > 
> > > Now, the main reasons in practice are anything touching graphics.
> > > 
> > > There's quite a few IP cores out there for SoCs that don't have HW
> > > swappers, and -tons- of more or less ugly code that can't deal with non
> > > native pixel ordering (hell, even Xorg isn't good at it, we really only
> > > support cards that have HW swappers today).
> > 
> > That's not true. Even the radeon driver doesn't really need the HW
> > swappers anymore with KMS.
> 
> And last I looked X still pukes if you give it a pixmap in non native
> byte order but that might have been fixed.

I'm not sure what exactly you mean by that, but I'm not aware of any
such issues offhand.


> > > There's an even bigger pile of application code that deals with graphics
> > > without any regard for endianness and is essentially unfixable.
> > 
> > Out of curiosity, what kind of APIs are those apps using? X11 and OpenGL
> > have well-defined semantics wrt endianness, allowing the drivers to
> > handle any necessary byte swapping internally, and IME the vast majority
> > of apps handle this correctly.
> 
> So why is it so hard to get any video card working on ppc ? :-)

I didn't say anything about that, just that IME it should be mostly
possible to deal with endianness within the driver stack.


Note that I'm not arguing against these changes, just pointing out some
apparent inaccuracies in the reasoning for them.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-04 10:30             ` Michel Dänzer
  0 siblings, 0 replies; 101+ messages in thread
From: Michel Dänzer @ 2010-10-04 10:30 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie

On Sam, 2010-10-02 at 06:50 +1000, Benjamin Herrenschmidt wrote:=20
> On Fri, 2010-10-01 at 18:20 +0200, Michel D=C3=A4nzer wrote:
> > On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote:=20
> > >=20
> > > Now, the main reasons in practice are anything touching graphics.
> > >=20
> > > There's quite a few IP cores out there for SoCs that don't have HW
> > > swappers, and -tons- of more or less ugly code that can't deal with n=
on
> > > native pixel ordering (hell, even Xorg isn't good at it, we really on=
ly
> > > support cards that have HW swappers today).
> >=20
> > That's not true. Even the radeon driver doesn't really need the HW
> > swappers anymore with KMS.
>=20
> And last I looked X still pukes if you give it a pixmap in non native
> byte order but that might have been fixed.

I'm not sure what exactly you mean by that, but I'm not aware of any
such issues offhand.


> > > There's an even bigger pile of application code that deals with graph=
ics
> > > without any regard for endianness and is essentially unfixable.
> >=20
> > Out of curiosity, what kind of APIs are those apps using? X11 and OpenG=
L
> > have well-defined semantics wrt endianness, allowing the drivers to
> > handle any necessary byte swapping internally, and IME the vast majorit=
y
> > of apps handle this correctly.
>=20
> So why is it so hard to get any video card working on ppc ? :-)

I didn't say anything about that, just that IME it should be mostly
possible to deal with endianness within the driver stack.


Note that I'm not arguing against these changes, just pointing out some
apparent inaccuracies in the reasoning for them.


--=20
Earthling Michel D=C3=A4nzer           |                http://www.vmware.c=
om
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-04 10:30             ` Michel Dänzer
@ 2010-10-04 22:50               ` Benjamin Herrenschmidt
  -1 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-04 22:50 UTC (permalink / raw)
  To: Michel Dänzer
  Cc: Josh Boyer, linuxppc-dev, paulus, linux-kernel, Ian Munsie

On Mon, 2010-10-04 at 12:30 +0200, Michel Dänzer wrote:

> > And last I looked X still pukes if you give it a pixmap in non native
> > byte order but that might have been fixed.
> 
> I'm not sure what exactly you mean by that, but I'm not aware of any
> such issues offhand.

Hrm, I meant on the DDX side. Anyways, doesn't matter. Even if it works
fine on X side. Fact is, there's tons and tons of existing SW stack and
drivers on the field that are totally incapable of doing BE and
essentially unfixable without major work that the customer(s) is(are)
unwilling to do at this stage.

(Think embedded gfx IP cores mostly, including codecs etc...)

> I didn't say anything about that, just that IME it should be mostly
> possible to deal with endianness within the driver stack.

To some extent yes. Completely, I'm not sure. Apps manipulating pixels,
such as video players doing hand-made overlay etc... will potentially
have issues. It's more than actual pixel byte ordering. It's anything
that accesses a quantity in memory using different size accessors, ie,
storing a u32 and then expecting to find the LSB at u8* of the same
address etc... that sort of stuff happens more often in gfx-oriented
code than anywhere else in my experience.

> Note that I'm not arguing against these changes, just pointing out some
> apparent inaccuracies in the reasoning for them.

Right, I possibly made an incorrect statement relative to Xorg (I had
assumed the fb layer only worked properly in native endian format), but
that doesn't matter much since the problem here is existing code &
drivers and goes way beyond X (probably no X on the target setups
anyways).

Cheers,
Ben


^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-04 22:50               ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 101+ messages in thread
From: Benjamin Herrenschmidt @ 2010-10-04 22:50 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: paulus, linuxppc-dev, linux-kernel, Ian Munsie

On Mon, 2010-10-04 at 12:30 +0200, Michel Dänzer wrote:

> > And last I looked X still pukes if you give it a pixmap in non native
> > byte order but that might have been fixed.
> 
> I'm not sure what exactly you mean by that, but I'm not aware of any
> such issues offhand.

Hrm, I meant on the DDX side. Anyways, doesn't matter. Even if it works
fine on X side. Fact is, there's tons and tons of existing SW stack and
drivers on the field that are totally incapable of doing BE and
essentially unfixable without major work that the customer(s) is(are)
unwilling to do at this stage.

(Think embedded gfx IP cores mostly, including codecs etc...)

> I didn't say anything about that, just that IME it should be mostly
> possible to deal with endianness within the driver stack.

To some extent yes. Completely, I'm not sure. Apps manipulating pixels,
such as video players doing hand-made overlay etc... will potentially
have issues. It's more than actual pixel byte ordering. It's anything
that accesses a quantity in memory using different size accessors, ie,
storing a u32 and then expecting to find the LSB at u8* of the same
address etc... that sort of stuff happens more often in gfx-oriented
code than anywhere else in my experience.

> Note that I'm not arguing against these changes, just pointing out some
> apparent inaccuracies in the reasoning for them.

Right, I possibly made an incorrect statement relative to Xorg (I had
assumed the fb layer only worked properly in native endian format), but
that doesn't matter much since the problem here is existing code &
drivers and goes way beyond X (probably no X on the target setups
anyways).

Cheers,
Ben

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 11:36   ` Josh Boyer
@ 2010-10-06  1:04     ` Ian Munsie
  -1 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-06  1:04 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev, linux-kernel, paulus, Benjamin Herrenschmidt

Hi Josh,

Excerpts from Josh Boyer's message of Fri Oct 01 21:36:35 +1000 2010:
> Aside from my general "uh, why?" stance, I'm very very hesitant to
> integrate anything in the kernel that doesn'.t have released patches
> on the toolchain side.

As I said the kernel can be built today with an unpatched toolchain
targetted at powerpcle-elf, the new powerpcle-linux target is mainly
required for userspace, but yes I want to get those patches out as soon
as possible.

> Also, which uClibc?  The old and crusty uClibc that uses the horrible
> linuxthreads, or the somewhat less crusty that just switched to NPTL
> (which hasn't been verified on normal PowerPC that I recall).  Why not
> use glibc...

As Ben said this was for a proof of concept and changing uClibc to
support it was quite literally a one line change.

I've been using stable packages as my base on the toolchain side of
things (gcc 4.4.4, binutils 2.20.1 and uClibc 0.9.31) so uClibc is still
using linuxthreads since they haven't released a version with NPTL yet.

> I'm not meeting to detract here, but the Kconfig should be dependent
> on && BROKEN until the above is fixed.

Good point.


Cheers,
-Ian

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-06  1:04     ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-06  1:04 UTC (permalink / raw)
  To: Josh Boyer; +Cc: paulus, linuxppc-dev, linux-kernel

Hi Josh,

Excerpts from Josh Boyer's message of Fri Oct 01 21:36:35 +1000 2010:
> Aside from my general "uh, why?" stance, I'm very very hesitant to
> integrate anything in the kernel that doesn'.t have released patches
> on the toolchain side.

As I said the kernel can be built today with an unpatched toolchain
targetted at powerpcle-elf, the new powerpcle-linux target is mainly
required for userspace, but yes I want to get those patches out as soon
as possible.

> Also, which uClibc?  The old and crusty uClibc that uses the horrible
> linuxthreads, or the somewhat less crusty that just switched to NPTL
> (which hasn't been verified on normal PowerPC that I recall).  Why not
> use glibc...

As Ben said this was for a proof of concept and changing uClibc to
support it was quite literally a one line change.

I've been using stable packages as my base on the toolchain side of
things (gcc 4.4.4, binutils 2.20.1 and uClibc 0.9.31) so uClibc is still
using linuxthreads since they haven't released a version with NPTL yet.

> I'm not meeting to detract here, but the Kconfig should be dependent
> on && BROKEN until the above is fixed.

Good point.


Cheers,
-Ian

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
  2010-10-01 11:27     ` Josh Boyer
@ 2010-10-06  1:28       ` Ian Munsie
  -1 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-06  1:28 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev, linux-kernel, paulus, Benjamin Herrenschmidt

Excerpts from Josh Boyer's message of Fri Oct 01 21:27:37 +1000 2010:
> > From: Ian Munsie <imunsie@au1.ibm.com>
> >
> > I haven't tested booting a little endian kernel on any of these targets,
> > but they all claim to be 44x so my little endian trampoline should work
> > on all of them, so wire it up on:
> >
> > bamboo
> > katmai
> > kilauea
> > rainer
> > sam440ep
> > sequoia
> > warp
> > yosemite
> > ebony
> 
> I see no reason to do this at all.  If you haven't tested them and
> there is no demand, there's no reason to wire them up.  Some might
> actively want to disallow LE mode anyway, like the Warp or Sam440EP.

I wasn't aware that the Warp and Sam440EP disallowed LE mode - I'll
definitely unwire them and move the ARCH_SUPPORTS_LITTLE_ENDIAN to just
the sub-arch's that support it.

As for the other boards, I would like to wire them up if they are able
to support LE mode - If anyone has one handy I would love to hear if
they are able to begin booting a LE kernel with these patches, or when &
how they fail.

Cheers,
-Ian

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
@ 2010-10-06  1:28       ` Ian Munsie
  0 siblings, 0 replies; 101+ messages in thread
From: Ian Munsie @ 2010-10-06  1:28 UTC (permalink / raw)
  To: Josh Boyer; +Cc: paulus, linuxppc-dev, linux-kernel

Excerpts from Josh Boyer's message of Fri Oct 01 21:27:37 +1000 2010:
> > From: Ian Munsie <imunsie@au1.ibm.com>
> >
> > I haven't tested booting a little endian kernel on any of these targets,
> > but they all claim to be 44x so my little endian trampoline should work
> > on all of them, so wire it up on:
> >
> > bamboo
> > katmai
> > kilauea
> > rainer
> > sam440ep
> > sequoia
> > warp
> > yosemite
> > ebony
> 
> I see no reason to do this at all.  If you haven't tested them and
> there is no demand, there's no reason to wire them up.  Some might
> actively want to disallow LE mode anyway, like the Warp or Sam440EP.

I wasn't aware that the Warp and Sam440EP disallowed LE mode - I'll
definitely unwire them and move the ARCH_SUPPORTS_LITTLE_ENDIAN to just
the sub-arch's that support it.

As for the other boards, I would like to wire them up if they are able
to support LE mode - If anyone has one handy I would love to hear if
they are able to begin booting a LE kernel with these patches, or when &
how they fail.

Cheers,
-Ian

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
  2010-10-06  1:28       ` Ian Munsie
@ 2010-10-06  1:55         ` Josh Boyer
  -1 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-06  1:55 UTC (permalink / raw)
  To: Ian Munsie; +Cc: linuxppc-dev, linux-kernel, paulus, Benjamin Herrenschmidt

On Tue, Oct 5, 2010 at 9:28 PM, Ian Munsie <imunsie@au1.ibm.com> wrote:
> Excerpts from Josh Boyer's message of Fri Oct 01 21:27:37 +1000 2010:
>> > From: Ian Munsie <imunsie@au1.ibm.com>
>> >
>> > I haven't tested booting a little endian kernel on any of these targets,
>> > but they all claim to be 44x so my little endian trampoline should work
>> > on all of them, so wire it up on:
>> >
>> > bamboo
>> > katmai
>> > kilauea
>> > rainer
>> > sam440ep
>> > sequoia
>> > warp
>> > yosemite
>> > ebony
>>
>> I see no reason to do this at all.  If you haven't tested them and
>> there is no demand, there's no reason to wire them up.  Some might
>> actively want to disallow LE mode anyway, like the Warp or Sam440EP.
>
> I wasn't aware that the Warp and Sam440EP disallowed LE mode - I'll
> definitely unwire them and move the ARCH_SUPPORTS_LITTLE_ENDIAN to just
> the sub-arch's that support it.

Well, Warp and Sam440EP are production boards for actual companies.
The rest are all just eval boards.  I don't know if the board
maintainers care either way, I was just using them as examples of
cases where someone might.

> As for the other boards, I would like to wire them up if they are able
> to support LE mode - If anyone has one handy I would love to hear if
> they are able to begin booting a LE kernel with these patches, or when &
> how they fail.

I'd avoid anything with an FPU until that gets tested.  So no bamboo,
sequoia, canyonlands, etc.

I noticed that canyonlands isn't even covered.  I'm guessing that's
because we don't need to create a wrapper for it because U-Boot does
direct loading of vmlinux and the DTB itself.  Has anyone done any
work with getting U-Boot to work in LE mode or at least load LE
vmlinux images?  The majority of new boards are going to be using
U-Boot and it's ability to load the DTB/FDT, so that would be
something that needs addressing.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
@ 2010-10-06  1:55         ` Josh Boyer
  0 siblings, 0 replies; 101+ messages in thread
From: Josh Boyer @ 2010-10-06  1:55 UTC (permalink / raw)
  To: Ian Munsie; +Cc: paulus, linuxppc-dev, linux-kernel

On Tue, Oct 5, 2010 at 9:28 PM, Ian Munsie <imunsie@au1.ibm.com> wrote:
> Excerpts from Josh Boyer's message of Fri Oct 01 21:27:37 +1000 2010:
>> > From: Ian Munsie <imunsie@au1.ibm.com>
>> >
>> > I haven't tested booting a little endian kernel on any of these target=
s,
>> > but they all claim to be 44x so my little endian trampoline should wor=
k
>> > on all of them, so wire it up on:
>> >
>> > bamboo
>> > katmai
>> > kilauea
>> > rainer
>> > sam440ep
>> > sequoia
>> > warp
>> > yosemite
>> > ebony
>>
>> I see no reason to do this at all. =A0If you haven't tested them and
>> there is no demand, there's no reason to wire them up. =A0Some might
>> actively want to disallow LE mode anyway, like the Warp or Sam440EP.
>
> I wasn't aware that the Warp and Sam440EP disallowed LE mode - I'll
> definitely unwire them and move the ARCH_SUPPORTS_LITTLE_ENDIAN to just
> the sub-arch's that support it.

Well, Warp and Sam440EP are production boards for actual companies.
The rest are all just eval boards.  I don't know if the board
maintainers care either way, I was just using them as examples of
cases where someone might.

> As for the other boards, I would like to wire them up if they are able
> to support LE mode - If anyone has one handy I would love to hear if
> they are able to begin booting a LE kernel with these patches, or when &
> how they fail.

I'd avoid anything with an FPU until that gets tested.  So no bamboo,
sequoia, canyonlands, etc.

I noticed that canyonlands isn't even covered.  I'm guessing that's
because we don't need to create a wrapper for it because U-Boot does
direct loading of vmlinux and the DTB itself.  Has anyone done any
work with getting U-Boot to work in LE mode or at least load LE
vmlinux images?  The majority of new boards are going to be using
U-Boot and it's ability to load the DTB/FDT, so that would be
something that needs addressing.

josh

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
  2010-10-06  1:55         ` Josh Boyer
@ 2010-10-06  2:10           ` Sean MacLennan
  -1 siblings, 0 replies; 101+ messages in thread
From: Sean MacLennan @ 2010-10-06  2:10 UTC (permalink / raw)
  To: Josh Boyer; +Cc: Ian Munsie, paulus, linuxppc-dev, linux-kernel

On Tue, 5 Oct 2010 21:55:35 -0400
Josh Boyer <jwboyer@gmail.com> wrote:

> Well, Warp and Sam440EP are production boards for actual companies.
> The rest are all just eval boards.  I don't know if the board
> maintainers care either way, I was just using them as examples of
> cases where someone might.

In the warp case, I basically don't care. I know LE would break some of
our telephony drivers since we assume PPC is BE. But on the other hand,
realistically, it will never get turned on by customers anyway.

We have to provide our own .config anyway, so it really don't hurt us
as long as it doesn't break BE support.

Cheers,
   Sean

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets
@ 2010-10-06  2:10           ` Sean MacLennan
  0 siblings, 0 replies; 101+ messages in thread
From: Sean MacLennan @ 2010-10-06  2:10 UTC (permalink / raw)
  To: Josh Boyer; +Cc: linuxppc-dev, paulus, Ian Munsie, linux-kernel

On Tue, 5 Oct 2010 21:55:35 -0400
Josh Boyer <jwboyer@gmail.com> wrote:

> Well, Warp and Sam440EP are production boards for actual companies.
> The rest are all just eval boards.  I don't know if the board
> maintainers care either way, I was just using them as examples of
> cases where someone might.

In the warp case, I basically don't care. I know LE would break some of
our telephony drivers since we assume PPC is BE. But on the other hand,
realistically, it will never get turned on by customers anyway.

We have to provide our own .config anyway, so it really don't hurt us
as long as it doesn't break BE support.

Cheers,
   Sean

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
  2010-10-01 22:03             ` Olof Johansson
@ 2010-10-07 16:25               ` Hollis Blanchard
  -1 siblings, 0 replies; 101+ messages in thread
From: Hollis Blanchard @ 2010-10-07 16:25 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Benjamin Herrenschmidt, paulus, linuxppc-dev, linux-kernel, Ian Munsie

On Fri, Oct 1, 2010 at 3:03 PM, Olof Johansson <olof@lixom.net> wrote:
> On Sat, Oct 02, 2010 at 06:51:55AM +1000, Benjamin Herrenschmidt wrote:
>> On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
>> > I'm not against it, and I agree some of the patches seem like good
>> > clean up.  I'm concerned about this bit rotting pretty quickly.
>>
>> Maybe. Most of it doesn't seem to be that bit-rottable.
>>
>> The changes to the asm stuff in misc_32.S for example are functions we
>> never ever touch once written (libgcc replacements) so I don't see them
>> rotting more with LE support than they did with BE :-)
>
> Does KVM/qemu support running LE guest on BE host? That'd help keeping
> the bitrot lower. :)

Surprisingly, qemu has very poor support for the concept of
endianness. The fact that BE PowerPC works on both BE and LE hosts in
Qemu today is more accidental than anything else (the special curse of
endianness is that two wrongs make a right). Supporting LE PowerPC
guests would be a dramatic effort, and I'm pretty sure it would impact
other qemu architectures as well.

-Hollis

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: Introduce support for little endian PowerPC
@ 2010-10-07 16:25               ` Hollis Blanchard
  0 siblings, 0 replies; 101+ messages in thread
From: Hollis Blanchard @ 2010-10-07 16:25 UTC (permalink / raw)
  To: Olof Johansson; +Cc: paulus, linuxppc-dev, Ian Munsie, linux-kernel

On Fri, Oct 1, 2010 at 3:03 PM, Olof Johansson <olof@lixom.net> wrote:
> On Sat, Oct 02, 2010 at 06:51:55AM +1000, Benjamin Herrenschmidt wrote:
>> On Fri, 2010-10-01 at 12:59 -0500, Kumar Gala wrote:
>> > I'm not against it, and I agree some of the patches seem like good
>> > clean up. =A0I'm concerned about this bit rotting pretty quickly.
>>
>> Maybe. Most of it doesn't seem to be that bit-rottable.
>>
>> The changes to the asm stuff in misc_32.S for example are functions we
>> never ever touch once written (libgcc replacements) so I don't see them
>> rotting more with LE support than they did with BE :-)
>
> Does KVM/qemu support running LE guest on BE host? That'd help keeping
> the bitrot lower. :)

Surprisingly, qemu has very poor support for the concept of
endianness. The fact that BE PowerPC works on both BE and LE hosts in
Qemu today is more accidental than anything else (the special curse of
endianness is that two wrongs make a right). Supporting LE PowerPC
guests would be a dramatic effort, and I'm pretty sure it would impact
other qemu architectures as well.

-Hollis

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
@ 2010-10-07 23:23     ` Grant Likely
  0 siblings, 0 replies; 101+ messages in thread
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
  To: Ian Munsie
  Cc: linux-kernel, linuxppc-dev, benh, paulus, Stefan Weil,
	Jiri Kosina, Sean MacLennan, Greg Kroah-Hartman, Michal Simek,
	David S. Miller, devicetree-discuss

On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
> 
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
> 
> Also fix other device tree references in the legacy serial code.
> 
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>

Applied, thanks.

I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.

As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.

g.

> ---
>  arch/powerpc/kernel/legacy_serial.c |   22 +++++++++++-----------
>  drivers/serial/of_serial.c          |   12 ++++++------
>  2 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
>  				  phys_addr_t taddr, unsigned long irq,
>  				  upf_t flags, int irq_check_parent)
>  {
> -	const u32 *clk, *spd;
> +	const __be32 *clk, *spd;
>  	u32 clock = BASE_BAUD * 16;
>  	int index;
>  
>  	/* get clock freq. if present */
>  	clk = of_get_property(np, "clock-frequency", NULL);
>  	if (clk && *clk)
> -		clock = *clk;
> +		clock = be32_to_cpup(clk);
>  
>  	/* get default speed if present */
>  	spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
>  	legacy_serial_infos[index].taddr = taddr;
>  	legacy_serial_infos[index].np = of_node_get(np);
>  	legacy_serial_infos[index].clock = clock;
> -	legacy_serial_infos[index].speed = spd ? *spd : 0;
> +	legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
>  	legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>  
>  	printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
>  static int __init add_legacy_isa_port(struct device_node *np,
>  				      struct device_node *isa_brg)
>  {
> -	const u32 *reg;
> +	const __be32 *reg;
>  	const char *typep;
>  	int index = -1;
>  	u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
>  		return -1;
>  
>  	/* Verify it's an IO port, we don't support anything else */
> -	if (!(reg[0] & 0x00000001))
> +	if (!(be32_to_cpu(reg[0]) & 0x00000001))
>  		return -1;
>  
>  	/* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
>  		taddr = 0;
>  
>  	/* Add port, irq will be dealt with later */
> -	return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> +	return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
>  			       NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>  
>  }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
>  	 * we get to their "reg" property
>  	 */
>  	if (np != pci_dev) {
> -		const u32 *reg = of_get_property(np, "reg", NULL);
> -		if (reg && (*reg < 4))
> -			index = lindex = *reg;
> +		const __be32 *reg = of_get_property(np, "reg", NULL);
> +		if (reg && (be32_to_cpup(reg) < 4))
> +			index = lindex = be32_to_cpup(reg);
>  	}
>  
>  	/* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
>  	struct device_node *prom_stdout = NULL;
>  	int i, speed = 0, offset = 0;
>  	const char *name;
> -	const u32 *spd;
> +	const __be32 *spd;
>  
>  	DBG(" -> check_legacy_serial_console()\n");
>  
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
>  	}
>  	spd = of_get_property(prom_stdout, "current-speed", NULL);
>  	if (spd)
> -		speed = *spd;
> +		speed = be32_to_cpup(spd);
>  
>  	if (strcmp(name, "serial") != 0)
>  		goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
>  {
>  	struct resource resource;
>  	struct device_node *np = ofdev->dev.of_node;
> -	const unsigned int *clk, *spd;
> -	const u32 *prop;
> +	const __be32 *clk, *spd;
> +	const __be32 *prop;
>  	int ret, prop_size;
>  
>  	memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
>  	/* Check for shifted address mapping */
>  	prop = of_get_property(np, "reg-offset", &prop_size);
>  	if (prop && (prop_size == sizeof(u32)))
> -		port->mapbase += *prop;
> +		port->mapbase += be32_to_cpup(prop);
>  
>  	/* Check for registers offset within the devices address range */
>  	prop = of_get_property(np, "reg-shift", &prop_size);
>  	if (prop && (prop_size == sizeof(u32)))
> -		port->regshift = *prop;
> +		port->regshift = be32_to_cpup(prop);
>  
>  	port->irq = irq_of_parse_and_map(np, 0);
>  	port->iotype = UPIO_MEM;
>  	port->type = type;
> -	port->uartclk = *clk;
> +	port->uartclk = be32_to_cpup(clk);
>  	port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
>  		| UPF_FIXED_PORT | UPF_FIXED_TYPE;
>  	port->dev = &ofdev->dev;
>  	/* If current-speed was set, then try not to change it. */
>  	if (spd)
> -		port->custom_divisor = *clk / (16 * (*spd));
> +		port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>  
>  	return 0;
>  }
> -- 
> 1.7.1
> 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
@ 2010-10-07 23:23     ` Grant Likely
  0 siblings, 0 replies; 101+ messages in thread
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
  To: Ian Munsie
  Cc: Greg Kroah-Hartman, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	Sean MacLennan, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stefan Weil,
	Jiri Kosina, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
	David S. Miller

On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>
> 
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
> 
> Also fix other device tree references in the legacy serial code.
> 
> Signed-off-by: Ian Munsie <imunsie-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>

Applied, thanks.

I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.

As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.

g.

> ---
>  arch/powerpc/kernel/legacy_serial.c |   22 +++++++++++-----------
>  drivers/serial/of_serial.c          |   12 ++++++------
>  2 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
>  				  phys_addr_t taddr, unsigned long irq,
>  				  upf_t flags, int irq_check_parent)
>  {
> -	const u32 *clk, *spd;
> +	const __be32 *clk, *spd;
>  	u32 clock = BASE_BAUD * 16;
>  	int index;
>  
>  	/* get clock freq. if present */
>  	clk = of_get_property(np, "clock-frequency", NULL);
>  	if (clk && *clk)
> -		clock = *clk;
> +		clock = be32_to_cpup(clk);
>  
>  	/* get default speed if present */
>  	spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
>  	legacy_serial_infos[index].taddr = taddr;
>  	legacy_serial_infos[index].np = of_node_get(np);
>  	legacy_serial_infos[index].clock = clock;
> -	legacy_serial_infos[index].speed = spd ? *spd : 0;
> +	legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
>  	legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>  
>  	printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
>  static int __init add_legacy_isa_port(struct device_node *np,
>  				      struct device_node *isa_brg)
>  {
> -	const u32 *reg;
> +	const __be32 *reg;
>  	const char *typep;
>  	int index = -1;
>  	u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
>  		return -1;
>  
>  	/* Verify it's an IO port, we don't support anything else */
> -	if (!(reg[0] & 0x00000001))
> +	if (!(be32_to_cpu(reg[0]) & 0x00000001))
>  		return -1;
>  
>  	/* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
>  		taddr = 0;
>  
>  	/* Add port, irq will be dealt with later */
> -	return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> +	return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
>  			       NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>  
>  }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
>  	 * we get to their "reg" property
>  	 */
>  	if (np != pci_dev) {
> -		const u32 *reg = of_get_property(np, "reg", NULL);
> -		if (reg && (*reg < 4))
> -			index = lindex = *reg;
> +		const __be32 *reg = of_get_property(np, "reg", NULL);
> +		if (reg && (be32_to_cpup(reg) < 4))
> +			index = lindex = be32_to_cpup(reg);
>  	}
>  
>  	/* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
>  	struct device_node *prom_stdout = NULL;
>  	int i, speed = 0, offset = 0;
>  	const char *name;
> -	const u32 *spd;
> +	const __be32 *spd;
>  
>  	DBG(" -> check_legacy_serial_console()\n");
>  
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
>  	}
>  	spd = of_get_property(prom_stdout, "current-speed", NULL);
>  	if (spd)
> -		speed = *spd;
> +		speed = be32_to_cpup(spd);
>  
>  	if (strcmp(name, "serial") != 0)
>  		goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
>  {
>  	struct resource resource;
>  	struct device_node *np = ofdev->dev.of_node;
> -	const unsigned int *clk, *spd;
> -	const u32 *prop;
> +	const __be32 *clk, *spd;
> +	const __be32 *prop;
>  	int ret, prop_size;
>  
>  	memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
>  	/* Check for shifted address mapping */
>  	prop = of_get_property(np, "reg-offset", &prop_size);
>  	if (prop && (prop_size == sizeof(u32)))
> -		port->mapbase += *prop;
> +		port->mapbase += be32_to_cpup(prop);
>  
>  	/* Check for registers offset within the devices address range */
>  	prop = of_get_property(np, "reg-shift", &prop_size);
>  	if (prop && (prop_size == sizeof(u32)))
> -		port->regshift = *prop;
> +		port->regshift = be32_to_cpup(prop);
>  
>  	port->irq = irq_of_parse_and_map(np, 0);
>  	port->iotype = UPIO_MEM;
>  	port->type = type;
> -	port->uartclk = *clk;
> +	port->uartclk = be32_to_cpup(clk);
>  	port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
>  		| UPF_FIXED_PORT | UPF_FIXED_TYPE;
>  	port->dev = &ofdev->dev;
>  	/* If current-speed was set, then try not to change it. */
>  	if (spd)
> -		port->custom_divisor = *clk / (16 * (*spd));
> +		port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>  
>  	return 0;
>  }
> -- 
> 1.7.1
> 

^ permalink raw reply	[flat|nested] 101+ messages in thread

* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
@ 2010-10-07 23:23     ` Grant Likely
  0 siblings, 0 replies; 101+ messages in thread
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
  To: Ian Munsie
  Cc: Michal Simek, Greg Kroah-Hartman, devicetree-discuss,
	Sean MacLennan, linux-kernel, Stefan Weil, paulus, Jiri Kosina,
	linuxppc-dev, David S. Miller

On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
> 
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
> 
> Also fix other device tree references in the legacy serial code.
> 
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>

Applied, thanks.

I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.

As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.

g.

> ---
>  arch/powerpc/kernel/legacy_serial.c |   22 +++++++++++-----------
>  drivers/serial/of_serial.c          |   12 ++++++------
>  2 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
>  				  phys_addr_t taddr, unsigned long irq,
>  				  upf_t flags, int irq_check_parent)
>  {
> -	const u32 *clk, *spd;
> +	const __be32 *clk, *spd;
>  	u32 clock = BASE_BAUD * 16;
>  	int index;
>  
>  	/* get clock freq. if present */
>  	clk = of_get_property(np, "clock-frequency", NULL);
>  	if (clk && *clk)
> -		clock = *clk;
> +		clock = be32_to_cpup(clk);
>  
>  	/* get default speed if present */
>  	spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
>  	legacy_serial_infos[index].taddr = taddr;
>  	legacy_serial_infos[index].np = of_node_get(np);
>  	legacy_serial_infos[index].clock = clock;
> -	legacy_serial_infos[index].speed = spd ? *spd : 0;
> +	legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
>  	legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>  
>  	printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
>  static int __init add_legacy_isa_port(struct device_node *np,
>  				      struct device_node *isa_brg)
>  {
> -	const u32 *reg;
> +	const __be32 *reg;
>  	const char *typep;
>  	int index = -1;
>  	u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
>  		return -1;
>  
>  	/* Verify it's an IO port, we don't support anything else */
> -	if (!(reg[0] & 0x00000001))
> +	if (!(be32_to_cpu(reg[0]) & 0x00000001))
>  		return -1;
>  
>  	/* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
>  		taddr = 0;
>  
>  	/* Add port, irq will be dealt with later */
> -	return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> +	return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
>  			       NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>  
>  }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
>  	 * we get to their "reg" property
>  	 */
>  	if (np != pci_dev) {
> -		const u32 *reg = of_get_property(np, "reg", NULL);
> -		if (reg && (*reg < 4))
> -			index = lindex = *reg;
> +		const __be32 *reg = of_get_property(np, "reg", NULL);
> +		if (reg && (be32_to_cpup(reg) < 4))
> +			index = lindex = be32_to_cpup(reg);
>  	}
>  
>  	/* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
>  	struct device_node *prom_stdout = NULL;
>  	int i, speed = 0, offset = 0;
>  	const char *name;
> -	const u32 *spd;
> +	const __be32 *spd;
>  
>  	DBG(" -> check_legacy_serial_console()\n");
>  
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
>  	}
>  	spd = of_get_property(prom_stdout, "current-speed", NULL);
>  	if (spd)
> -		speed = *spd;
> +		speed = be32_to_cpup(spd);
>  
>  	if (strcmp(name, "serial") != 0)
>  		goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
>  {
>  	struct resource resource;
>  	struct device_node *np = ofdev->dev.of_node;
> -	const unsigned int *clk, *spd;
> -	const u32 *prop;
> +	const __be32 *clk, *spd;
> +	const __be32 *prop;
>  	int ret, prop_size;
>  
>  	memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
>  	/* Check for shifted address mapping */
>  	prop = of_get_property(np, "reg-offset", &prop_size);
>  	if (prop && (prop_size == sizeof(u32)))
> -		port->mapbase += *prop;
> +		port->mapbase += be32_to_cpup(prop);
>  
>  	/* Check for registers offset within the devices address range */
>  	prop = of_get_property(np, "reg-shift", &prop_size);
>  	if (prop && (prop_size == sizeof(u32)))
> -		port->regshift = *prop;
> +		port->regshift = be32_to_cpup(prop);
>  
>  	port->irq = irq_of_parse_and_map(np, 0);
>  	port->iotype = UPIO_MEM;
>  	port->type = type;
> -	port->uartclk = *clk;
> +	port->uartclk = be32_to_cpup(clk);
>  	port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
>  		| UPF_FIXED_PORT | UPF_FIXED_TYPE;
>  	port->dev = &ofdev->dev;
>  	/* If current-speed was set, then try not to change it. */
>  	if (spd)
> -		port->custom_divisor = *clk / (16 * (*spd));
> +		port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>  
>  	return 0;
>  }
> -- 
> 1.7.1
> 

^ permalink raw reply	[flat|nested] 101+ messages in thread

end of thread, other threads:[~2010-10-07 23:23 UTC | newest]

Thread overview: 101+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-01  7:05 Introduce support for little endian PowerPC Ian Munsie
2010-10-01  7:05 ` [PATCH 01/18] powerpc: Add ability to build little endian kernels Ian Munsie
2010-10-01  7:05   ` Ian Munsie
2010-10-01  9:18   ` Kumar Gala
2010-10-01  9:18     ` Kumar Gala
2010-10-01 11:28     ` Josh Boyer
2010-10-01 11:28       ` Josh Boyer
2010-10-01 12:09       ` Benjamin Herrenschmidt
2010-10-01 12:09         ` Benjamin Herrenschmidt
2010-10-01 11:40   ` Josh Boyer
2010-10-01 11:40     ` Josh Boyer
2010-10-01 12:22     ` Benjamin Herrenschmidt
2010-10-01 12:22       ` Benjamin Herrenschmidt
2010-10-01  7:05 ` [PATCH 02/18] powerpc: Add CROSSBE_COMPILE to build big endian boot wrapper Ian Munsie
2010-10-01  7:05   ` Ian Munsie
2010-10-01  7:13   ` Geert Uytterhoeven
2010-10-01  7:13     ` Geert Uytterhoeven
2010-10-01  7:19     ` Ian Munsie
2010-10-01  7:19       ` Ian Munsie
2010-10-01  7:05 ` [PATCH 03/18] powerpc: Support parsing a little endian kernel from zImage wrapper Ian Munsie
2010-10-01  7:05 ` [PATCH 04/18] powerpc: Allow taishan platform to boot a little endian kernel Ian Munsie
2010-10-01  7:05   ` Ian Munsie
2010-10-01  7:05 ` [PATCH 05/18] powerpc: Wire up 44x little endian boot for remaining 44x targets Ian Munsie
2010-10-01 11:27   ` Josh Boyer
2010-10-01 11:27     ` Josh Boyer
2010-10-06  1:28     ` Ian Munsie
2010-10-06  1:28       ` Ian Munsie
2010-10-06  1:55       ` Josh Boyer
2010-10-06  1:55         ` Josh Boyer
2010-10-06  2:10         ` Sean MacLennan
2010-10-06  2:10           ` Sean MacLennan
2010-10-01  7:05 ` [PATCH 06/18] powerpc 44x: Set E bit in TLBs and PTEs when CPU is in little endian mode Ian Munsie
2010-10-01  7:05   ` Ian Munsie
2010-10-01  7:06 ` [PATCH 07/18] powerpc: Use generic bitops for little endian bitmap operations Ian Munsie
2010-10-01  7:06 ` [PATCH 08/18] powerpc: Include the appropriate endianness header Ian Munsie
2010-10-01  7:06 ` [PATCH 09/18] powerpc: Support device tree regardless of CPU endianness Ian Munsie
2010-10-01  7:06   ` Ian Munsie
2010-10-03  3:15   ` Grant Likely
2010-10-03  3:15     ` Grant Likely
2010-10-03  6:22     ` Benjamin Herrenschmidt
2010-10-03  6:22       ` Benjamin Herrenschmidt
2010-10-01  7:06 ` [PATCH 10/18] powerpc: Support endian agnostic MMIO Ian Munsie
2010-10-01  7:06 ` [PATCH 11/18] powerpc: Make assembly endian agnostic when accessing 64bit values Ian Munsie
2010-10-01  7:06   ` Ian Munsie
2010-10-01  7:06 ` [PATCH 12/18] powerpc 44x: Handle TLB miss regardless of endianness Ian Munsie
2010-10-01  7:06   ` Ian Munsie
2010-10-01  7:06 ` [PATCH 13/18] powerpc 44x: Make DCR endianness agnostic Ian Munsie
2010-10-01  7:06   ` Ian Munsie
2010-10-01  7:06 ` [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports Ian Munsie
2010-10-01  7:06   ` Ian Munsie
2010-10-07 23:23   ` Grant Likely
2010-10-07 23:23     ` Grant Likely
2010-10-07 23:23     ` Grant Likely
2010-10-01  7:06 ` [PATCH 15/18] mtd: Fix endianness issues from device tree Ian Munsie
2010-10-01  7:06   ` Ian Munsie
2010-10-01  7:06   ` Ian Munsie
2010-10-01 19:29   ` Artem Bityutskiy
2010-10-01 19:29     ` Artem Bityutskiy
2010-10-01 19:29     ` Artem Bityutskiy
2010-10-01  7:06 ` [PATCH 16/18] powerpc: Fix endianness issues in alignment handler Ian Munsie
2010-10-01  7:06   ` Ian Munsie
2010-10-01  7:06 ` [PATCH 17/18] net: Fix endianess issues in IBM newemac driver Ian Munsie
2010-10-01  7:06   ` Ian Munsie
2010-10-01  7:06 ` [PATCH 18/18] powerpc: Fix jiffies variable on little endian Ian Munsie
2010-10-01  7:06   ` Ian Munsie
2010-10-01  9:02 ` Introduce support for little endian PowerPC Kumar Gala
2010-10-01  9:02   ` Kumar Gala
2010-10-01 11:30   ` Josh Boyer
2010-10-01 11:30     ` Josh Boyer
2010-10-01 11:55     ` Gary Thomas
2010-10-01 11:55       ` Gary Thomas
2010-10-01 12:15       ` Benjamin Herrenschmidt
2010-10-01 12:15         ` Benjamin Herrenschmidt
2010-10-01 12:37         ` Gary Thomas
2010-10-01 12:37           ` Gary Thomas
2010-10-01 12:14     ` Benjamin Herrenschmidt
2010-10-01 12:14       ` Benjamin Herrenschmidt
2010-10-01 16:20       ` Michel Dänzer
2010-10-01 16:20         ` Michel Dänzer
2010-10-01 20:50         ` Benjamin Herrenschmidt
2010-10-01 20:50           ` Benjamin Herrenschmidt
2010-10-04 10:30           ` Michel Dänzer
2010-10-04 10:30             ` Michel Dänzer
2010-10-04 22:50             ` Benjamin Herrenschmidt
2010-10-04 22:50               ` Benjamin Herrenschmidt
2010-10-01 17:59       ` Kumar Gala
2010-10-01 17:59         ` Kumar Gala
2010-10-01 20:51         ` Benjamin Herrenschmidt
2010-10-01 20:51           ` Benjamin Herrenschmidt
2010-10-01 22:03           ` Olof Johansson
2010-10-01 22:03             ` Olof Johansson
2010-10-01 22:28             ` Benjamin Herrenschmidt
2010-10-01 22:28               ` Benjamin Herrenschmidt
2010-10-07 16:25             ` Hollis Blanchard
2010-10-07 16:25               ` Hollis Blanchard
2010-10-01 11:36 ` Josh Boyer
2010-10-01 11:36   ` Josh Boyer
2010-10-01 12:21   ` Benjamin Herrenschmidt
2010-10-01 12:21     ` Benjamin Herrenschmidt
2010-10-06  1:04   ` Ian Munsie
2010-10-06  1:04     ` Ian Munsie

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.