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

[Tian, Kevin]

> From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Sent: Wednesday, November 23, 2022 7:29 PM
> 
> On Wed, Nov 23 2022 at 07:57, Kevin Tian wrote:
> >> From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> >> + * 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.