[PATCH] [RFC] ARM: keystone: possibly fix big-endian kernels

[PATCH] [RFC] ARM: keystone: possibly fix big-endian kernels

[Arnd Bergmann]

While discussing a regressing in the netcp driver, I wondered
whether Keystone can work with a big-endian kernel, and noticed
that we don't switch endianess when we enter the kernel on the
secondary CPU, or when we call into smc.

I don't know whether this works on the machine, but on others
it does not, so this adds the explicit switch to big-endian
in keystone_secondary_startup.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/mach-keystone/keystone.h | 2 +-
 arch/arm/mach-keystone/platsmp.c  | 2 +-
 arch/arm/mach-keystone/smc.S      | 8 ++++++++
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/keystone.h b/arch/arm/mach-keystone/keystone.h
index 33eaa037af5a..016ae7644e73 100644
--- a/arch/arm/mach-keystone/keystone.h
+++ b/arch/arm/mach-keystone/keystone.h
@@ -16,7 +16,7 @@
 #ifndef __ASSEMBLER__
 
 extern const struct smp_operations keystone_smp_ops;
-extern void secondary_startup(void);
+extern void keystone_secondary_startup(void);
 extern u32 keystone_cpu_smc(u32 command, u32 cpu, u32 addr);
 extern int keystone_pm_runtime_init(void);
 
diff --git a/arch/arm/mach-keystone/platsmp.c b/arch/arm/mach-keystone/platsmp.c
index 5665276972ec..c427787f78d1 100644
--- a/arch/arm/mach-keystone/platsmp.c
+++ b/arch/arm/mach-keystone/platsmp.c
@@ -26,7 +26,7 @@
 static int keystone_smp_boot_secondary(unsigned int cpu,
 						struct task_struct *idle)
 {
-	unsigned long start = virt_to_idmap(&secondary_startup);
+	unsigned long start = virt_to_idmap(&keystone_secondary_startup);
 	int error;
 
 	pr_debug("keystone-smp: booting cpu %d, vector %08lx\n",
diff --git a/arch/arm/mach-keystone/smc.S b/arch/arm/mach-keystone/smc.S
index d15de8179fab..81604c0d4e1b 100644
--- a/arch/arm/mach-keystone/smc.S
+++ b/arch/arm/mach-keystone/smc.S
@@ -10,6 +10,7 @@
  */
 
 #include <linux/linkage.h>
+#include <asm/assembler.h>
 
 /**
  * u32 keystone_cpu_smc(u32 command, u32 cpu, u32 addr)
@@ -26,3 +27,10 @@ ENTRY(keystone_cpu_smc)
 	smc	#0
 	ldmfd   sp!, {r4-r11, pc}
 ENDPROC(keystone_cpu_smc)
+
+#ifdef CONFIG_SMP
+ENTRY(keystone_secondary_startup)
+ARM_BE8(setend	be)			@ go BE8 if entered LE
+	b	secondary_startup
+ENDPROC(keystone_secondary_startup)
+#endif
-- 
2.7.0

[PATCH] [RFC] ARM: keystone: possibly fix big-endian kernels

[Russell King - ARM Linux]

On Tue, Feb 23, 2016 at 03:43:21PM +0100, Arnd Bergmann wrote:
> While discussing a regressing in the netcp driver, I wondered
> whether Keystone can work with a big-endian kernel, and noticed
> that we don't switch endianess when we enter the kernel on the
> secondary CPU, or when we call into smc.

NAK.  Sorry Arnd, you're worringly wrong on this.

secondary_startup will do the setend if necessary, there's no need
to do this kind of junk in each and every platform.  It's been this
way since:

commit 97bcb0fea590d3d704f985bec08f342d28992634
Author: Ben Dooks <ben.dooks@codethink.co.uk>
Date:   Fri Feb 1 09:40:42 2013 +0000

So, I hope you've not been telling platform folk to do this.  Please
audit the arm-soc code to make sure, thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] [RFC] ARM: keystone: possibly fix big-endian kernels

[Arnd Bergmann]

On Tuesday 23 February 2016 14:53:18 Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 03:43:21PM +0100, Arnd Bergmann wrote:
> > While discussing a regressing in the netcp driver, I wondered
> > whether Keystone can work with a big-endian kernel, and noticed
> > that we don't switch endianess when we enter the kernel on the
> > secondary CPU, or when we call into smc.
> 
> NAK.  Sorry Arnd, you're worringly wrong on this.
> 
> secondary_startup will do the setend if necessary, there's no need
> to do this kind of junk in each and every platform.  It's been this
> way since:
> 
> commit 97bcb0fea590d3d704f985bec08f342d28992634
> Author: Ben Dooks <ben.dooks@codethink.co.uk>
> Date:   Fri Feb 1 09:40:42 2013 +0000
> 
> So, I hope you've not been telling platform folk to do this.  Please
> audit the arm-soc code to make sure, thanks.
> 

I see my mistake now: I looked at the secondary_startup() function
by looking up the location in ctags, and that pointed me to
arch/arm/kernel/head-nommu.S.

I was surprised when I didn't see the setend() in there, but
didn't realize that I was looking in the wrong place, but it
made some sense when I found the setend in a couple of other
platforms that all need a wrapper anyway.

Sorry about the noise.

	Arnd