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 13:42:22 -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>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Christophe Leroy <christophe.leroy@csgroup.eu>,
        linuxppc-dev@lists.ozlabs.org
Subject: Re: [patch 30/39] PCI/MSI: Move pci_msi_restore_state() to api.c
Message-ID: <Y3Ug/vWnDWBfKw1l@nvidia.com>
References: <20221111120501.026511281@linutronix.de>
 <20221111122015.331584998@linutronix.de>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221111122015.331584998@linutronix.de>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?TJedsFT2JeQQYxp1tRBULefV1Cbvo+8UEJ0ptxX+R3p266s78JV0eoFZ4Kcx?=
 =?us-ascii?Q?nAPLAsbY9c81KS50BBH/Jt5mYaToN/RWNN3+p4kDft3Q0f1sZ0IxCqL1+hJK?=
 =?us-ascii?Q?qDBIGCQsjo3nSnKSInRuR++Z6v3bxKQ4aQsq/HmuYv5vew7oBPiEmjfZHpvq?=
 =?us-ascii?Q?bpFcFT2uafopY6fiX7IZwk3Q8tav6UbIZdnXnFB2tXriVGL9ZpN+1ZZzZIlP?=
 =?us-ascii?Q?CA3f26kwu8ydKC6iByJbOPfro2gb7nE8jYLfXOcJMlSWdBSVkXyNKZX1EETZ?=
 =?us-ascii?Q?BqLKRSIZtGJBi+aKjbi85Dn9ESKuEdUcl8MCC1mODpPkozypRprLhYFt8W/D?=
 =?us-ascii?Q?l4aeJL/5LJgma+O6a/3BOHjH09kh2Lt1DS2z4cxq5APJnm06bpYx8T8CALDD?=
 =?us-ascii?Q?TEyDr1fkts3HDlkzeT9l4NR80YEMKB1O2jsJyFHSw8hVftl7FQhbUI9UMiLX?=
 =?us-ascii?Q?pKeXFiuljX4QKET7fAphj6eGTcdcvlZ/RlzA5LjKwrztHrYiaaLTIyf7zobs?=
 =?us-ascii?Q?766iSRVnN4ya6yKYvJ+cR19xcD3VeCE5Mr4ZWEA54zlf3nJP6jrkBdN8rtMu?=
 =?us-ascii?Q?y0WDQf4333sMzm/t0FuTLHqmhc/wYxLVA9n5TjuSs9RuzGeWJLEu7zmXRCau?=
 =?us-ascii?Q?QK9adZI8QdtQEPYLu7oXqsodMp5fnlm3+0Ywp/1byikhjOBPBTH3GEgTPkbi?=
 =?us-ascii?Q?N2r2R5tHVrbP9DHVu7dFBCZN/Mu0dV5hjvqHwen46uU6OBpqHk1Y0IGSIdY4?=
 =?us-ascii?Q?PC2OV0m1gJvtp7zWwuYSin0LcGWCskhzQJNT+lcMNC0/uU0SwUTAkGjwbdjW?=
 =?us-ascii?Q?HUIEr3AP3cKEwxl3wfwo6+/fUKdgeUPsEN2dwE8R4JbjKa+pSbEkftRWMNEI?=
 =?us-ascii?Q?A5LHovz1uQVYuY98ey4Y7xMRLCitRKrlz15l8cdfbBdcNR2FvczLRlAlN5kp?=
 =?us-ascii?Q?n1PSai6qNP/0i1RikNtOJSH2MrajFElfr42DgGLLMEsM5ZQ5+gFWH3cbi4E4?=
 =?us-ascii?Q?pl7SG8mvVvO1IIskQ0gfr5nqzFpNHaTD+YqtfO6ka7VhGMeFNc1NQXOJwwBX?=
 =?us-ascii?Q?u6ziHRFECyb79+VShncYw3imX14iMh7nOcEtBmV/ExhBIKo+YkYxmzr0jlt0?=
 =?us-ascii?Q?ZJ6p7rfUllf9T75pst9NM1C9Z80FtNmj9Y5OIIwq2QEpEDan3ncsR7Yoe/Z6?=
 =?us-ascii?Q?iX0bvSIqfO6sIKljoI9ojm5TTi/mEq4zhzL+0IjTtYRe5Afl3D7VN2HgPWJx?=
 =?us-ascii?Q?xCz/jh7Dw9psmcm+zahwGw71ZDFGec7dp98zhalx1c4aV9g2PDNnHXlCoW3j?=
 =?us-ascii?Q?PKBwQ58fawoTojptgCWZXcRXgIhnrriUdS8WTRhG89gwPif6tcHTPohb++cn?=
 =?us-ascii?Q?mt6hTErmuRzeXOByEBNQMMjUctJtZhuOnfU2apmvJHQ1xP64K2Ffy/abg+C0?=
 =?us-ascii?Q?dGgLdU7/bkl8nPvMkjMzDlx+VhSxvk+MX8a5nSvWm5IKGj45r9IBgVDdQ9aW?=
 =?us-ascii?Q?iV4G0zwcBaup9Kcmhlabm8UlpYyYzWp5eJwfCeLp3TzF6PL2OYQ9OcVHNwZF?=
 =?us-ascii?Q?SXrURTyF1UHpxGY7GAoosVHl/S+NPDR3OZ6sKsoM?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ca37360-7821-46a5-35c5-08dac7f9eb9d
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2022 17:42:25.7432
 (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: YDAHiW4v/sO5pR3Bn9gorKUyfaCLFnXL3at4gtKrxjMKKWhiJN1TGWVnneyfnQyp
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR12MB6268
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:55:03PM +0100, Thomas Gleixner wrote:
> From: Ahmed S. Darwish <darwi@linutronix.de>
>     
> To distangle the maze in msi.c, all exported device-driver MSI APIs are
> now to be grouped in one file, api.c.
>     
> Move pci_msi_enabled() and add kernel-doc for the function.
>     
> Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> diff --git a/drivers/pci/msi/api.c b/drivers/pci/msi/api.c
> index ee9ed5ccd94d..8d1cf6db9bd7 100644
> --- a/drivers/pci/msi/api.c
> +++ b/drivers/pci/msi/api.c
> @@ -308,6 +308,21 @@ void pci_free_irq_vectors(struct pci_dev *dev)
>  }
>  EXPORT_SYMBOL(pci_free_irq_vectors);
>  
> +/**
> + * pci_restore_msi_state() - Restore cached MSI(-X) state on device
> + * @dev: the PCI device to operate on
> + *
> + * Write the Linux-cached MSI(-X) state back on device. This is
> + * typically useful upon system resume, or after an error-recovery PCI
> + * adapter reset.
> + */
> +void pci_restore_msi_state(struct pci_dev *dev)
> +{
> +	__pci_restore_msi_state(dev);
> +	__pci_restore_msix_state(dev);
> +}
> +EXPORT_SYMBOL_GPL(pci_restore_msi_state);

This leaves behind two functions that are only called from here.

I think they should be moved into this file as well.

Or perhaps more broadly, it would make sense if the functions
were split up into 'for irq chip implementors' 'for drivers' and
'shared utilities'.

There are several other examples, like
__pci_enable_msix_range()/__pci_enable_msi_range() that are only used
by api.c and could reasonably move as well, plus their tree of
single-use support functions.

And if you think about it that way - things have ended up so that
api.c is really all about vector allocation (as that is the only thing
the drivers actually do) so it would be tempting to call it
allocator.c and consolidate everything in that topic.

Jason