On Fri, 22 Jul 2022, Rob Herring wrote: > > Maybe the right thing to do here is actually to make the default > > definitions of these macros non-zero, or to add some sort of ARCH_ > > flavor of them and move that non-zero requirement closer to where it > > comes from? From the look of it any port that uses the generic port I/O > > functions and has 0 for these will be broken in the same way. > > > > That said, I'm not really a PCI guy so maybe Bjorn or Maciej has a > > better idea? > > >From fu740: > ranges = <0x81000000 0x0 0x60080000 0x0 > 0x60080000 0x0 0x10000>, /* I/O */ > <0x82000000 0x0 0x60090000 0x0 > 0x60090000 0x0 0xff70000>, /* mem */ > <0x82000000 0x0 0x70000000 0x0 > 0x70000000 0x0 0x1000000>, /* mem */ > <0xc3000000 0x20 0x00000000 0x20 > 0x00000000 0x20 0x00000000>; /* mem prefetchable */ > > 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? It doesn't matter as <asm/pci.h> just sets it as a generic parameter for the platform, reflecting the limitation of PCI core, which in the course of the discussion referred was found rather infeasible to remove. The FU740 does not decode to PCI at 0, but another RISC-V device could. And I think that DT should faithfully describe hardware and not our software limitations. Mind that PCI has originated from the x86 world where decoding low 24-bit memory space to ISA has been implied (implicitly decoded on PCI systems by the southbridge) for areas not decoded to DRAM by the memory controller. So the inability of our PCI core to handle MMIO at 0 did not matter at the time it was introduced as the value of 0 would never be used for a memory BAR. Maciej
