Displaying 3 results from an estimated 3 matches for "iort_iommu_msi_get_resv_region".
Did you mean:
iort_iommu_msi_get_resv_regions
2019 Nov 22
0
[RFC 08/13] ACPI/IORT: Add callback to update a device's fwnode
...+ pdev->bus->number == devid->bus &&
+ pdev->devfn == devid->devfn) {
+ WARN_ON(fwnode && curr->fwnode);
+ curr->fwnode = fwnode;
+ break;
+ }
+ }
+ spin_unlock(&iort_fwnode_lock);
+}
+EXPORT_SYMBOL_GPL(iort_iommu_update_fwnode);
#else
int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
{ return 0; }
const struct iommu_ops *iort_iommu_configure(struct device *dev)
{ return NULL; }
+static void iort_iommu_update_fwnode(struct device *dev,
+ struct fwnode_handle *fwnode)
+{ }
#endif
static int nc_dma_get_range(struct device...
2019 Nov 22
16
[RFC 00/13] virtio-iommu on non-devicetree platforms
I'm seeking feedback on multi-platform support for virtio-iommu. At the
moment only devicetree (DT) is supported and we don't have a pleasant
solution for other platforms. Once we figure out the topology
description, x86 support is trivial.
Since the IOMMU manages memory accesses from other devices, the guest
kernel needs to initialize the IOMMU before endpoints start issuing DMA.
2019 Nov 22
16
[RFC 00/13] virtio-iommu on non-devicetree platforms
I'm seeking feedback on multi-platform support for virtio-iommu. At the
moment only devicetree (DT) is supported and we don't have a pleasant
solution for other platforms. Once we figure out the topology
description, x86 support is trivial.
Since the IOMMU manages memory accesses from other devices, the guest
kernel needs to initialize the IOMMU before endpoints start issuing DMA.