Displaying 7 results from an estimated 7 matches for "iort_iommu_typ".
Did you mean:
iort_iommu_type
2019 Nov 22
0
[RFC 04/13] ACPI/IORT: Add node categories
...6c91e06f8f..1d43fbc0001f 100644
--- a/drivers/acpi/iort.c
+++ b/drivers/acpi/iort.c
@@ -18,10 +18,10 @@
#include <linux/platform_device.h>
#include <linux/slab.h>
-#define IORT_TYPE_MASK(type) (1 << (type))
-#define IORT_MSI_TYPE (1 << ACPI_IORT_NODE_ITS_GROUP)
-#define IORT_IOMMU_TYPE ((1 << ACPI_IORT_NODE_SMMU) | \
- (1 << ACPI_IORT_NODE_SMMU_V3))
+enum iort_node_category {
+ IORT_MSI_TYPE,
+ IORT_IOMMU_TYPE,
+};
struct iort_its_msi_chip {
struct list_head list;
@@ -38,6 +38,20 @@ struct iort_fwnode {
static LIST_HEAD(iort_fwnode_list);
static DEFINE_SPI...
2019 Nov 22
0
[RFC 06/13] ACPI/IORT: Support VIOT virtio-pci node
...st_head list;
struct acpi_iort_node *iort_node;
struct fwnode_handle *fwnode;
+ struct iort_pci_devid *pci_devid;
};
static LIST_HEAD(iort_fwnode_list);
static DEFINE_SPINLOCK(iort_fwnode_lock);
@@ -44,7 +51,8 @@ static bool iort_type_matches(u8 type, enum iort_node_category category)
case IORT_IOMMU_TYPE:
return type == ACPI_IORT_NODE_SMMU ||
type == ACPI_IORT_NODE_SMMU_V3 ||
- type == ACPI_VIOT_IORT_NODE_VIRTIO_MMIO_IOMMU;
+ type == ACPI_VIOT_IORT_NODE_VIRTIO_MMIO_IOMMU ||
+ type == ACPI_VIOT_IORT_NODE_VIRTIO_PCI_IOMMU;
case IORT_MSI_TYPE:
return type ==...
2017 Nov 17
0
[RFC PATCH v2 4/5] ACPI/IORT: Support paravirtualized IOMMU
...a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index fde279b0a6d8..c7132e4a0560 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -29,7 +29,8 @@
#define IORT_TYPE_MASK(type) (1 << (type))
#define IORT_MSI_TYPE (1 << ACPI_IORT_NODE_ITS_GROUP)
#define IORT_IOMMU_TYPE ((1 << ACPI_IORT_NODE_SMMU) | \
- (1 << ACPI_IORT_NODE_SMMU_V3))
+ (1 << ACPI_IORT_NODE_SMMU_V3) | \
+ (1 << ACPI_IORT_NODE_PARAVIRT))
/* Until ACPICA headers cover IORT rev. C */
#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
@@ -616,6 +617,8 @@ static inline bool i...
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.
2017 Nov 17
11
[RFC PATCH v2 0/5] Add virtio-iommu driver
Implement the virtio-iommu driver following version 0.5 of the
specification [1]. Previous version of this code was sent back in April
[2], implementing the first public RFC. Since then there has been lots of
progress and discussion on the specification side, and I think the driver
is in a good shape now.
The reason patches 1-3 are only RFC is that I'm waiting on feedback from
the Virtio TC
2017 Nov 17
11
[RFC PATCH v2 0/5] Add virtio-iommu driver
Implement the virtio-iommu driver following version 0.5 of the
specification [1]. Previous version of this code was sent back in April
[2], implementing the first public RFC. Since then there has been lots of
progress and discussion on the specification side, and I think the driver
is in a good shape now.
The reason patches 1-3 are only RFC is that I'm waiting on feedback from
the Virtio TC