Re: [PATCH v7 11/17] ACPI / processor: Make it possible to get CPU hardware ID via GICC

From: Hanjun Guo
Date: Tue Jan 20 2015 - 07:26:58 EST


On 2015å01æ20æ 19:17, Catalin Marinas wrote:
On Wed, Jan 14, 2015 at 03:04:59PM +0000, Hanjun Guo wrote:
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -64,6 +64,38 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
return 0;
}

+/*
+ * On ARM platform, MPIDR value is the hardware ID as apic ID
+ * on Intel platforms
+ */
+static int map_gicc_mpidr(struct acpi_subtable_header *entry,
+ int device_declaration, u32 acpi_id, int *mpidr)
+{
+ struct acpi_madt_generic_interrupt *gicc =
+ container_of(entry, struct acpi_madt_generic_interrupt, header);
+
+ if (!(gicc->flags & ACPI_MADT_ENABLED))
+ return -ENODEV;
+
+ /* In the GIC interrupt model, logical processors are
+ * required to have a Processor Device object in the DSDT,
+ * so we should check device_declaration here
+ */
+ if (device_declaration && (gicc->uid == acpi_id)) {
+ /*
+ * Only bits [0:7] Aff0, bits [8:15] Aff1, bits [16:23] Aff2
+ * and bits [32:39] Aff3 are meaningful, so pack the Affx
+ * fields into a single 32 bit identifier to accommodate the
+ * acpi processor drivers.
+ */
+ *mpidr = ((gicc->arm_mpidr & 0xff00000000) >> 8)
+ | gicc->arm_mpidr;

Nitpick: I would clarify the comment here since "meaningful" doesn't
necessarily mean that the other bits are 0. And if they are not, the
above masking is not enough. Looking at the ACPI 5.1 spec, bits other
than Aff[0-3] must be zero.

Same for the pack_mpidr() comment.

OK, how about:

/*
* bits other than [0:7] Aff0, [8:15] Aff1, [16:23] Aff2 and
* [32:39] Aff3 must be 0 which is defined in ACPI 5.1, so pack
* the Affx fields into a single 32 bit identifier to accommodate
* the acpi processor drivers.
*/

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/