| Message ID | 1426865807-22981-1-git-send-email-digetx@gmail.com |
|---|---|
| State | Deferred |
| Headers | show |
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.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 --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;
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(-)