Thread (117 messages) 117 messages, 18 authors, 2014-09-16

[PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support

From: Jon Masters <hidden>
Date: 2014-09-09 06:36:31
Also in: linux-acpi, lkml

On 09/03/2014 02:42 PM, Arnd Bergmann wrote:
On Monday 01 September 2014 22:57:51 Hanjun Guo wrote:
quoted
+       /* Collect CPU base addresses */
+       count = acpi_parse_entries(sizeof(struct acpi_table_madt),
+                                  gic_acpi_parse_madt_cpu, table,
+                                  ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+                                  ACPI_MAX_GIC_CPU_INTERFACE_ENTRIES);
+       if (count < 0) {
+               pr_err("Error during GICC entries parsing\n");
+               return -EFAULT;
+       } else if (!count) {
+               /* No GICC entries provided, use address from MADT header */
+               struct acpi_table_madt *madt = (struct acpi_table_madt *)table;
+
+               if (!madt->address)
+                       return -EFAULT;
+
+               cpu_phy_base = (u64)madt->address;
+       }
After I read through ACPI-5.1 section 5.2.12.14, I wonder if this is the
best way to treat a missing ACPI_MADT_TYPE_GENERIC_INTERRUPT table.

Do we expect to see those in practice? It seems like using the x86 local
APIC address as a fallback for the GIC address is not something we
should do unless we absolutely have to support a system that doesn't
have the GIC table.
All GICv2 based ACPI systems should define GICCs for the CPU interfaces.

Jon.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help