Re: [Patch V2 13/13] genirq/msi: Provide helpers to return Linux IRQ/dev_msi hw IRQ number
Hi Marc,
On 3/26/2021 6:28 PM, Marc Zyngier wrote:
On Fri, 26 Mar 2021 01:02:43 +,
"Dey, Megha" wrote:
Hi Marc,
On 3/25/2021 10:53 AM, Marc Zyngier wrote:
On Fri, 26 Feb 2021 20:11:17 +,
Megha Dey wrote:
From: Dave Jiang
Add new helpers to get the Linux IRQ number and device specific index
for given device-relative vector so that the drivers don't need to
allocate their own arrays to keep track of the vectors and hwirq for
the multi vector device MSI case.
Reviewed-by: Tony Luck
Signed-off-by: Dave Jiang
Signed-off-by: Megha Dey
---
include/linux/msi.h | 2 ++
kernel/irq/msi.c| 44
2 files changed, 46 insertions(+)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 24abec0..d60a6ba 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -451,6 +451,8 @@ struct irq_domain *platform_msi_create_irq_domain(struct
fwnode_handle *fwnode,
int platform_msi_domain_alloc_irqs(struct device *dev, unsigned int nvec,
irq_write_msi_msg_t write_msi_msg);
void platform_msi_domain_free_irqs(struct device *dev);
+int msi_irq_vector(struct device *dev, unsigned int nr);
+int dev_msi_hwirq(struct device *dev, unsigned int nr);
/* When an MSI domain is used as an intermediate domain */
int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 047b59d..f2a8f55 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -581,4 +581,48 @@ struct msi_domain_info *msi_get_domain_info(struct
irq_domain *domain)
return (struct msi_domain_info *)domain->host_data;
}
+/**
+ * msi_irq_vector - Get the Linux IRQ number of a device vector
+ * @dev: device to operate on
+ * @nr: device-relative interrupt vector index (0-based).
+ *
+ * Returns the Linux IRQ number of a device vector.
+ */
+int msi_irq_vector(struct device *dev, unsigned int nr)
+{
+ struct msi_desc *entry;
+ int i = 0;
+
+ for_each_msi_entry(entry, dev) {
+ if (i == nr)
+ return entry->irq;
+ i++;
This obviously doesn't work with Multi-MSI, does it?
This API is only for devices that support device MSI interrupts. They
follow MSI-x format and don't support multi MSI (part of MSI).
Not sure if I am missing something here, can you please let me know?
Nothing in the prototype of the function indicates this limitation,
nor does the documentation. And I'm not sure why you should exclude
part of the MSI functionality here. It can't be for performance
reason, so you might as well make sure this works for all the MSI
variants:
int msi_irq_vector(struct device *dev, unsigned int nr)
{
struct msi_desc *entry;
int irq, index = 0;
for_each_msi_vector(entry, irq, dev) {
if (index == nr}
return irq;
index++;
}
return WARN_ON_ONCE(-EINVAL);
}
Ok, got it!
+ }
+ WARN_ON_ONCE(1);
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(msi_irq_vector);
+
+/**
+ * dev_msi_hwirq - Get the device MSI hw IRQ number of a device vector
+ * @dev: device to operate on
+ * @nr: device-relative interrupt vector index (0-based).
+ *
+ * Return the dev_msi hw IRQ number of a device vector.
+ */
+int dev_msi_hwirq(struct device *dev, unsigned int nr)
+{
+ struct msi_desc *entry;
+ int i = 0;
+
+ for_each_msi_entry(entry, dev) {
+ if (i == nr)
+ return entry->device_msi.hwirq;
+ i++;
+ }
+ WARN_ON_ONCE(1);
+ return -EINVAL;
+}
And this helper would be more generally useful if it returned the n-th
msi_desc entry rather than some obscure field in a substructure.
struct msi_desc *msi_get_nth_desc(struct device *dev, unsigned int nth)
{
struct msi_desc *entry = NULL;
unsigned int i = 0;
for_each_msi_entry(entry, dev) {
if (i == nth)
return entry;
i++;
}
WARN_ON_ONCE(!entry);
return entry;
}
You can always wrap it for your particular use case.
Yeah, makes sense.
+EXPORT_SYMBOL_GPL(dev_msi_hwirq);
+
#endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
And what uses these helpers?]
These helpers are to be used by a driver series(Intel's IDXD driver)
which is currently stuck due to VFIO refactoring.
Then I's suggest you keep the helpers together with the actual user,
unless this can generally be useful to existing users (exported
symbols without in-tree users is always a bit odd).
Yeah in the next submission, we will submit this patch series along with
the user driver patch series.
Thanks,
M.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [Patch V2 12/13] irqchip: Add IMS (Interrupt Message Store) driver
Hi Thomas/Marc, On 3/25/2021 12:07 PM, Thomas Gleixner wrote: On Thu, Mar 25 2021 at 17:43, Marc Zyngier wrote: On Fri, 26 Feb 2021 20:11:16 +, Megha Dey wrote: + +#include + +#ifdef CONFIG_IMS_MSI_ARRAY Given that this covers the whole driver, what is this #defined used for? You might as well make the driver depend on this config option. That's a leftover from the initial version I wrote which had also support for IMS_MSI_QUEUE to store the message in queue memory, but we have no use case yet for it. But yes, as things stand now it does not make any sense and IIRC at the end they do not share anything in the C file except for some includes at the very end. Sure, I will make this change. Thanks, tglx ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [Patch V2 13/13] genirq/msi: Provide helpers to return Linux IRQ/dev_msi hw IRQ number
Hi Marc,
On 3/25/2021 10:53 AM, Marc Zyngier wrote:
On Fri, 26 Feb 2021 20:11:17 +,
Megha Dey wrote:
From: Dave Jiang
Add new helpers to get the Linux IRQ number and device specific index
for given device-relative vector so that the drivers don't need to
allocate their own arrays to keep track of the vectors and hwirq for
the multi vector device MSI case.
Reviewed-by: Tony Luck
Signed-off-by: Dave Jiang
Signed-off-by: Megha Dey
---
include/linux/msi.h | 2 ++
kernel/irq/msi.c| 44
2 files changed, 46 insertions(+)
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 24abec0..d60a6ba 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -451,6 +451,8 @@ struct irq_domain *platform_msi_create_irq_domain(struct
fwnode_handle *fwnode,
int platform_msi_domain_alloc_irqs(struct device *dev, unsigned int nvec,
irq_write_msi_msg_t write_msi_msg);
void platform_msi_domain_free_irqs(struct device *dev);
+int msi_irq_vector(struct device *dev, unsigned int nr);
+int dev_msi_hwirq(struct device *dev, unsigned int nr);
/* When an MSI domain is used as an intermediate domain */
int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 047b59d..f2a8f55 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -581,4 +581,48 @@ struct msi_domain_info *msi_get_domain_info(struct
irq_domain *domain)
return (struct msi_domain_info *)domain->host_data;
}
+/**
+ * msi_irq_vector - Get the Linux IRQ number of a device vector
+ * @dev: device to operate on
+ * @nr: device-relative interrupt vector index (0-based).
+ *
+ * Returns the Linux IRQ number of a device vector.
+ */
+int msi_irq_vector(struct device *dev, unsigned int nr)
+{
+ struct msi_desc *entry;
+ int i = 0;
+
+ for_each_msi_entry(entry, dev) {
+ if (i == nr)
+ return entry->irq;
+ i++;
This obviously doesn't work with Multi-MSI, does it?
This API is only for devices that support device MSI interrupts. They
follow MSI-x format and don't support multi MSI (part of MSI).
Not sure if I am missing something here, can you please let me know?
+ }
+ WARN_ON_ONCE(1);
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(msi_irq_vector);
+
+/**
+ * dev_msi_hwirq - Get the device MSI hw IRQ number of a device vector
+ * @dev: device to operate on
+ * @nr: device-relative interrupt vector index (0-based).
+ *
+ * Return the dev_msi hw IRQ number of a device vector.
+ */
+int dev_msi_hwirq(struct device *dev, unsigned int nr)
+{
+ struct msi_desc *entry;
+ int i = 0;
+
+ for_each_msi_entry(entry, dev) {
+ if (i == nr)
+ return entry->device_msi.hwirq;
+ i++;
+ }
+ WARN_ON_ONCE(1);
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(dev_msi_hwirq);
+
#endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
And what uses these helpers?]
These helpers are to be used by a driver series(Intel's IDXD driver)
which is currently stuck due to VFIO refactoring.
Thanks,
M.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V2 00/46] x86, PCI, XEN, genirq ...: Prepare for device MSI
Hi Thomas/Jason, On 9/30/2020 8:20 AM, Thomas Gleixner wrote: On Wed, Sep 30 2020 at 08:43, Jason Gunthorpe wrote: On Wed, Sep 30, 2020 at 08:41:48AM +0200, Thomas Gleixner wrote: On Tue, Sep 29 2020 at 16:03, Megha Dey wrote: On 8/26/2020 4:16 AM, Thomas Gleixner wrote: #9 is obviously just for the folks interested in IMS I see that the tip tree (as of 9/29) has most of these patches but notice that the DEV_MSI related patches haven't made it. I have tested the tip tree(x86/irq branch) with your DEV_MSI infra patches and our IMS patches with the IDXD driver and was Your IMS patches? Why do you need something special again? By IMS patches, I meant your IMS driver patch that was updated (as it was untested, it had some compile errors and we removed the IMS_QUEUE parts) : https://lore.kernel.org/lkml/160021246221.67751.16280230469654363209.st...@djiang5-desk3.ch.intel.com/ and some iommu related changes required by IMS. https://lore.kernel.org/lkml/160021246905.67751.1674517279122764758.st...@djiang5-desk3.ch.intel.com/ The whole patchset can be found here: https://lore.kernel.org/lkml/f4a085f1-f6de-2539-12fe-c7308d243...@intel.com/ It would be great if you could review the IMS patches :) wondering if we should push out those patches as part of our patchset? As I don't have any hardware to test that, I was waiting for you and Jason to confirm that this actually works for the two different IMS implementations. How urgently do you need this? The code looked good from what I understood. It will be a while before we have all the parts to send an actual patch though. I personally do not need it at all :) Megha might have different thoughts... I have tested these patches and it works fine (I had to add a couple of EXPORT_SYMBOLS). We were hoping to get IMS in the 5.10 merge window :) We might be able to put together a mockup just to prove it If that makes Megha's stuff going that would of course be appreciated, but we can defer the IMS_QUEUE part for later. It's orthogonal to the IMS_ARRAY stuff. In our patch series, we have removed the IMS_QUEUE stuff and retained only the IMS_ARRAY parts as that was sufficient for us. Thanks, tglx ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V2 00/46] x86, PCI, XEN, genirq ...: Prepare for device MSI
Hi Thomas, On 8/26/2020 4:16 AM, Thomas Gleixner wrote: This is the second version of providing a base to support device MSI (non PCI based) and on top of that support for IMS (Interrupt Message Storm) based devices in a halfways architecture independent way. The first version can be found here: https://lore.kernel.org/r/20200821002424.119492...@linutronix.de It's still a mixed bag of bug fixes, cleanups and general improvements which are worthwhile independent of device MSI. There are quite a bunch of issues to solve: - X86 does not use the device::msi_domain pointer for historical reasons and due to XEN, which makes it impossible to create an architecture agnostic device MSI infrastructure. - X86 has it's own msi_alloc_info data type which is pointlessly different from the generic version and does not allow to share code. - The logic of composing MSI messages in an hierarchy is busted at the core level and of course some (x86) drivers depend on that. - A few minor shortcomings as usual This series addresses that in several steps: 1) Accidental bug fixes iommu/amd: Prevent NULL pointer dereference 2) Janitoring x86/init: Remove unused init ops PCI: vmd: Dont abuse vector irqomain as parent x86/msi: Remove pointless vcpu_affinity callback 3) Sanitizing the composition of MSI messages in a hierarchy genirq/chip: Use the first chip in irq_chip_compose_msi_msg() x86/msi: Move compose message callback where it belongs 4) Simplification of the x86 specific interrupt allocation mechanism x86/irq: Rename X86_IRQ_ALLOC_TYPE_MSI* to reflect PCI dependency x86/irq: Add allocation type for parent domain retrieval iommu/vt-d: Consolidate irq domain getter iommu/amd: Consolidate irq domain getter iommu/irq_remapping: Consolidate irq domain lookup 5) Consolidation of the X86 specific interrupt allocation mechanism to be as close as possible to the generic MSI allocation mechanism which allows to get rid of quite a bunch of x86'isms which are pointless x86/irq: Prepare consolidation of irq_alloc_info x86/msi: Consolidate HPET allocation x86/ioapic: Consolidate IOAPIC allocation x86/irq: Consolidate DMAR irq allocation x86/irq: Consolidate UV domain allocation PCI/MSI: Rework pci_msi_domain_calc_hwirq() x86/msi: Consolidate MSI allocation x86/msi: Use generic MSI domain ops 6) x86 specific cleanups to remove the dependency on arch_*_msi_irqs() x86/irq: Move apic_post_init() invocation to one place x86/pci: Reducde #ifdeffery in PCI init code x86/irq: Initialize PCI/MSI domain at PCI init time irqdomain/msi: Provide DOMAIN_BUS_VMD_MSI PCI: vmd: Mark VMD irqdomain with DOMAIN_BUS_VMD_MSI PCI/MSI: Provide pci_dev_has_special_msi_domain() helper x86/xen: Make xen_msi_init() static and rename it to xen_hvm_msi_init() x86/xen: Rework MSI teardown x86/xen: Consolidate XEN-MSI init irqdomain/msi: Allow to override msi_domain_alloc/free_irqs() x86/xen: Wrap XEN MSI management into irqdomain iommm/vt-d: Store irq domain in struct device iommm/amd: Store irq domain in struct device x86/pci: Set default irq domain in pcibios_add_device() PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable x86/irq: Cleanup the arch_*_msi_irqs() leftovers x86/irq: Make most MSI ops XEN private iommu/vt-d: Remove domain search for PCI/MSI[X] iommu/amd: Remove domain search for PCI/MSI 7) X86 specific preparation for device MSI x86/irq: Add DEV_MSI allocation type x86/msi: Rename and rework pci_msi_prepare() to cover non-PCI MSI 8) Generic device MSI infrastructure platform-msi: Provide default irq_chip:: Ack genirq/proc: Take buslock on affinity write genirq/msi: Provide and use msi_domain_set_default_info_flags() platform-msi: Add device MSI infrastructure irqdomain/msi: Provide msi_alloc/free_store() callbacks 9) POC of IMS (Interrupt Message Storm) irq domain and irqchip implementations for both device array and queue storage. irqchip: Add IMS (Interrupt Message Storm) driver - NOT FOR MERGING Changes vs. V1: - Addressed various review comments and addressed the 0day fallout. - Corrected the XEN logic (Jürgen) - Make the arch fallback in PCI/MSI opt-in not opt-out (Bjorn) - Fixed the compose MSI message inconsistency - Ensure that the necessary flags are set for device SMI - Make the irq bus logic work for affinity setting to prepare support for IMS storage in queue memory. It turned out to be less scary than I feared. - Remove leftovers in iommu/intel|amd - Reworked the IMS POC driver to cover queue storage so Jason can have a look whether that fits the needs of MLX
Re: [patch V2 29/46] irqdomain/msi: Allow to override msi_domain_alloc/free_irqs()
Hi Thomas,
On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
From: Thomas Gleixner
To support MSI irq domains which do not fit at all into the regular MSI
irqdomain scheme, like the XEN MSI interrupt management for PV/HVM/DOM0,
it's necessary to allow to override the alloc/free implementation.
This is a preperatory step to switch X86 away from arch_*_msi_irqs() and
store the irq domain pointer right in struct device.
No functional change for existing MSI irq domain users.
Aside of the evil XEN wrapper this is also useful for special MSI domains
which need to do extra alloc/free work before/after calling the generic
core function. Work like allocating/freeing MSI descriptors, MSI storage
space etc.
Signed-off-by: Thomas Gleixner
---
include/linux/msi.h | 27
kernel/irq/msi.c| 70
+++-
2 files changed, 75 insertions(+), 22 deletions(-)
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -241,6 +241,10 @@ struct msi_domain_info;
* @msi_finish: Optional callback to finalize the allocation
* @set_desc: Set the msi descriptor for an interrupt
* @handle_error: Optional error handler if the allocation fails
+ * @domain_alloc_irqs: Optional function to override the default allocation
+ * function.
+ * @domain_free_irqs: Optional function to override the default free
+ * function.
*
* @get_hwirq, @msi_init and @msi_free are callbacks used by
* msi_create_irq_domain() and related interfaces
@@ -248,6 +252,22 @@ struct msi_domain_info;
* @msi_check, @msi_prepare, @msi_finish, @set_desc and @handle_error
* are callbacks used by msi_domain_alloc_irqs() and related
* interfaces which are based on msi_desc.
+ *
+ * @domain_alloc_irqs, @domain_free_irqs can be used to override the
+ * default allocation/free functions (__msi_domain_alloc/free_irqs). This
+ * is initially for a wrapper around XENs seperate MSI universe which can't
+ * be wrapped into the regular irq domains concepts by mere mortals. This
+ * allows to universally use msi_domain_alloc/free_irqs without having to
+ * special case XEN all over the place.
+ *
+ * Contrary to other operations @domain_alloc_irqs and @domain_free_irqs
+ * are set to the default implementation if NULL and even when
+ * MSI_FLAG_USE_DEF_DOM_OPS is not set to avoid breaking existing users and
+ * because these callbacks are obviously mandatory.
+ *
+ * This is NOT meant to be abused, but it can be useful to build wrappers
+ * for specialized MSI irq domains which need extra work before and after
+ * calling __msi_domain_alloc_irqs()/__msi_domain_free_irqs().
*/
struct msi_domain_ops {
irq_hw_number_t (*get_hwirq)(struct msi_domain_info *info,
@@ -270,6 +290,10 @@ struct msi_domain_ops {
struct msi_desc *desc);
int (*handle_error)(struct irq_domain *domain,
struct msi_desc *desc, int error);
+ int (*domain_alloc_irqs)(struct irq_domain *domain,
+struct device *dev, int nvec);
+ void(*domain_free_irqs)(struct irq_domain *domain,
+ struct device *dev);
};
/**
@@ -327,8 +351,11 @@ int msi_domain_set_affinity(struct irq_d
struct irq_domain *msi_create_irq_domain(struct fwnode_handle *fwnode,
struct msi_domain_info *info,
struct irq_domain *parent);
+int __msi_domain_alloc_irqs(struct irq_domain *domain, struct device *dev,
+ int nvec);
int msi_domain_alloc_irqs(struct irq_domain *domain, struct device *dev,
int nvec);
+void __msi_domain_free_irqs(struct irq_domain *domain, struct device *dev);
void msi_domain_free_irqs(struct irq_domain *domain, struct device *dev);
struct msi_domain_info *msi_get_domain_info(struct irq_domain *domain);
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -229,11 +229,13 @@ static int msi_domain_ops_check(struct i
}
static struct msi_domain_ops msi_domain_ops_default = {
- .get_hwirq = msi_domain_ops_get_hwirq,
- .msi_init = msi_domain_ops_init,
- .msi_check = msi_domain_ops_check,
- .msi_prepare= msi_domain_ops_prepare,
- .set_desc = msi_domain_ops_set_desc,
+ .get_hwirq = msi_domain_ops_get_hwirq,
+ .msi_init = msi_domain_ops_init,
+ .msi_check = msi_domain_ops_check,
+ .msi_prepare= msi_domain_ops_prepare,
+ .set_desc = msi_domain_ops_set_desc,
+ .domain_alloc_irqs = __msi_domain_alloc_irqs,
+ .domain_free_irqs = __msi_domain_free_irqs,
};
static void msi_domain_update_dom_ops(struct msi_domain_info *info)
@
Re: [patch V2 15/46] x86/irq: Consolidate DMAR irq allocation
Hi Thomas,
On 8/26/2020 1:50 PM, Thomas Gleixner wrote:
On Wed, Aug 26 2020 at 20:32, Thomas Gleixner wrote:
On Wed, Aug 26 2020 at 09:50, Megha Dey wrote:
@@ -329,15 +329,15 @@ static struct irq_chip dmar_msi_controll
static irq_hw_number_t dmar_msi_get_hwirq(struct msi_domain_info *info,
msi_alloc_info_t *arg)
{
- return arg->dmar_id;
+ return arg->hwirq;
Shouldn't this return the arg->devid which gets set in dmar_alloc_hwirq?
Indeed.
But for simplicity we can set arg->hwirq to the dmar id right in the
alloc function and then once the generic ops are enabled remove the dmar
callback completely
True, can get rid of more code that way.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V2 15/46] x86/irq: Consolidate DMAR irq allocation
Hi Thomas,
On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
From: Thomas Gleixner
None of the DMAR specific fields are required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |6 --
arch/x86/kernel/apic/msi.c| 10 +-
2 files changed, 5 insertions(+), 11 deletions(-)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -83,12 +83,6 @@ struct irq_alloc_info {
irq_hw_number_t msi_hwirq;
};
#endif
-#ifdef CONFIG_DMAR_TABLE
- struct {
- int dmar_id;
- void*dmar_data;
- };
-#endif
#ifdefCONFIG_X86_UV
struct {
int uv_limit;
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -329,15 +329,15 @@ static struct irq_chip dmar_msi_controll
static irq_hw_number_t dmar_msi_get_hwirq(struct msi_domain_info *info,
msi_alloc_info_t *arg)
{
- return arg->dmar_id;
+ return arg->hwirq;
Shouldn't this return the arg->devid which gets set in dmar_alloc_hwirq?
-Megha
}
static int dmar_msi_init(struct irq_domain *domain,
struct msi_domain_info *info, unsigned int virq,
irq_hw_number_t hwirq, msi_alloc_info_t *arg)
{
- irq_domain_set_info(domain, virq, arg->dmar_id, info->chip, NULL,
- handle_edge_irq, arg->dmar_data, "edge");
+ irq_domain_set_info(domain, virq, arg->devid, info->chip, NULL,
+ handle_edge_irq, arg->data, "edge");
return 0;
}
@@ -384,8 +384,8 @@ int dmar_alloc_hwirq(int id, int node, v
init_irq_alloc_info(&info, NULL);
info.type = X86_IRQ_ALLOC_TYPE_DMAR;
- info.dmar_id = id;
- info.dmar_data = arg;
+ info.devid = id;
+ info.data = arg;
return irq_domain_alloc_irqs(domain, 1, node, &info);
}
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
