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;
Date:   Wed, 16 Nov 2022 14:57:34 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     LKML <linux-kernel@vger.kernel.org>, x86@kernel.org,
        Joerg Roedel <joro@8bytes.org>, Will Deacon <will@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>,
        Dave Jiang <dave.jiang@intel.com>,
        Alex Williamson <alex.williamson@redhat.com>,
        Kevin Tian <kevin.tian@intel.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Logan Gunthorpe <logang@deltatee.com>,
        Ashok Raj <ashok.raj@intel.com>, Jon Mason <jdmason@kudzu.us>,
        Allen Hubbe <allenbh@gmail.com>,
        "Ahmed S. Darwish" <darwi@linutronix.de>,
        Reinette Chatre <reinette.chatre@intel.com>
Subject: Re: [patch 02/33] genirq/msi: Provide struct msi_parent_ops
Message-ID: <Y3Uynk6brtNVFUH7@nvidia.com>
References: <20221111133158.196269823@linutronix.de>
 <20221111135205.368911521@linutronix.de>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221111135205.368911521@linutronix.de>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xHTEXpAQ4W/LnMqWZLIhzXViZu5ByC0F20TdGoZJYtETKgU1S/TPLFEGuQp2?=
 =?us-ascii?Q?CoMCbsB9Q0pHqYrkajgEDNdSXhcgW05yRUdlso7AEjRf2cGAr8n3sznnDn/g?=
 =?us-ascii?Q?oDryC/sZrdcOhm2h7wz5HAuLVHUZwmrLMfAinudLO5qlVb8Xjvrx3UDBGnOB?=
 =?us-ascii?Q?QfIokxBggvQR3vF+/bz/6jXjk6qY+DCE0+iItmjWAjSCnw7+gL70FNj+llkE?=
 =?us-ascii?Q?Ck6DJvQnjzPGdWgbtMTnrGbSYmoGyaMDoXqXI/1GdWIIOz/Co8h2bYGiyZbJ?=
 =?us-ascii?Q?FxtrC+XiAWGE+Jx3I8unzRc5csdN2xYNaDE+36qeOwIvsvkMhqe5xaiv7Prg?=
 =?us-ascii?Q?LUqWPBUyqda1N3YKpBqsVdYuwvAIoCJ4mwBDwGpO2vg/5RGCXpnMzSbVAB3C?=
 =?us-ascii?Q?In919kIpbTnx+0Lxw8IdtjptErkeZX7XEYmN8Sf/73tSpT98xcyr+0iT3Dcy?=
 =?us-ascii?Q?G+yPXebGTgNxWzDJSaGeP4FNKXfrxIAfuKAnji1W5ZS2O7ViAsXrT2egcRxh?=
 =?us-ascii?Q?yO9Nv0VclzOij2S3IAvNznkqqZDeCM2pkFxgt4Rn2tq7UJC+3hHe19hGmsO2?=
 =?us-ascii?Q?OeHL9fG7qN+2xxSPa7QwZhVF7QBjg3rxYKwqHQOS5ghums9ZWU1uA6fbBn1l?=
 =?us-ascii?Q?pVfZoZTzut9AcbEaeM9aESCQcGVq9Q7hGcjbiNC94SJjxMqOoDAcxI3RrTmP?=
 =?us-ascii?Q?LXI+mJzo5ezHitrSh+ElTKC0U0bnFikmSdUy8KZOR6mhP9gMpmPbsDVOgO3C?=
 =?us-ascii?Q?mJPIqxqgEmhczCkrV9XPN0X9lMkZPbGnIcNNYb8blKTvXs7fWFe8hnIeB0og?=
 =?us-ascii?Q?x0rk6ENtLiqbOXcBSyaOGMQr3SkNimSiS6BPimRu9nHZ6cE2PlQg5H7CH4Vz?=
 =?us-ascii?Q?DaZnuLkjA/wH+6AcNyRZkWxzhnEAqcDw5CX0I43JClwdFs7wsYpO9SS2nunS?=
 =?us-ascii?Q?2N0cGu0TGjP4rwdp55lmT0gJ/VFiMJiCsguO5E7m2rXw7Uj1r1zaM+486Chp?=
 =?us-ascii?Q?sPuExPuPVTaFWQ2AWqvDN435qdrhyO3KMtCO3IzpToSM46uPnu/aYfNq6kso?=
 =?us-ascii?Q?CX5h9PMIIw3OEk8JNrn61/O5vQoVjBzFNYQBRyZBb+s5/oATS3d/Ta9Tzo3G?=
 =?us-ascii?Q?5r/oV7tzpyT66P4ZNfnD67a8ZE2u6iAFT3mucmSdyWWSx4eUMp0F38KYV7X2?=
 =?us-ascii?Q?MvhrA5aQ3wFbEyaOQHEtHegByohxJzC17NWKm7YIVMCeQCJ0/u+MRNCvo3yJ?=
 =?us-ascii?Q?UeCv/7AG+0goZ7fwI7xz3pTuNdBJsOhdLAoOo36fZl3yZ4uUSvZkugvMpdej?=
 =?us-ascii?Q?pu6iyAKY9L7ZvS5z7ajWh+1KqlfZGss91/1KS7e+HmAYVakXWol3L99dtNIb?=
 =?us-ascii?Q?CoS6jEnHxBOAIVlqRFh6iBLlftcTmF6OGQoCnB1X/UZ4TB4rwiRHUVqbe49d?=
 =?us-ascii?Q?tsil1v2Y8kLSlzYZpust1kLIsCLHbEV+LsH6GrHEGQxDvprZqp2Wlkzy8lBN?=
 =?us-ascii?Q?xeMT4cJqKMpQY1Dm25x+ayJquQeVqlVQwFEb9Y61eLoLDQF1i6Hxw9jkVBmt?=
 =?us-ascii?Q?7jTq1hDIWBSwBXr7XW5Z+FtuYuOyrSJVAvv6bP0a?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5eba28e3-a699-4eb0-f905-08dac8046d6a
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2022 18:57:37.1247
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: +e1CNq28ZGN2cWwJ9MQZx380cKh22MQ5RgWyVirTXEGFKNOGpOUnRSbxq7aXzwJQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5853
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE
        autolearn=no 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

On Fri, Nov 11, 2022 at 02:58:14PM +0100, Thomas Gleixner wrote:
> +/**
> + * msi_parent_init_dev_msi_info - Delegate initialization of device MSI info to parent domain
> + * @dev:		The device for which the domain should be created
> + * @domain:		The domain which delegates
> + * @real_parent:	The real parent domain of the to be initialized MSI domain
> + * @info:		The MSI domain info to initialize
> + *
> + * Return: true on success, false otherwise
> + *
> + * 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 :)

> +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?

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

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?

Jason