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 c
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 n
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 == &pci_bus_type)
+ device_link_a
@@ -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 == &pci_bus_type)
+ device_link_add(&dev->dev, parent, DL_FLAG_AUTOPROBE_CO
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 de
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 IOMM
+
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 a
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:
r
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 gro
11 matches
Mail list logo