On 2015年02月04日 04:09, Catalin Marinas wrote:
On Tue, Feb 03, 2015 at 02:17:49PM +0000, Mark Rutland wrote:
On Mon, Feb 02, 2015 at 12:45:42PM +0000, Hanjun Guo wrote:
Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
from the GICC Structure introduced by ACPI 5.1.
MPIDR is the CPU hardware ID as local APIC ID on x86 platform, so we use
MPIDR not the GIC CPU interface ID to identify CPUs.
Further steps would typedef a phys_id_t for in arch code(with
appropriate size and a corresponding invalid value, say ~0) and use that
instead of an int in drivers/acpi/processor_core.c to store phys_id, then
no need for mpidr packing.
I don't understand why we don't fix this now, and I'm very worried that
this patch leaves much potential for FW bugs due to potential Linux
bugs.
Having a function called cpu_physical_id which _does not_ return a
physical ID makes no sense to me. Any time we really need a physical
ID, we're still going to have to unpack it (in an architecture-specific
manner).
Do you mean something like this? Only briefly tested on Juno and I may
have missed other calls:
Thanks, I think it is Mark's suggestion (and also Lorenzo's)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index ea4d2b35c57b..4fafd62b1b86 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -49,33 +49,12 @@ static inline void enable_acpi(void)
acpi_noirq = 0;
}
-/* MPIDR value provided in GICC structure is 64 bits, but the
- * existing phys_id (CPU hardware ID) using in acpi processor
- * driver is 32-bit, to conform to the same datatype we need
- * to repack the GICC structure MPIDR.
- *
- * bits other than following 32 bits are defined as 0, so it
- * will be no information lost after repacked.
- *
- * Bits [0:7] Aff0;
- * Bits [8:15] Aff1;
- * Bits [16:23] Aff2;
- * Bits [32:39] Aff3;
- */
-static inline u32 pack_mpidr(u64 mpidr)
-{
- return (u32) ((mpidr & 0xff00000000) >> 8) | mpidr;
-}
-
/*
* The ACPI processor driver for ACPI core code needs this macro
* to find out this cpu was already mapped (mapping from CPU hardware
* ID to CPU logical ID) or not.
- *
- * cpu_logical_map(cpu) is the mapping of MPIDR and the logical cpu,
- * and MPIDR is the cpu hardware ID we needed to pack.
*/
-#define cpu_physical_id(cpu) pack_mpidr(cpu_logical_map(cpu))
+#define cpu_physical_id(cpu) cpu_logical_map(cpu)
/*
* It's used from ACPI core in kdump to boot UP system with SMP kernel,
diff --git a/arch/arm64/include/asm/smp_plat.h b/arch/arm64/include/asm/smp_plat.h
index 59e282311b58..a492276e008d 100644
--- a/arch/arm64/include/asm/smp_plat.h
+++ b/arch/arm64/include/asm/smp_plat.h
@@ -40,4 +40,6 @@ static inline u32 mpidr_hash_size(void)
extern u64 __cpu_logical_map[NR_CPUS];
#define cpu_logical_map(cpu) __cpu_logical_map[cpu]
+typedef u64 cpuid_t;
I think cpuid_t is a little confused because people may recognize
it as cpu logical id, its original meaning is the physical cpu ID,
so how about:
typedef u64 phys_id_t; ?
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
