mbox series

[0/2] PCI: Remove pcim_iounmap_regions()

Message ID 20250327110707.20025-2-phasta@kernel.org (mailing list archive)
Headers show
Series PCI: Remove pcim_iounmap_regions() | expand

Message

Philipp Stanner March 27, 2025, 11:07 a.m. UTC
The last remaining user of pcim_iounmap_regions() is mtip32 (in Linus's
current master)

So we could finally remove this deprecated API. I suggest that this gets
merged through the PCI tree. (I also suggest we watch with an eagle's
eyes for folks who want to re-add calls to that function before the next
merge window opens).

P.

Philipp Stanner (2):
  mtip32xx: Remove unnecessary PCI function calls
  PCI: Remove pcim_iounmap_regions()

 .../driver-api/driver-model/devres.rst        |  1 -
 drivers/block/mtip32xx/mtip32xx.c             |  7 ++----
 drivers/pci/devres.c                          | 24 -------------------
 include/linux/pci.h                           |  1 -
 4 files changed, 2 insertions(+), 31 deletions(-)

Comments

Andy Shevchenko March 27, 2025, 11:42 a.m. UTC | #1
On Thu, Mar 27, 2025 at 12:07:06PM +0100, Philipp Stanner wrote:
> The last remaining user of pcim_iounmap_regions() is mtip32 (in Linus's
> current master)
> 
> So we could finally remove this deprecated API. I suggest that this gets
> merged through the PCI tree.

Good god! One API less, +1 to support this move.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

> (I also suggest we watch with an eagle's
> eyes for folks who want to re-add calls to that function before the next
> merge window opens).

Instead of this I suggest that PCI can take this before merge window finishes
and cooks the (second) PR with it. In such a case we wouldn't need to care,
the developers will got broken builds.
Philipp Stanner April 2, 2025, 7:58 a.m. UTC | #2
On Thu, 2025-03-27 at 13:42 +0200, Andy Shevchenko wrote:
> On Thu, Mar 27, 2025 at 12:07:06PM +0100, Philipp Stanner wrote:
> > The last remaining user of pcim_iounmap_regions() is mtip32 (in
> > Linus's
> > current master)
> > 
> > So we could finally remove this deprecated API. I suggest that this
> > gets
> > merged through the PCI tree.
> 
> Good god! One API less, +1 to support this move.
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> > (I also suggest we watch with an eagle's
> > eyes for folks who want to re-add calls to that function before the
> > next
> > merge window opens).
> 
> Instead of this I suggest that PCI can take this before merge window
> finishes
> and cooks the (second) PR with it. In such a case we wouldn't need to
> care,
> the developers will got broken builds.
> 

Normally Bjorn / PCI lets changes settle on a branch for >1 week before
throwing them at mainline – but if we ask him very very nicely, maybe
he would make an exception for this special case? :)

P.
Jonathan Cameron April 2, 2025, 1:53 p.m. UTC | #3
On Wed, 02 Apr 2025 09:58:24 +0200
Philipp Stanner <pstanner@redhat.com> wrote:

> On Thu, 2025-03-27 at 13:42 +0200, Andy Shevchenko wrote:
> > On Thu, Mar 27, 2025 at 12:07:06PM +0100, Philipp Stanner wrote:  
> > > The last remaining user of pcim_iounmap_regions() is mtip32 (in
> > > Linus's
> > > current master)
> > > 
> > > So we could finally remove this deprecated API. I suggest that this
> > > gets
> > > merged through the PCI tree.  
> > 
> > Good god! One API less, +1 to support this move.
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >   
> > > (I also suggest we watch with an eagle's
> > > eyes for folks who want to re-add calls to that function before the
> > > next
> > > merge window opens).  
> > 
> > Instead of this I suggest that PCI can take this before merge window
> > finishes
> > and cooks the (second) PR with it. In such a case we wouldn't need to
> > care,
> > the developers will got broken builds.
> >   
> 
> Normally Bjorn / PCI lets changes settle on a branch for >1 week before
> throwing them at mainline – but if we ask him very very nicely, maybe
> he would make an exception for this special case? :)
> 
linux-next should deal with any new users anyway so I wouldn't worry
about it.  Anyone who still has trees destined for the next merge window
that aren't in next gets to deal with Linus being very grumpy at them.

Jonathan

> P.
> 
> 
>