diff mbox

ARM: trusted_foundations: Maintain CPU endianness

Message ID 1426865807-22981-1-git-send-email-digetx@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Dmitry Osipenko March 20, 2015, 3:36 p.m. UTC
Convert CPU reset vector address to LE to support big-endian kernel.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
 arch/arm/firmware/trusted_foundations.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Dmitry Osipenko March 20, 2015, 3:47 p.m. UTC | #1
This patch not tested. I assume that firmware save/restore cp15 context, i.e. it 
doesn't require switching to LE before smc call and restore endianness after.
Stephen Warren March 20, 2015, 4:07 p.m. UTC | #2
On 03/20/2015 09:36 AM, Dmitry Osipenko wrote:
> Convert CPU reset vector address to LE to support big-endian kernel.

Naively this sounds a little odd; the value here is in a CPU register 
all the time, not in memory, so I'm not sure why endianness is relevant? 
Presumably the CPU doesn't end up byte-swapping values in registers when 
running in BE mode or it takes an SMC? If it does, why don't we need 
cpu_to_le32(TF_SET_CPU_BOOT_ADDR_SMC) too?

Sorry if this is a silly question; I haven't followed any of the BE 
kernel patches.
Dave Martin March 20, 2015, 4:20 p.m. UTC | #3
On Fri, Mar 20, 2015 at 06:47:18PM +0300, Dmitry Osipenko wrote:
> This patch not tested. I assume that firmware save/restore cp15
> context, i.e. it doesn't require switching to LE before smc call and
> restore endianness after.

That assumption should be valid.

However, I think this patch must be tested before assuming it is
correct.  If the arguments were passed in memory then there might
force LE order for that data block, but there should not be a need for
this if the values are in registers.

Cheers
---Dave
Dmitry Osipenko March 20, 2015, 4:41 p.m. UTC | #4
20.03.2015 19:07, Stephen Warren ?????:
> On 03/20/2015 09:36 AM, Dmitry Osipenko wrote:
>> Convert CPU reset vector address to LE to support big-endian kernel.
>
> Naively this sounds a little odd; the value here is in a CPU register all the
> time, not in memory, so I'm not sure why endianness is relevant? Presumably the
> CPU doesn't end up byte-swapping values in registers when running in BE mode or
> it takes an SMC? If it does, why don't we need
> cpu_to_le32(TF_SET_CPU_BOOT_ADDR_SMC) too?
>
> Sorry if this is a silly question; I haven't followed any of the BE kernel patches.

You absolutely right. I goofed it by replacing 'smc' with 'str' without adding 
reg reverse for BE when was testing and then blindly made patch. Please ignore 
it and sorry for the noise.
diff mbox

Patch

diff --git a/arch/arm/firmware/trusted_foundations.c b/arch/arm/firmware/trusted_foundations.c
index 3fb1b5a..865103a 100644
--- a/arch/arm/firmware/trusted_foundations.c
+++ b/arch/arm/firmware/trusted_foundations.c
@@ -50,7 +50,7 @@  static void __naked tf_generic_smc(u32 type, u32 arg1, u32 arg2)
 
 static int tf_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
 {
-	cpu_boot_addr = boot_addr;
+	cpu_boot_addr = cpu_to_le32(boot_addr);
 	tf_generic_smc(TF_SET_CPU_BOOT_ADDR_SMC, cpu_boot_addr, 0);
 
 	return 0;