On 5/15/2024 6:47 AM, Michael Kelley wrote:
From: Roman Kisel <romank@xxxxxxxxxxxxxxxxxxx> Sent: Tuesday, May 14, 2024 3:44 PM
The hyperv-pci driver uses ACPI for MSI IRQ domain configuration
on arm64 thereby it won't be able to do that in the VTL mode where
only DeviceTree can be used.
That sentence seems a bit weird. How about:
The hyperv-pci driver uses ACPI for MSI IRQ domain configuration on arm64.
It won't be able to do that in the VTL mode where only DeviceTree can be used.
Agreed, appreciate your wordsmithing :)
Update the hyperv-pci driver to discover interrupt configuration
via DeviceTree.
"discover interrupt configuration"? I think that's a cut-and-paste error
from the previous patch.
Guilty as charged :) Will fix.
Signed-off-by: Roman Kisel <romank@xxxxxxxxxxxxxxxxxxx>
---
drivers/pci/controller/pci-hyperv.c | 13 ++++++++++---
include/linux/acpi.h | 9 +++++++++
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index 1eaffff40b8d..ccc2b54206f4 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -906,9 +906,16 @@ static int hv_pci_irqchip_init(void)
* way to ensure that all the corresponding devices are also gone and
* no interrupts will be generated.
*/
- hv_msi_gic_irq_domain = acpi_irq_create_hierarchy(0, HV_PCI_MSI_SPI_NR,
- fn, &hv_pci_domain_ops,
- chip_data);
+ if (acpi_disabled)
+ hv_msi_gic_irq_domain = irq_domain_create_hierarchy(
+ irq_find_matching_fwnode(fn, DOMAIN_BUS_ANY),
+ 0, HV_PCI_MSI_SPI_NR,
+ fn, &hv_pci_domain_ops,
+ chip_data);
Does the above really work? It seems doubtful to me that irq_find_matching_fwnode()
always finds the parent domain that you want. But I don't have a deep understanding
of how this works or is supposed to work, so I don't know for sure.
If the above *does* actually work for all cases, then should it also work for the ACPI
case? Then you could avoid the messiness when acpi_irq_create_hierarchy() doesn't
exist.
Have not got a system to validate this on. Conceptually (at my level of
ignorance) didn't look very off... Will use the "collapsed" version
you're suggesting as the litmus test.
+ else
+ hv_msi_gic_irq_domain = acpi_irq_create_hierarchy(0, HV_PCI_MSI_SPI_NR,
+ fn, &hv_pci_domain_ops,
+ chip_data);
if (!hv_msi_gic_irq_domain) {
pr_err("Failed to create Hyper-V arm64 vPCI MSI IRQ domain\n");
I'm wondering if these are the only changes needed to make vPCI work on
arm64 with DeviceTree. The DMA coherence issue I mentioned in the previous patch
definitely affects vPCI devices, so it needs to be fully understood and verified to work
correctly.
Likely not all as the code is venturing into the new territory composed
of the pieces never snapped in place together before. Will work on the
previous patch to resolve as many concerns as possible.
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b7165e52b3c6..498cbb2c40a1 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1077,6 +1077,15 @@ static inline bool acpi_sleep_state_supported(u8 sleep_state)
return false;
}
+static inline struct irq_domain *acpi_irq_create_hierarchy(unsigned int flags,
+ unsigned int size,
+ struct fwnode_handle *fwnode,
+ const struct irq_domain_ops *ops,
+ void *host_data)
+{
+ return NULL;
+}
+
#endif /* !CONFIG_ACPI */
extern void arch_post_acpi_subsys_init(void);
--
2.45.0
--
Thank you,
Roman
