On Wed, 27 Aug 2025, Bjorn Helgaas wrote: > On Fri, Aug 22, 2025 at 05:55:41PM +0300, Ilpo Järvinen wrote: > > This series is based on top of the three resource fitting and > > assignment algorithm fixes (v3). > > > > PCI resource fitting and assignment code needs to find the bridge > > window a resource belongs to in multiple places, yet, no common > > function for that exists. Thus, each site has its own version of > > the decision, each with their own corner cases, misbehaviors, and > > some resulting in complex interfaces between internal functions. > > ... > > > I've tried to look out for any trouble that code under arch/ could > > cause after the flags start to behave differently and therefore ended > > up consolidating arch/ code to use pci_enable_resources(). My > > impression is that strictly speaking only the MIPS code would break > > similar to PCI core's copy of pci_enable_resources(), the others were > > much more lax in checking so they'd likely keep working but > > consolidation seemed still the best approach there as the enable checks > > seemed diverging for no apparent reason. > > ... > > > m68k/PCI: Use pci_enable_resources() in pcibios_enable_device() > > sparc/PCI: Remove pcibios_enable_device() as they do nothing extra > > MIPS: PCI: Use pci_enable_resources() > > ... > > > arch/m68k/kernel/pcibios.c | 39 +- > > arch/mips/pci/pci-legacy.c | 38 +- > > arch/sparc/kernel/leon_pci.c | 27 -- > > arch/sparc/kernel/pci.c | 27 -- > > arch/sparc/kernel/pcic.c | 27 -- > > ... > > I love the fact that you're doing so much cleanup. Thanks for all the > work in this! > > Obviously all this code is quite sensitive, so I put it on > pci/resource to get more exposure in -next.
Thanks. I really appreciate the opportunity to have it in next for extra testing as my testing, while relatively extensive, still has its limits. I'll need to do minor corrections into a few intermediate patches though to ensure bisectability, we really want to make this as bisectable as possible. In other words, I've found 2 relatively small issues in them which won't change the end result when the whole series is complete and fixed some small grammar errors in the changelogs. I see you made some corrections so I'm not sure what's the best course of action here to update them. Should I just send v2 normally and you deal with your changes while replacing v1 with v2? > If it turns out that we > trip over things or just don't feel comfortable yet for v6.18, we can > always defer this part until the next cycle. I agree, and really please don't hesitate to postpone if it turns out necessary. > I will also watch for acks from the m68k, mips, and sparc maintainers > for those pieces. > > Bjorn > -- i.
