Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [patch 21/33] genirq/msi: Provide msi_domain_alloc_irq_at() | Date | Fri, 18 Nov 2022 23:31:07 +0100 |
| |
On Fri, Nov 18 2022 at 10:18, Reinette Chatre wrote: >> @@ -141,7 +141,7 @@ static int msi_insert_desc(struct device *dev, struct msi_desc *desc, >> if (ret) >> goto fail; >> >> - desc->msi_index = index; >> + desc->msi_index = index - baseidx; > > Could msi_desc->msi_index be made bigger? The hardware I am testing > on claims to support more IMS entries than what the u16 can > accommodate.
Sure that's trivial. How big does it claim it is?
>> @@ -1476,9 +1476,10 @@ struct msi_map msi_domain_alloc_irq_at(struct device *dev, unsigned int domid, u >> const struct irq_affinity_desc *affdesc, >> union msi_dev_cookie *cookie) >> { >> + struct msi_ctrl ctrl = { .domid = domid, .nirqs = 1, }; >> + struct msi_domain_info *info; >> struct irq_domain *domain; >> struct msi_map map = { }; >> - struct msi_desc *desc; > > (*desc is still needed)
Yes, I figured that out later :)
> Thank you very much. With the above snippet it is possible to > allocate an IMS IRQ. I am not yet able to use the IRQ and I am working > on more tracing to figure out why. In the mean time, I did > just try the pci_ims_alloc_irq()/pci_ims_free_irq() flow and > pci_ims_free_irq() triggered the WARN below: > > remove_proc_entry: removing non-empty directory 'irq/220', leaking at least 'idxd-portal'
Hrm, that's the irq action directory. No idea why that is not torn down.
I assume your sequence is:
pci_ims_alloc(); request_irq(); <- This creates it free_irq(); <- This removes it pci_ims_free();
Right?
Thanks,
tglx
| |