Messages in this thread | | | Date | Fri, 06 Nov 2020 09:43:58 +0000 | From | Marc Zyngier <> | Subject | Re: Aw: Re: Re: [PATCH] pci: mediatek: fix warning in msi.h |
| |
On 2020-11-05 23:00, Thomas Gleixner wrote: > On Thu, Nov 05 2020 at 09:20, Marc Zyngier wrote: >> On 2020-11-04 23:14, Thomas Gleixner wrote: >>> /* Resource alignment requirements */ >>> resource_size_t (*align_resource)(struct pci_dev *dev, >> >> If that's the direction of travel, we also need something like this >> for configuration where the host bridge relies on an external MSI >> block >> that uses MSI domains (boot-tested in a GICv3 guest). > > Some more context would be helpful. Brain fails to decode the logic > here.
OK, let me try again.
The MSI controller, which is the thing that deals with MSIs in the system (GICv2m, GICv3-ITS, and a number of others), is optional, is not part of the host bridge (it has nothing to do with PCI at all), and the bridge driver has absolutely no idea whether:
- there is something that provides MSI or not - that something has successfully been initialised or not (which translates into an MSI domain being present or not)
This is the case for most ARM systems, and all KVM/arm guests. Booting a VM without MSIs is absolutely trivial, and actually makes sense for some of the smaller guests.
In these conditions, your no_msi attribute doesn't work as is: we can't decide on its value at probe time without extracting all of the OF/ACPI logic that deals with MSI domains from the core code, and making it available to the host bridge drivers for systems that follow that model.
Using the flow you insist on requires parsing the topology twice:
- once to find out whether there is actually a MSI provider registered for the host bridge in order to set the no_msi flag
- once to actually be able to store the domain into the pci_bus structure, as it isn't available at probe time.
My last suggestion is to indicate to the core code that there is a *possible* MSI controller available in the form of a MSI domain. This is still suboptimal compared to checking the presence an MSI domain in core code (my initial suggestion), but the fallback stuff gets in the way (though I still think it can be made to work).
Anyway, this was my last attempt at addressing the problem. Most people won't see it. The couple of drivers that require the fallback hack are usually selected in distro kernels, and do a good job hiding the error.
M. -- Jazz is not dead. It just smells funny...
| |