[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMuHMdUqKT4OaX6P_1CW_e2U1GwiCmyV5sAoDVa7EWUX2r6SsA@mail.gmail.com>
Date: Mon, 1 Sep 2025 10:38:57 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Andreas Larsson <andreas@...sler.com>, Bjorn Helgaas <bhelgaas@...gle.com>,
"David S. Miller" <davem@...emloft.net>, linux-m68k@...ts.linux-m68k.org,
linux-mips@...r.kernel.org, linux-pci@...r.kernel.org,
sparclinux@...r.kernel.org, Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Christian König <christian.koenig@....com>,
Yinghai Lu <yinghai@...nel.org>, Igor Mammedov <imammedo@...hat.com>,
"Rafael J . Wysocki" <rafael@...nel.org>, Jonathan Cameron <Jonathan.Cameron@...wei.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>, Krzysztof Wilczyński <kw@...ux.com>,
linux-kernel@...r.kernel.org,
Michał Winiarski <michal.winiarski@...el.com>,
linuxppc-dev@...ts.ozlabs.org, Greg Ungerer <gerg@...ux-m68k.org>
Subject: Re: [PATCH 00/24] PCI: Bridge window selection improvements
CC Greg
On Thu, 28 Aug 2025 at 00:36, Bjorn Helgaas <helgaas@...nel.org> 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. 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 will also watch for acks from the m68k, mips, and sparc maintainers
> for those pieces.
Powered by blists - more mailing lists