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.