| Message ID | 20190422164937.21350-11-julien.grall@arm.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | xen/arm: Clean-up & fixes in boot/mm code | expand |
Hello Julien, On 22.04.19 19:49, Julien Grall wrote: > There are no reason to consider the HW CPU ID will be 0 when the > processor is part of a uniprocessor system. At best, this will result to > conflicting output as the rest of Xen use the value directly read from > MPIDR. > > So remove the zeroing and logic to check if the CPU is part of a > uniprocessor system. > > Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Andrii Anisov <andrii_anisov@epam.com>
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S index 9f40face98..d42a13556c 100644 --- a/xen/arch/arm/arm32/head.S +++ b/xen/arch/arm/arm32/head.S @@ -124,16 +124,8 @@ GLOBAL(init_secondary) mov r12, #1 /* r12 := is_secondary_cpu */ common_start: - mov r7, #0 /* r7 := CPU ID. Initialy zero until we - * find that multiprocessor extensions are - * present and the system is SMP */ mrc CP32(r1, MPIDR) - tst r1, #MPIDR_SMP /* Multiprocessor extension supported? */ - beq 1f - tst r1, #MPIDR_UP /* Uniprocessor system? */ - bne 1f bic r7, r1, #(~MPIDR_HWID_MASK) /* Mask out flags to get CPU ID */ -1: /* Non-boot CPUs wait here until __cpu_up is ready for them */ teq r12, #0
There are no reason to consider the HW CPU ID will be 0 when the processor is part of a uniprocessor system. At best, this will result to conflicting output as the rest of Xen use the value directly read from MPIDR. So remove the zeroing and logic to check if the CPU is part of a uniprocessor system. Signed-off-by: Julien Grall <julien.grall@arm.com> --- xen/arch/arm/arm32/head.S | 8 -------- 1 file changed, 8 deletions(-)