From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Guenter Roeck <linux@roeck-us.net>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 03/24] MIPS: PCI: Use pci_enable_resources()
Date: Tue, 14 Oct 2025 15:41:42 +0300 (EEST) [thread overview]
Message-ID: <9f80ba5e-726b-ad68-b71f-ab23470bfa36@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2510141232400.39634@angie.orcam.me.uk>
[-- Attachment #1: Type: text/plain, Size: 3121 bytes --]
On Tue, 14 Oct 2025, Maciej W. Rozycki wrote:
> On Tue, 14 Oct 2025, Ilpo Järvinen wrote:
>
> > > As you can see there are holes in the map below 0x100, so e.g. if the bus
> > > master IDE I/O space registers (claimed last in the list by `ata_piix')
> > > were assigned to 00000030-0000003f, then all hell would break loose. It
> > > is exactly the mapping that happened in the absence of the code piece in
> > > question IIRC.
> >
> > Are you sure pci-malta.c has to do anything like this as
> > pcibios_align_resource() does lower bound IO resource start addresses if
> > PCIBIOS_MIN_IO is set?
>
> Well, PCIBIOS_MIN_IO is never set for Malta and therefore stays at 0.
I meant whether pci-malta.c has to play with the ->start address at all
if it would use PCIBIOS_MIN_IO.
> I could boot 2.6.11 with the hunk reverted and see what happens, not a big
> deal (I should have old GCC somewhere as a kernel such old would surely be
> a pain to build with modern GCC). This stuff was badly broken before
> commit ae81aad5c2e1 (and there was support there too for the Atlas board,
> a weird one with a Philips SAA9730 southbridge and supporting a subset of
> the same CPU core cards as the Malta board does).
>
> > How about this patch below?
> >
> > (I'm not sure if it should actually be
> > PCIBIOS_MIN_IO = 0x1000 - hose->io_resource->start;
> > to allow resources starting from 0x1000 if ->start is not at 0.)
>
> I'd have to go through the relevant datasheets to see whether it can
> actually happen in reality. Perhaps we can just hardwire PCIBIOS_MIN_IO
> to 0x1000 instead, similarly to what other MIPS platforms do.
My patch did hardcode set it to 0x1000, I just noted before the patch that
I'm not sure if the code should actually try to align the resulting "real
start address" to 0x1000 if hose->io_resource->start != 0.
Or are you saying also the the if () check should be removed as well?
> After all
> Malta's southbridge is on the mainboard and therefore always the same,
> regardless of the northbridge (system controller in MIPS-speak) which
> comes with the pluggable CPU core card.
>
> NB there are commit c5de50dada14 ("MIPS: Malta: Change start address to
> avoid conflicts.") and commit 27547abf36af ("MIPS: malta: Incorporate
> PIIX4 ACPI I/O region in PCI controller resources") that fiddled with this
> code piece. Especially the latter one refers additional commits that may
> give further insights. And the former one removed a "FIXME" annotation,
> which suggests I didn't consider the solution perfect back 20 years ago,
> but given how long it stayed there it was surely good enough for its time.
It was "good enough" only because the arch specific
pcibios_enable_resources() was lacking the check for whether the resource
truly got assigned or not. The PIIX4 driver must worked just fine without
those IO resources which is what most drivers do despite using
pci(m)_enable_device() and not pci_enable_device_mem() (the latter
doesn't even seem to come with m variant).
--
i.
next prev parent reply other threads:[~2025-10-14 12:41 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-29 13:10 [PATCH v2 00/24] PCI: Bridge window selection improvements Ilpo Järvinen
2025-08-29 13:10 ` [PATCH v2 01/24] m68k/PCI: Use pci_enable_resources() in pcibios_enable_device() Ilpo Järvinen
2025-08-29 13:10 ` [PATCH v2 02/24] sparc/PCI: Remove pcibios_enable_device() as they do nothing extra Ilpo Järvinen
2025-08-29 13:10 ` [PATCH v2 03/24] MIPS: PCI: Use pci_enable_resources() Ilpo Järvinen
2025-10-13 19:54 ` Guenter Roeck
2025-10-13 21:02 ` Bjorn Helgaas
2025-10-28 22:45 ` Bjorn Helgaas
2025-10-13 21:17 ` Thomas Bogendoerfer
2025-10-13 23:00 ` Maciej W. Rozycki
2025-10-14 10:54 ` Ilpo Järvinen
2025-10-14 12:22 ` Maciej W. Rozycki
2025-10-14 12:41 ` Ilpo Järvinen [this message]
2025-10-14 12:58 ` Maciej W. Rozycki
2025-10-17 10:49 ` Thomas Bogendoerfer
2025-10-17 10:58 ` Ilpo Järvinen
2025-10-17 12:11 ` Thomas Bogendoerfer
2025-10-18 21:32 ` Maciej W. Rozycki
2025-08-29 13:10 ` [PATCH v2 04/24] PCI: Move find_bus_resource_of_type() earlier Ilpo Järvinen
2025-08-29 13:10 ` [PATCH v2 05/24] PCI: Refactor find_bus_resource_of_type() logic checks Ilpo Järvinen
2025-08-29 13:10 ` [PATCH v2 06/24] PCI: Always claim bridge window before its setup Ilpo Järvinen
2025-08-29 13:10 ` [PATCH v2 07/24] PCI: Disable non-claimed bridge window Ilpo Järvinen
2025-08-29 13:10 ` [PATCH v2 08/24] PCI: Use pci_release_resource() instead of release_resource() Ilpo Järvinen
2025-08-29 13:10 ` [PATCH v2 09/24] PCI: Enable bridge even if bridge window fails to assign Ilpo Järvinen
2025-08-29 13:10 ` [PATCH v2 10/24] PCI: Preserve bridge window resource type flags Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 11/24] PCI: Add defines for bridge window indexing Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 12/24] PCI: Add bridge window selection functions Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 13/24] PCI: Fix finding bridge window in pci_reassign_bridge_resources() Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 14/24] PCI: Warn if bridge window cannot be released when resizing BAR Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 15/24] PCI: Use pbus_select_window() during BAR resize Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 16/24] PCI: Use pbus_select_window_for_type() during IO window sizing Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 17/24] PCI: Rename resource variable from r to res Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 18/24] PCI: Use pbus_select_window() in space available checker Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 19/24] PCI: Use pbus_select_window_for_type() during mem window sizing Ilpo Järvinen
2025-10-18 8:14 ` WARNING at drivers/pci/setup-bus.c:2373, bisected to "PCI: Use pbus_select_window_for_type() during mem window sizing" Klaus Kudielka
2025-10-25 10:11 ` Klaus Kudielka
2025-10-25 12:44 ` Klaus Kudielka
2025-10-27 13:29 ` Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 20/24] PCI: Refactor distributing available memory to use loops Ilpo Järvinen
2025-10-08 14:47 ` john_chen_chn
2025-08-29 13:11 ` [PATCH v2 21/24] PCI: Refactor remove_dev_resources() to use pbus_select_window() Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 22/24] PCI: Add pci_setup_one_bridge_window() Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 23/24] PCI: Pass bridge window to pci_bus_release_bridge_resources() Ilpo Järvinen
2025-08-29 13:11 ` [PATCH v2 24/24] PCI: Alter misleading recursion " Ilpo Järvinen
2025-09-16 16:02 ` [PATCH v2 00/24] PCI: Bridge window selection improvements Ilpo Järvinen
2025-09-16 16:23 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9f80ba5e-726b-ad68-b71f-ab23470bfa36@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=macro@orcam.me.uk \
--cc=tsbogend@alpha.franken.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).