Re: trouble with PCI: Call pci_read_bridge_bases() from core instead of arch code

[Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>]

Yinghai,

On Mon, Sep 07, 2015 at 10:12:30AM +0100, Lorenzo Pieralisi wrote:
> On Sat, Sep 05, 2015 at 12:53:48AM +0100, Yinghai Lu wrote:
> > On Fri, Sep 4, 2015 at 9:44 AM, Lorenzo Pieralisi
> > <lorenzo.pieralisi@arm.com> wrote:
> > > On Fri, Sep 04, 2015 at 05:00:35PM +0100, Yinghai Lu wrote:
> > >
> > > The problem here is not the last retry, it is the first bridge scan.
> > >
> > > By moving pci_read_bridge_bases() to core PCI code, if we do not
> > > vet the bridge apertures (ie claim them and reset them if the claiming
> > > fails) we end up calling (on ARM) __pci_bus_size_bridges() with apertures
> > > that can have sizes != 0, which does not make any sense since we are calling
> > > __pci_bus_size_bridges() to *discover* what the aperture size should
> > > be on first bridge scan, correct ?
> > 
> > for x86, in pcibios_allocate_bridge_resources(), we do validate
> > the bridge resources, and reset size to 1 (strange ?!).
> 
> Yes, strange, but there is even a special case in calculate_memsize()
> to handle that :) it seems !

Any thoughts on that ? I would like to understand if there is any
reason why on first scan the bridge aperture size is relevant, whereas
in my opinion it should not be, I need your input on that.

Put it differently, I do not see any reason why arch code should
reset the bridge resource on platforms that reassign the whole
PCI config space, if you see any please mention it here.

As I said, ARM is not the only platform affected, MIPS and possibly
Alpha suffer from the same issue and I think it should be fixed
in core code (I think __pci_bus_size_bridges() should ignore the
old aperture size on first scan).

Thanks !
Lorenzo