On Fri, Jul 22, 2022 at 1:23 PM Maciej W. Rozycki <macro@xxxxxxxxxxx> wrote: > > 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. Let me ask this another way. When would a 0 memory or i/o address ever work? It doesn't seem this s/w limitation has anything specific to Risc-V. Given pci_iomap_range() rejects 0, I can't see how it could ever work. Maybe only for legacy ISA? So should the generic defaults just be what Risc-V is using instead of 0? Rob
