linux-kernel - Re: [PATCH v2 03/24] MIPS: PCI: Use pci_enable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2510141349560.39634@angie.orcam.me.uk>
Date: Tue, 14 Oct 2025 13:58:10 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Guenter Roeck <linux@...ck-us.net>, Bjorn Helgaas <bhelgaas@...gle.com>, 
    linux-pci@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 03/24] MIPS: PCI: Use pci_enable_resources()

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