On 22 Jul 2022, at 20:55, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Fri, Jul 22, 2022 at 6:36 PM Rob Herring <robh@xxxxxxxxxx> wrote: >> On Fri, Jul 22, 2022 at 9:27 AM Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote: >> >> From fu740: >> ranges = <0x81000000 0x0 0x60080000 0x0 >> 0x60080000 0x0 0x10000>, /* I/O */ > ... >> So again, how does one get a 0 address handed out when that's not even >> a valid region according to DT? Is there some legacy stuff that >> ignores the bridge windows? > > The PCI-side port number 0x60080000 gets turned into Linux I/O resource 0, > which I think is what __pci_assign_resource operates on. > > The other question is why the platform would want to configure the > PCI bus to have a PCI I/O space window of size 0x10000 at the address > it's mapped into, rather than putting it at address zero. Is this a hardware > bug, a bootloader bug, or just badly set up in the DT? > > Putting the PCI address of the I/O space window at port 0 is usually > better because it works with PCI devices and drivers that assume that > port numbers are below 0xfffff, and makes the PCI port number match > the Linux port number. Possibly related is the (harmless) warning spew seen during boot on FreeBSD. The bridge, and all downstream ones, reset to having I/O window 0x0-0xfff and memory/prefetch window 0x0-0xfffff (which FreeBSD tries to allocate, fails because that’s outside the valid ranges above, so it then just paves over with a sane fresh config). Linux resets the controller on probe so this is the initial state when enumerating, and perhaps that’s not handled so gracefully as on FreeBSD (which also resets in device_attach, the second half of what Linux calls probe)? Jess
