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

On Mon, 13 Oct 2025, Thomas Bogendoerfer wrote:

> > This patch causes boot failures when trying to boot mips images from
> > ide drive in qemu. As far as I can see the interface no longer instantiates.
> > 
> > Reverting this patch fixes the problem. Bisect log attached for reference.
> 
> Patch below fixes my qemu malta setup. Now I'm wondering, why this is
> needed. It was added with commit
> 
> aa0980b80908 ("Fixes for system controllers for Atlas/Malta core cards.")
> 
> Maciej, do you remember why this is needed ?

 I do.  The reason is preventing PCI port I/O mappings below 0x100, which 
interferes badly with how the PIIX4 decodes port I/O cycles.  That did 
happen in the field, wreaking havoc and prompting my change.

 By the look of the code it would definitely trigger for the Bonito64 
system controller, which has a fixed port I/O target address range and, 
depending on the settings left by the firmware, it might also trigger for 
the Galileo GT64120A and SOC-it 101 system controllers, which have 
variable port I/O target address ranges.

 Here's an example map of Malta port I/O resources (SOC-it 101 variant):

00000000-0000001f : dma1
00000020-00000021 : pic1
00000040-0000005f : timer
00000060-0000006f : keyboard
00000070-00000077 : rtc0
00000080-0000008f : dma page reg
000000a0-000000a1 : pic2
000000c0-000000df : dma2
00000170-00000177 : ata_piix
000001f0-000001f7 : ata_piix
000002f8-000002ff : serial
00000376-00000376 : ata_piix
00000378-0000037a : parport0
0000037b-0000037f : parport0
000003f6-000003f6 : ata_piix
000003f8-000003ff : serial
00001000-00ffffff : MSC PCI I/O
  00001000-0000103f : 0000:00:0a.3
  00001040-0000105f : 0000:00:0a.2
    00001040-0000105f : uhci_hcd
  00001060-0000107f : 0000:00:0b.0
    00001060-0000107f : pcnet32_probe_pci
  00001080-000010ff : 0000:00:12.0
    00001080-000010ff : defxx
  00001100-0000110f : 0000:00:0a.3
  00001400-000014ff : 0000:00:13.0
  00001800-0000180f : 0000:00:0a.1
    00001800-0000180f : ata_piix

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.

 The choice of 0x1000 as the lower boundary IIRC has something to do with 
alignment; I think the decoding base has to be a multiple of 0x1000 and 
given that the ACPI resource is decoded by a non-standard BAR at 0x40 in 
the configuration space (set up by `malta_piix_func3_base_fixup' BTW) we 
just need to match its setting.

 Can you please check what the port I/O map looks like with your setup 
with and without your patch applied?

 NB there is still something fishy with the setup of SOC-it 101's PCI 
decoding windows, which is why I have forced `defxx' with a patch to use 
port I/O, as reported above.  The driver uses MMIO unconditionally on PCI 
systems nowadays, but using MMIO prevents it from working with the SOC-it 
101 system controller and I yet need to debug it.  Conversely MMIO used to 
work just fine with the Galileo GT64120A system controller while I still 
had one operational.

 HTH,

  Maciej

Powered by blists - more mailing lists