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