[PATCH v3 2/2] asm-generic: Add new pci.h and use it

[Maciej W. Rozycki]

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