[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87cyjgwfmo.ffs@tglx>
Date: Thu, 31 Oct 2024 14:45:03 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Philipp Stanner <pstanner@...hat.com>, Damien Le Moal
<dlemoal@...nel.org>, Niklas Cassel <cassel@...nel.org>, Sergey Shtylyov
<s.shtylyov@....ru>, Basavaraj Natikar <basavaraj.natikar@....com>, Jiri
Kosina <jikos@...nel.org>, Benjamin Tissoires <bentiss@...nel.org>, Arnd
Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alex Dubov <oakad@...oo.com>, Sudarsana Kalluru <skalluru@...vell.com>,
Manish Chopra <manishc@...vell.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rasesh Mody
<rmody@...vell.com>, GR-Linux-NIC-Dev@...vell.com, Igor Mitsyanko
<imitsyanko@...ntenna.com>, Sergey Matyukevich <geomatsi@...il.com>, Kalle
Valo <kvalo@...nel.org>, Sanjay R Mehta <sanju.mehta@....com>, Shyam
Sundar S K <Shyam-sundar.S-k@....com>, Jon Mason <jdmason@...zu.us>, Dave
Jiang <dave.jiang@...el.com>, Allen Hubbe <allenbh@...il.com>, Bjorn
Helgaas <bhelgaas@...gle.com>, Alex Williamson
<alex.williamson@...hat.com>, Juergen Gross <jgross@...e.com>, Stefano
Stabellini <sstabellini@...nel.org>, Oleksandr Tyshchenko
<oleksandr_tyshchenko@...m.com>, Jaroslav Kysela <perex@...ex.cz>, Takashi
Iwai <tiwai@...e.com>, Chen Ni <nichen@...as.ac.cn>, Mario Limonciello
<mario.limonciello@....com>, Philipp Stanner <pstanner@...hat.com>, Ricky
Wu <ricky_wu@...ltek.com>, Al Viro <viro@...iv.linux.org.uk>, Breno Leitao
<leitao@...ian.org>, Kevin Tian <kevin.tian@...el.com>, Ilpo Järvinen
<ilpo.jarvinen@...ux.intel.com>, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, Mostafa Saleh <smostafa@...gle.com>,
Jason Gunthorpe <jgg@...pe.ca>, Yi Liu <yi.l.liu@...el.com>, Christian
Brauner <brauner@...nel.org>, Ankit Agrawal <ankita@...dia.com>, Eric
Auger <eric.auger@...hat.com>, Reinette Chatre
<reinette.chatre@...el.com>, Ye Bin <yebin10@...wei.com>, Marek
Marczykowski-Górecki <marmarek@...isiblethingslab.com>,
Pierre-Louis
Bossart <pierre-louis.bossart@...ux.dev>, Peter Ujfalusi
<peter.ujfalusi@...ux.intel.com>, Maarten Lankhorst
<maarten.lankhorst@...ux.intel.com>, Kai Vehmanen
<kai.vehmanen@...ux.intel.com>, Rui Salvaterra <rsalvaterra@...il.com>
Cc: linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-input@...r.kernel.org, netdev@...r.kernel.org,
linux-wireless@...r.kernel.org, ntb@...ts.linux.dev,
linux-pci@...r.kernel.org, kvm@...r.kernel.org,
xen-devel@...ts.xenproject.org, linux-sound@...r.kernel.org
Subject: Re: [PATCH 01/13] PCI: Prepare removing devres from pci_intx()
On Tue, Oct 15 2024 at 20:51, Philipp Stanner wrote:
> +/**
> + * pci_intx - enables/disables PCI INTx for device dev, unmanaged version
mismatch vs. actual function name.
> + * @pdev: the PCI device to operate on
> + * @enable: boolean: whether to enable or disable PCI INTx
> + *
> + * Enables/disables PCI INTx for device @pdev
> + *
> + * This function behavios identically to pci_intx(), but is never managed with
> + * devres.
> + */
> +void pci_intx_unmanaged(struct pci_dev *pdev, int enable)
This is a misnomer. The function controls the INTX_DISABLE bit of a
PCI device. Something like this:
void __pci_intx_control()
{
}
static inline void pci_intx_enable(d)
{
__pci_intx_control(d, true);
}
.....
makes it entirely clear what this is about.
Hmm?
Thanks,
tglx
Powered by blists - more mailing lists