[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87plmzktn3.ffs@tglx>
Date: Wed, 13 Nov 2024 17:04:00 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Philipp Stanner <pstanner@...hat.com>, Damien Le Moal
<dlemoal@...nel.org>, Niklas Cassel <cassel@...nel.org>, 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>, Andrew Lunn <andrew+netdev@...n.ch>, "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>, Philipp Stanner <pstanner@...hat.com>,
Mario Limonciello <mario.limonciello@....com>, Chen Ni
<nichen@...as.ac.cn>, Ricky Wu <ricky_wu@...ltek.com>, Al Viro
<viro@...iv.linux.org.uk>, Breno Leitao <leitao@...ian.org>, Kevin Tian
<kevin.tian@...el.com>, Mostafa Saleh <smostafa@...gle.com>, Andy
Shevchenko <andriy.shevchenko@...ux.intel.com>, Jason Gunthorpe
<jgg@...pe.ca>, Yi Liu <yi.l.liu@...el.com>, Kunwu Chan
<chentao@...inos.cn>, Ankit Agrawal <ankita@...dia.com>, Christian Brauner
<brauner@...nel.org>, Reinette Chatre <reinette.chatre@...el.com>, Eric
Auger <eric.auger@...hat.com>, Ye Bin <yebin10@...wei.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
Subject: Re: [PATCH v2 01/11] PCI: Prepare removing devres from pci_intx()
On Wed, Nov 13 2024 at 13:41, Philipp Stanner wrote:
> +/**
> + * pci_intx_unmanaged - enables/disables PCI INTx for device dev,
> + * unmanaged version
> + * @pdev: the PCI device to operate on
> + * @enable: boolean: whether to enable or disable PCI INTx
Except that the argument is of type int, which really should be type bool.
> + * Enables/disables PCI INTx for device @pdev
> + *
> + * This function behavios identically to pci_intx(), but is never managed with
> + * devres.
behavios?
> + */
> +void pci_intx_unmanaged(struct pci_dev *pdev, int enable)
I find this function name mildy confusing. This _unmanaged suffix is not
really telling me anything. And the reference that this behaves
identically to pci_intx() makes it even worse.
This function is about controlling the PCI INTX_DISABLE bit in the
PCI_COMMAND config word, right?
So naming it pci_intx_control() would make it entirely clear what this
is about, no?
Thanks,
tglx
Powered by blists - more mailing lists