Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>
CC:     "x86@kernel.org" <x86@kernel.org>, Joerg Roedel <joro@8bytes.org>,
        "Will Deacon" <will@kernel.org>,
        "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
        Bjorn Helgaas <bhelgaas@google.com>,
        "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
        Marc Zyngier <maz@kernel.org>,
        "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
        Jason Gunthorpe <jgg@mellanox.com>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        Alex Williamson <alex.williamson@redhat.com>,
        "Williams, Dan J" <dan.j.williams@intel.com>,
        Logan Gunthorpe <logang@deltatee.com>,
        "Raj, Ashok" <ashok.raj@intel.com>, Jon Mason <jdmason@kudzu.us>,
        Allen Hubbe <allenbh@gmail.com>
Subject: RE: [patch V2 02/33] genirq/msi: Provide struct msi_parent_ops
Thread-Topic: [patch V2 02/33] genirq/msi: Provide struct msi_parent_ops
Thread-Index: AQHY/bbfZgnIzHqDcU+i9IUI1W3Xhq5MB7NAgABaboCAAOBlEA==
Date:   Thu, 24 Nov 2022 00:53:29 +0000
Message-ID: <BN9PR11MB52763BEF1A4C88368B8A9E448C0F9@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20221121083657.157152924@linutronix.de>
 <20221121091326.604272160@linutronix.de>
 <BN9PR11MB52768F0E5B9A4D8E2CF9C5578C0C9@BN9PR11MB5276.namprd11.prod.outlook.com>
 <878rk1gb9g.ffs@tglx>
In-Reply-To: <878rk1gb9g.ffs@tglx>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?pR9gdYzBOpxtNbvTM/KaSQxmxfr6rkGetBFG2nkbDen8k2m82X8KzPRzI7FE?=
 =?us-ascii?Q?3xZ9oI1GGyTuup70S4JTUpUeisxaEcSyNGxtQN2+H1ATr4YtKKgTyg/DsSy6?=
 =?us-ascii?Q?wIw5aNGpgKxOZ7O2Bw3TOFDfy1AhQZqYZBxGAJUUhPMNtnbL+frIECkMMfcC?=
 =?us-ascii?Q?a7QYeW8ktO/uoIFO+TNJurWcwOTv8inrB2k/yAG5QJ5YftzEtYU4P6DBnNqT?=
 =?us-ascii?Q?QEW4Ai+lyF3JiThTja2sBSaaCwTjpVRD8zeJ5LIO9hAnY/Mn+KP41fO7GZHu?=
 =?us-ascii?Q?aFVyImcfzj41Bm84JJeCFEJJ5dTePZkpLO6QPTPl8ZGcl5Z8CLZQkWdNUkf2?=
 =?us-ascii?Q?Xda3tCeCMh5Y7FURPv8mnIToGV97Mm20P4Zu2erhfulXJ0BUMqXrrI+02IDE?=
 =?us-ascii?Q?6NVzbiP+JaQrGb+TZKGdGVWtLLrergh6/1YPd33J7WqjCUnX/jHEyCwfRQpx?=
 =?us-ascii?Q?q6z1/UfjGbZvxtV1LP36+12iNrOZccw1L/tr0y58ozvPE1VBlHnRUCSpr0jh?=
 =?us-ascii?Q?fD5N/JEU1PjrF+OgIsfWOGeHcT5ep/3rGvr9NzGMducJdKWDLQOMuQdH2xW/?=
 =?us-ascii?Q?qcxtcfwKLi/+WmeYKkJYzfYKkD2z+SL7CynOS17tG2NYIybVd3jbmCO5c62E?=
 =?us-ascii?Q?tM1PKbL1e9l8gaF42xfXk22b9DMHwJxk37uhqnHMTRzbSe/2o0j2eaArk4Pj?=
 =?us-ascii?Q?FeXnnCn/TxqiOV6QcWhg6+ofpipvIX1EKZ7CWxLh2pttScUVL7zXGhCyu+s0?=
 =?us-ascii?Q?Kk7Th4UMIJGS5PPcRSSrf0BOKZBOaca69ht0wKu1D6UjPe/psGgm8a5ugBnj?=
 =?us-ascii?Q?Gs9dmNA9NznD3gWZavbDg4qJyO45KabRcpbF0em/BGkRPMLkqqxwA/1YE7xc?=
 =?us-ascii?Q?IwRJ2tYRWZSfUJ341mVuby8yHt7RAoesGqKYTLP9UWNItx3gC94SfN3vXr70?=
 =?us-ascii?Q?1XYidYVFGmxcCZeixLR8AL0ixaUlCgZFT0aiAUuTsdP9SC1JDJoRiLvnK/5L?=
 =?us-ascii?Q?HX1WhIizR11iaWF5zW/NGoBgAF1NHjozxr9tLLFdEFyx4mNJK/JZjR5Z0c3D?=
 =?us-ascii?Q?OuzYjmsLSEjVr+Zl8k+qp4F7+jPEBVnq5rd1lUlkOYImb7C5PRT3QiLCNue3?=
 =?us-ascii?Q?xkv01U3nJSNWFhakSw++p/ShnZ9QzPDW8AoPNjMd2KtCC3OQ9AhoYR7At4ve?=
 =?us-ascii?Q?cywyLJqYsOwTgwr1+srzceUP/hYtiTgAZzhvyRUQiZwnOdDTJ1W04P4fqefr?=
 =?us-ascii?Q?4EwWkw74UQfQ98l66MXDxIfVl8sIYx2H2o9NFBVq1PixtUYHCJgNjw90t2M1?=
 =?us-ascii?Q?OVlSB2BZ7V19ugrEuhE1AAA3CG1F4P1isd7J+aX7l588G2bE9J0rCglxt19t?=
 =?us-ascii?Q?JJPtqGsqZieUt0Wm2AJLmvLsfzQWqwot5qf88Xc/gh/jBC6mP0EDwk4PfEEv?=
 =?us-ascii?Q?DzvgFxYPrAqgaQbm98xSVV+wxD+mRkLOZ8h4s0Dj/fXww/Q3nLBxIqH0aFic?=
 =?us-ascii?Q?tc4IacG7vcnsb0lYOcShv4KdmxiO1lF991T4cPonRXvAChUFymDds3NLZo6N?=
 =?us-ascii?Q?DbVV2avogw9d/ToCHN6ElSnZAezp8WNPkj6uTu/F?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3d0f62a0-a2f4-4185-b0d7-08dacdb64dc9
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2022 00:53:29.8995
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hfxvB3aVSshmDKxK+7+WAjOBOPT94MWxgh5QODjEP61pw0A5ak8wse3kvGgik2a/Bka39URhHft70e8+Rxm7hA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB6777
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Thomas Gleixner <tglx@linutronix.de>
> Sent: Wednesday, November 23, 2022 7:29 PM
>=20
> 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 t=
hat'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 minima=
l
> > 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 restriction=
s to
> > info->flags.
> >
> > I can see why this is required for x86 given that MULTI_MSI is supporte=
d
> > 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-lay=
ers
> > hierarchy where the root parent wants to check both two intermediate
> > parents?
>=20
> Sure. Nothing prevents you from doing so:
>=20
> dom4:
>     .init... =3D dom4_init
>=20
> dom4_init()
>     do_stuff()
>     invoke parent init
>=20
> dom3:
>     .init... =3D parent_init
>=20
> dom2:
>     .init... =3D dom2_init
>=20
> dom2_init()
>     do_stuff()
>     invoke parent init
>=20
> ....
>=20
> See?
>=20

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