On Fri, 2020-10-09 at 01:27 +0200, Thomas Gleixner wrote: > On Thu, Oct 08 2020 at 22:39, David Woodhouse wrote: > > On Thu, 2020-10-08 at 23:14 +0200, Thomas Gleixner wrote: > > > > > > > > (We'd want the x86_vector_domain to actually have an MSI compose > > > > function in the !CONFIG_PCI_MSI case if we did this, of course.) > > > > > > The compose function and the vector domain wrapper can simply move to > > > vector.c > > > > I ended up putting __irq_msi_compose_msg() into apic.c and that way I > > can make virt_ext_dest_id static in that file. > > > > And then I can move all the HPET-MSI support into hpet.c too. > > Works for me. > > > https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/ext_dest_id > > For the next submission, can you please > > - pick up the -ENODEV changes for HPET/IOAPIC which I posted earlier I think the world will be a nicer place if HPET and IOAPIC have their own struct device and their drivers can just use dev_get_msi_domain(). The IRQ remapping drivers already plug into the device-add notifier and can fill in the appropriate MSI domain just like they do¹ for PCI and ACPI devices. Using platform_add_bundle() for HPET looks trivial enough; I'll have a play with that and then do IOAPIC too if/when the initialisation order and hotplug handling all works out OK to install the correct msi_domain. -- dwmw2 ¹ Yeah, I know they don't do it directly; it's done in pcibios_add_device(). But maybe they should? Because yeah, I also know they don't do it for ACPI devices either, because nothing does, and IRQ remapping on ANDD-listed devices doesn't work AFAICT.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
