On 8/11/23 15:42, Will Deacon wrote:
On Fri, Aug 11, 2023 at 02:13:42PM +0530, Anshuman Khandual wrote:
On 8/8/23 13:52, Anshuman Khandual wrote:
- /*
* Sanity check all the GICC tables for the same interrupt* number. For now, only support homogeneous ACPI machines.*/- for_each_possible_cpu(cpu) {
struct acpi_madt_generic_interrupt *gicc;gicc = acpi_cpu_get_madt_gicc(cpu);if (gicc->header.length < len)return gsi ? -ENXIO : 0;this_gsi = parse_gsi(gicc);if (!this_gsi)return gsi ? -ENXIO : 0;this_hetid = find_acpi_cpu_topology_hetero_id(cpu);if (!gsi) {hetid = this_hetid;gsi = this_gsi;} else if (hetid != this_hetid || gsi != this_gsi) {pr_warn("ACPI: %s: must be homogeneous\n", pdev->name);return -ENXIO;}- }
As discussed on the previous version i.e V3 thread, will move the 'this_gsi' check after parse_gsi(), inside if (!gsi) conditional block. This will treat subsequent cpu parse_gsi()'s failure as a mismatch thus triggering the pr_warn() message.
diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c index 845683ca7c64..6eae772d6298 100644 --- a/drivers/perf/arm_pmu_acpi.c +++ b/drivers/perf/arm_pmu_acpi.c @@ -98,11 +98,11 @@ arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len, return gsi ? -ENXIO : 0; this_gsi = parse_gsi(gicc);
if (!this_gsi)return gsi ? -ENXIO : 0;this_hetid = find_acpi_cpu_topology_hetero_id(cpu); if (!gsi) {
if (!this_gsi)return 0;Why do you need this hunk?
Otherwise '0' gsi on all cpus would just clear the above homogeneity test, and end up in acpi_register_gsi() making it fail, but with the following warning before returning with -ENXIO.
irq = acpi_register_gsi(NULL, gsi, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_HIGH); if (irq < 0) { pr_warn("ACPI: %s Unable to register interrupt: %d\n", pdev->name, gsi); return -ENXIO; }
Is this behaviour better than returning 0 after detecting '0' gsi in the first cpu to avoid the above mentioned scenario ? Although 0 gsi followed by non-zero ones will still end up warning about a mismatch.
-
Anshuman Khandual