Messages in this thread | | | Subject | Re: [RFC PATCH] irqchip/gic-v3-its: apply ACPI device based quirks | From | Marc Zyngier <> | Date | Mon, 26 Feb 2018 11:37:57 +0000 |
| |
On 26/02/18 11:09, Ard Biesheuvel wrote: > On 26 February 2018 at 10:18, Marc Zyngier <marc.zyngier@arm.com> wrote: >> Hi Ard, >> >> On 13/02/18 14:11, Ard Biesheuvel wrote: >>> Reapply the SynQuacer quirk for ITS frames that are matched by 'SCX0005' >>> based ACPI devices, replacing the dummy fwnode with the one populated by >>> the ACPI device core. >>> >>> This allows the SynQuacer ACPI tables to publish a device node such >>> as >>> >>> Device (ITS0) { >>> Name (_HID, "SCX0005") >>> Name (_ADR, 0x30020000) >>> Name (_DSD, Package () // _DSD: Device-Specific Data >>> { >>> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), >>> Package () { >>> Package (2) { >>> "socionext,synquacer-pre-its", >>> Package () { 0x58000000, 0x200000 } >>> }, >>> } >>> }) >>> } >>> >>> which will trigger the existing quirk that replaces the doorbell >>> address with the appropriate address in the pre-ITS frame. >>> >>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >>> --- >>> Marc, Lorenzo, >>> >>> I am aware that this patch may be seen as controversial, but I would like to >>> propose it nonetheless. The reason is that this is the only thing standing in >>> the way of full ACPI support in Socionext SynQuacer based platforms. >>> >>> The pre-ITS is a monstrosity, but as it turns out, Socionext had help from >>> ARM designing it, and the reason we need DT/ACPI based quirks in the first >>> place is that the IIDR of this GICv3 implementation is simply the ARM Ltd. >>> one (as they designed the IP) >> >> That's odd. A bit of archaeology shows that ARM indeed designed a >> pre-ITS, but that one doesn't break isolation at all (it still has a >> single doorbell). So whatever creative changes Socionext applied to that >> piece of IP (assuming this is the same IP), they didn't really >> understand the far reaching impact it has. >> > > OK, thanks for digging that up. All the information I have on this > topic is second hand, and I had no reason to assume their account of > the history was inaccurate.
No worries. There is a short description of the PITS in the integration guide, but I don't think that's available to the mere mortal, unfortunately.
> >>> >>> Please take this into consideration when reviewing this patch, >>> >>> Thanks, >>> Ard. >>> >>> drivers/irqchip/irq-gic-v3-its.c | 39 ++++++++++++++++++++ >>> 1 file changed, 39 insertions(+) >>> >>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c >>> index 06f025fd5726..a63973baf08a 100644 >>> --- a/drivers/irqchip/irq-gic-v3-its.c >>> +++ b/drivers/irqchip/irq-gic-v3-its.c >>> @@ -3517,3 +3517,42 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists, >>> >>> return 0; >>> } >>> + >>> +#if defined(CONFIG_SOCIONEXT_SYNQUACER_PREITS) && defined(CONFIG_ACPI) >>> +static acpi_status __init acpi_its_device_probe (acpi_handle handle, >>> + u32 depth, void *context, >>> + void **ret) >>> +{ >>> + struct acpi_device *adev; >>> + unsigned long long phys_base; >>> + struct its_node *its; >>> + acpi_status status; >>> + int err; >>> + >>> + err = acpi_bus_get_device(handle, &adev); >>> + if (err) >>> + return AE_CTRL_TERMINATE; >>> + >>> + status = acpi_evaluate_integer(handle, "_ADR", NULL, &phys_base); >>> + if (ACPI_FAILURE(status)) >>> + return status; >>> + >>> + list_for_each_entry(its, &its_nodes, entry) >>> + if (its->phys_base == phys_base) { >>> + irq_domain_free_fwnode(its->fwnode_handle); >> >> That line scares me. What about irq domains that are hold a pointer to >> this handle? its_init_domain() uses it to construct the LPI domain, and >> it is now pointing to some free memory. >> >> You'd need to reassign all the domains that match this fwnode before >> freeing it. >> > > OK, I can iterate over the domains using irq_find_matching_fwspec() > and update the handles one by one. Not pretty, but that is a lost > cause anyway for this patch.
Yeah, that should do the trick.
> >>> + its->fwnode_handle = &adev->fwnode; >>> + its_enable_quirk_socionext_synquacer(its); >>> + break; >>> + } >>> + >>> + return AE_CTRL_TERMINATE; >>> +} >>> + >>> +static int __init acpi_its_device_probe_init(void) >>> +{ >>> + if (!acpi_disabled) >>> + acpi_get_devices("SCX0005", acpi_its_device_probe, NULL, NULL); >>> + return 0; >>> +} >>> +subsys_initcall_sync(acpi_its_device_probe_init); >>> +#endif >>> >> >> Is there any chance that MSIs could be allocated before this kicks in? >> If that happens, we're in trouble... > > This SoC does not have any MSI capable platform devices, so the only > consumers are PCI devices, and PCI drivers are registered as a > device_initcal().
Ideally, we'd only do the reasignment if domain->mapcount is zero.
Thanks,
M. -- Jazz is not dead. It just smells funny...
| |