On 12/06/2020 15:30, Lorenzo Pieralisi wrote:
On Mon, Feb 17, 2020 at 12:08:48PM +, John Garry wrote:
Right, and even worse is that it relies on the port driver even
existing at all.
All this iommu group assignment should be taken outside device
driver probe paths.
However we could still
On Mon, Feb 17, 2020 at 12:08:48PM +, John Garry wrote:
> > >
> > > Right, and even worse is that it relies on the port driver even
> > > existing at all.
> > >
> > > All this iommu group assignment should be taken outside device
> > > driver probe paths.
> > >
> > > However we could still
Right, and even worse is that it relies on the port driver even
existing at all.
All this iommu group assignment should be taken outside device driver
probe paths.
However we could still consider device links for sync'ing the SMMU and
each device probing.
Yes, we should get that for DT
On 14/02/2020 2:09 pm, John Garry wrote:
@@ -2420,6 +2421,10 @@ void pci_device_add(struct pci_dev *dev, struct
pci_bus *bus)
/* Set up MSI IRQ domain */
pci_set_msi_domain(dev);
+ parent = dev->dev.parent;
+ if (parent && parent->bus == _bus_type)
+
@@ -2420,6 +2421,10 @@ void pci_device_add(struct pci_dev *dev, struct
pci_bus *bus)
/* Set up MSI IRQ domain */
pci_set_msi_domain(dev);
+ parent = dev->dev.parent;
+ if (parent && parent->bus == _bus_type)
+ device_link_add(>dev, parent, DL_FLAG_AUTOPROBE_CONSUMER);
On 13/02/2020 3:49 pm, John Garry wrote:
The underlying issue is that, for historical reasons, OF/IORT-based
IOMMU drivers have ended up with group allocation being tied to endpoint
driver probing via the dma_configure() mechanism (long story short,
driver probe is the only thing which can be
The underlying issue is that, for historical reasons, OF/IORT-based
IOMMU drivers have ended up with group allocation being tied to endpoint
driver probing via the dma_configure() mechanism (long story short,
driver probe is the only thing which can be delayed in order to wait for
a specific
+
On 19/09/2019 15:35, John Garry wrote:
On 19/09/2019 14:25, Robin Murphy wrote:
When the port eventually probes it gets a new, separate group.
This all seems to be as the built-in module init ordering is as
follows: pcieport drv, smmu drv, mlx5 drv
I notice that if I build the mlx5 drv as
On 19/09/2019 14:25, Robin Murphy wrote:
When the port eventually probes it gets a new, separate group.
This all seems to be as the built-in module init ordering is as
follows: pcieport drv, smmu drv, mlx5 drv
I notice that if I build the mlx5 drv as a ko and insert after boot,
all functions +
Hi John,
On 19/09/2019 09:43, John Garry wrote:
Hi all,
We have noticed a special behaviour on our arm64 D05 board when the SMMU
is enabled with regards PCI device iommu groups.
This platform does not support ACS, yet we find that all functions for a
PCI device are not grouped together:
Hi all,
We have noticed a special behaviour on our arm64 D05 board when the SMMU
is enabled with regards PCI device iommu groups.
This platform does not support ACS, yet we find that all functions for a
PCI device are not grouped together:
root@ubuntu:/sys# dmesg | grep "Adding to iommu
11 matches
Mail list logo
