Re: [PATCH v2 03/24] MIPS: PCI: Use pci_enable_resources()

Maciej W. Rozycki
2025-10-14T12:58:11Z

On Tue, 14 Oct 2025, Ilpo Järvinen wrote:

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

Yes, we need either, not both.

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

That's what I meant, sorry to be unclear.

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

As /proc/ioport contents indicate the resources did get assigned or there
would be no claiming driver reported. I'm sure I did double-check it back
in the day too.

Maciej