Re: [PATCH 00/24] PCI: Bridge window selection improvements

On Wed, 27 Aug 2025, Bjorn Helgaas wrote:

On Fri, Aug 22, 2025 at 05:55:41PM +0300, Ilpo Järvinen wrote:

quoted

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.
...

quoted

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.
...

quoted

  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()
...

quoted

 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.