[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241030221737.GA1223682@bhelgaas>
Date: Wed, 30 Oct 2024 17:17:37 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Philipp Stanner <pstanner@...hat.com>
Cc: 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>,
Ricky Wu <ricky_wu@...ltek.com>, Al Viro <viro@...iv.linux.org.uk>,
Breno Leitao <leitao@...ian.org>, Kevin Tian <kevin.tian@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
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>, 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 00/13] Remove implicit devres from pci_intx()
On Tue, Oct 15, 2024 at 08:51:10PM +0200, Philipp Stanner wrote:
> @Driver-Maintainers: Your driver might be touched by patch "Remove
> devres from pci_intx()". You might want to take a look.
>
> Changes since the RFC [1]:
> - Add a patch deprecating pci{m}_intx(). (Heiner, Andy, Me)
> - Add Acked-by's already given.
> - Export pcim_intx() as a GPL function. (Alex)
> - Drop patch for rts5280, since this driver will be removed quite
> soon. (Philipp Hortmann, Greg)
> - Use early-return in pci_intx_unmanaged() and pci_intx(). (Andy)
>
> Hi all,
>
> this series removes a problematic feature from pci_intx(). That function
> sometimes implicitly uses devres for automatic cleanup. We should get
> rid of this implicit behavior.
>
> To do so, a pci_intx() version that is always-managed, and one that is
> never-managed are provided. Then, all pci_intx() users are ported to the
> version they need. Afterwards, pci_intx() can be cleaned up and the
> users of the never-managed version be ported back to pci_intx().
>
> This way we'd get this PCI API consistent again.
>
> Patch "Remove devres from pci_intx()" obviously reverts the previous
> patches that made drivers use pci_intx_unmanaged(). But this way it's
> easier to review and approve. It also makes sure that each checked out
> commit should provide correct behavior, not just the entire series as a
> whole.
>
> Merge plan for this is to enter through the PCI tree.
>
> [1] https://lore.kernel.org/all/20241009083519.10088-1-pstanner@redhat.com/
I *think* this series depends on resolution of Takashi's "Restore the
original INTX_DISABLE bit by pcim_intx()" patch [2], right?
For now I'm postponing this series, but let me know if that's not the
right thing.
[2] https://lore.kernel.org/r/20241024155539.19416-1-tiwai@suse.de
> Philipp Stanner (13):
> PCI: Prepare removing devres from pci_intx()
> ALSA: hda_intel: Use always-managed version of pcim_intx()
> drivers/xen: Use never-managed version of pci_intx()
> net/ethernet: Use never-managed version of pci_intx()
> net/ntb: Use never-managed version of pci_intx()
> misc: Use never-managed version of pci_intx()
> vfio/pci: Use never-managed version of pci_intx()
> PCI: MSI: Use never-managed version of pci_intx()
> ata: Use always-managed version of pci_intx()
> wifi: qtnfmac: use always-managed version of pcim_intx()
> HID: amd_sfh: Use always-managed version of pcim_intx()
> Remove devres from pci_intx()
> PCI: Deprecate pci_intx(), pcim_intx()
>
> drivers/ata/ahci.c | 2 +-
> drivers/ata/ata_piix.c | 2 +-
> drivers/ata/pata_rdc.c | 2 +-
> drivers/ata/sata_sil24.c | 2 +-
> drivers/ata/sata_sis.c | 2 +-
> drivers/ata/sata_uli.c | 2 +-
> drivers/ata/sata_vsc.c | 2 +-
> drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 4 +--
> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_init.c | 2 +-
> .../wireless/quantenna/qtnfmac/pcie/pcie.c | 2 +-
> drivers/pci/devres.c | 29 +++++--------------
> drivers/pci/pci.c | 19 ++++--------
> include/linux/pci.h | 1 +
> sound/pci/hda/hda_intel.c | 2 +-
> 14 files changed, 26 insertions(+), 47 deletions(-)
>
> --
> 2.47.0
>
Powered by blists - more mailing lists