RE: [patch V2 02/33] genirq/msi: Provide struct msi_parent_ops

Tian, Kevin
2022-11-24T00:54:46Z

> From: Thomas Gleixner <tglx@linutronix.de>
> Sent: Wednesday, November 23, 2022 7:29 PM
>
> On Wed, Nov 23 2022 at 07:57, Kevin Tian wrote:
> >> From: Thomas Gleixner <tglx@linutronix.de>
> >> + * One solution is to let the root domain handle the initialization that's
> >> + * why there is the @domain and the @msi_parent_domain pointer.
> >
> > This is the part which I don't quite understand (sorry with limited
> knowledge
> > in this area).
> >
> > In concept a hierarchical model has restrictions added up when moving
> > down to lower layers i.e. presumably the root domain decides the minimal
> > supported capabilities. In this case there is no need of a real parent pointer
> > as long as every domain in the stack incrementally adds its restrictions to
> > info->flags.
> >
> > I can see why this is required for x86 given that MULTI_MSI is supported
> > only with IR. and we cannot make vector domain inclusively claiming
> > MULTI_MSI since it's completely broken when the vector domain becomes
> > the parent itself, in absence of IR.
> >
> > Just be curious whether this intermediate-parent-deciding-restrictions
> > is generic instead of x86 specific, e.g. is it possible to have a 4-layers
> > hierarchy where the root parent wants to check both two intermediate
> > parents?
>
> Sure. Nothing prevents you from doing so:
>
> dom4:
> .init... = dom4_init
>
> dom4_init()
> do_stuff()
> invoke parent init
>
> dom3:
> .init... = parent_init
>
> dom2:
> .init... = dom2_init
>
> dom2_init()
> do_stuff()
> invoke parent init
>
> ....
>
> See?
>

yes. with the hierarchy being arch specific those dependencies
can be easily figured out.