Re: [PATCH 2/2] irqchip/gic-v3: Enable non-coherent redistributors/ITSes probing

From: Robin Murphy
Date: Tue Oct 03 2023 - 12:19:09 EST


On 03/10/2023 3:43 pm, Lorenzo Pieralisi wrote:
On Tue, Sep 05, 2023 at 12:34:58PM +0100, Marc Zyngier wrote:

[...]

* Make sure *all* the ITS are reset before we probe any, as
* they may be sharing memory. If any of the ITS fails to
@@ -5396,7 +5405,8 @@ static int __init its_of_probe(struct device_node *node)
continue;
}
- its_probe_one(&res, &np->fwnode, of_node_to_nid(np));
+ its_probe_one(&res, &np->fwnode, of_node_to_nid(np),
+ of_property_read_bool(np, "dma-noncoherent"));
}
return 0;
}
@@ -5533,7 +5543,8 @@ static int __init gic_acpi_parse_madt_its(union acpi_subtable_headers *header,
}
err = its_probe_one(&res, dom_handle,
- acpi_get_its_numa_node(its_entry->translation_id));
+ acpi_get_its_numa_node(its_entry->translation_id),
+ false);

I came up with the following alternative approach, which is as usual
completely untested. It is entirely based on the quirk infrastructure,
and doesn't touch the ACPI path at all.

Writing the ACPI bits. We can't use the quirks framework for ACPI (we
don't have "properties" and I don't think we want to attach any to the
fwnode_handle) that's why I generalized its_probe_one() above with an
extra param, that would have simplified ACPI parsing:

- we alloc struct its_node in its_probe_one() but at that stage
ACPI parsing was already done. If we have to parse the MADT(ITS) again
just to scan for non-coherent we then have to match the MADT entries
to the *current* struct its_node* we are handling (MADT parsing
callbacks don't even take a param - we have to resort to global
variables - definitely doable but it is a bit ugly).

How about a compromise of passing a whole MADT flags field into its_probe_one() (where its_of_probe() can just pass 0), to pass through to its_enable_quirks() to then match against an madt_flags field in the gic_quirk? gic_acpi_init() could then do something similar for the redistributor quirk, although I guess it would then need to distinguish GICC and GICR-based quirks cases since the respective flags are in different formats.

Thanks,
Robin.