On Thu, Sep 18, 2025 at 10:21 AM Lorenzo Pieralisi
[off-list ref] wrote:
On Thu, Sep 18, 2025 at 08:55:55AM -0500, Rob Herring wrote:
quoted
On Tue, Sep 16, 2025 at 11:18:58AM +0200, Lorenzo Pieralisi wrote:
quoted
In some legacy platforms the MSI controller for a PCI host
bridge is identified by an msi-parent property whose phandle
points at an MSI controller node with no #msi-cells property,
that implicitly means #msi-cells == 0.
For such platforms, mapping a device ID and retrieving the
MSI controller node becomes simply a matter of checking
whether in the device hierarchy there is an msi-parent property
pointing at an MSI controller node with such characteristics.
Add a helper function to of_msi_xlate() to check the msi-parent
property in addition to msi-map and retrieve the MSI controller
node (with a 1:1 ID deviceID-IN<->deviceID-OUT mapping) to
provide support for deviceID mapping and MSI controller node
retrieval for such platforms.
Your line wrapping is a bit short.
I had a look at who is parsing "msi-parent" themselves as that's
typically a recipe for doing it incorrectly ('interrupt-map' anyone).
Can we make iproc_pcie_msi_enable() use this? It's quite ugly reaching
into the GICv3 node...
I am not sure I get what you mean here. Possibly iproc_pcie_msi_enable()
can reuse this patch's code if I extend it and make it a global function,
yes and somehow use that function to carry out the check for an
msi-parent property with no #msi-cells property or an #msi-cells == 0.
I meant using of_msi_xlate() (or even of_msi_get_domain()).
Don't get what GICv3 node has to do with that though, sorry.
Just trace what the code there does after it gets the MSI parent. I
didn't study it too closely, but why is a iProc PCIe parsing GICv3 MSI
stuff itself? There's either some missing feature in the
irqchip/domain APIs or it's being dumb.
Rob