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@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
