Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [patch 02/33] genirq/msi: Provide struct msi_parent_ops | Date | Thu, 17 Nov 2022 16:58:42 +0100 |
| |
On Wed, Nov 16 2022 at 14:57, Jason Gunthorpe wrote: > On Fri, Nov 11, 2022 at 02:58:14PM +0100, Thomas Gleixner wrote: >> + * This is the most complex problem of per device MSI domains and the >> + * underlying interrupt domain hierarchy: >> + * >> + * The device domain to be initialized requests the broadest feature set >> + * possible and the underlying domain hierarchy puts restrictions on it. >> + * >> + * That's working perfectly fine for a strict parent->device model, but it >> + * falls apart with a root_parent->real_parent->device chain because the > > This language hurt my brain :)
IKR
>> +bool msi_parent_init_dev_msi_info(struct device *dev, struct irq_domain *domain, >> + struct irq_domain *real_parent, struct msi_domain_info *info) > > 'real_parent' is global IRQ_DOMAIN_FLAG_MSI_PARENT of the dev for > which we are constructing a msi_domain_info to create a child aka > IRQ_DOMAIN_FLAG_MSI_DEVICE? > > 'domain' is the current step in the hierarchy as we walk up the ops > pointers?
Yes.
> Maybe: > > @child_info: The MSI domain info of the IRQ_DOMAIN_FLAG_MSI_DEVICE > domain to be created > @parent_domain: The IRQ_DOMAIN_FLAG_MSI_PARENT domain for the child to > be created > @domain: The domain in the hierarchy this op is being called on
Definitely better.
> And perhaps it would be a bit clearer to put the parent_domain inside > the msi_domain_info, which is basically acting as an argument bundle > for a future allocation call?
Maybe. Let me try.
| |