Re: [PATCH 01/37] PCI/MSI: Add Devres managed IRQ vectors allocation

Philipp Stanner <[email protected]> Tue, 24 Feb 2026 09:32:39 +0100
Newsgroups dev.linux.lists.mhi,dev.linux.lists.iommu,org.freedesktop.lists.dri-devel,org.infradead.lists.linux-i3c,org.infradead.lists.linux-riscv,org.kernel.vger.dmaengine,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-cxl,org.kernel.vger.linux-gpio,org.kernel.vger.linux-i2c,org.kernel.vger.linux-input,org.kernel.vger.linux-media,org.kernel.vger.linux-mmc,org.kernel.vger.linux-pci,org.kernel.vger.linux-serial,org.kernel.vger.linux-spi,org.kernel.vger.linux-usb,org.kernel.vger.netdev,org.kernel.vger.platform-driver-x86
Message-ID <[email protected]>
On Tue, 2026-02-24 at 16:21 +0800, Shawn Lin wrote:
> 在 2026/02/24 星期二 15:47, Philipp Stanner 写道:
> > On Tue, 2026-02-24 at 10:08 +0800, Shawn Lin wrote:
> > > 在 2026/02/24 星期二 8:04, Jakub Kicinski 写道:
> > > > On Mon, 23 Feb 2026 23:29:40 +0800 Shawn Lin wrote:
> > > > > pcim_alloc_irq_vectors() and pcim_alloc_irq_vectors_affinity() are created for
> > > > > pci device drivers which rely on the devres machinery to help cleanup the IRQ
> > > > > vectors.
> > > > 
> > > > If you can please add this API with just a few users, and then convert
> > > > remaining users via the subsystem trees in the next cycle.
> > > > There's no need to risk wasting maintainer time on conflicts with
> > > > conversions like this.
> > > 
> > > Thanks for the suggestion, Jakub. I have little experience with
> > > cross-subsystem cleanups like this, so your suggestion is very helpful.
> > 
> > 
> > When I removed the hybrid nature of pci_request_region() et al., I
> > concluded that there were so few users that doing them all in one run
> > was sufficient.
> > 
> > For larger reworks, like removing pcim_iomap_table(), a slower step-by-
> > step strategy is necessary for the reasons that Jakub details.
> > 
> > It is then smart to omit an easy to port subsystem / driver for the
> > ultimate patch series where one then removes the hybrid behavior from
> > PCI itself, after porting the last driver.
> > 
> > In general,  as Jakub details, those step-by-step cleanups are a bit
> > safer, since you can proof valid behavior early on and in case of an
> > explosion they are very easy to revert.
> > 
> 
> Thank you, Philipp. I wish I had attended your talk at FOSDEM 2025 on
> removing pcim_iomap_table earlier. This first version was perhaps a bit 
> too aggressive.

No worries at all, it's very cool that you pick this work up!

>  For v2, I think the plan should start with addressing
> the switchtec and vmd drivers, since both of those, along with the new 
> API additions, can be handled entirely within the PCI subsystem scope.

Sounds reasonable to me.

Regards
Philipp