On Tue, Sep 15, 2015 at 12:25 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
> [+cc Ray]
>
> On Tue, Sep 15, 2015 at 09:51:54AM -0700, Guenter Roeck wrote:
>> On 09/15/2015 09:30 AM, Lorenzo Pieralisi wrote:
>> >On Tue, Sep 15, 2015 at 04:57:07PM +0100, Bjorn Helgaas wrote:
>
>> >>I'm inclined to revert dff22d2054b5 ("PCI: Call
>> >>pci_read_bridge_bases() from core instead of arch code") until we can
>> >>figure this out. I think the idea of moving that work from
>> >>arch-specific code to the core is good, but it seems like it leads to
>> >>more hacky workarounds than real cleanup right now. What would break
>> >>if we simply reverted it? Would that reintroduce any problems?
Agreed, that is good if we can move pci_read_bridge_bases() to pci core.
Also hope that we can move pcibios_resource_survey() etc into
core too.
> I put the following on my for-linus branch for v4.3. I'd appreciate any
> corrections to my understanding of the problem.
>
>
> commit d5da9d99d4d79d877815af96fdbfac829c4ce7b2
> Author: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> Date: Tue Sep 15 13:18:04 2015 -0500
>
> PCI: Revert "PCI: Call pci_read_bridge_bases() from core instead of arch code"
>
> Revert dff22d2054b5 ("PCI: Call pci_read_bridge_bases() from core instead
> of arch code").
>
> Reading PCI bridge windows is not arch-specific in itself, but there is PCI
> core code that doesn't work correctly if we read them too early. For
> example, Hannes found this case on an ARM Freescale i.mx6 board:
>
> pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> pci 0000:00:00.0: BAR 8: no space for [mem size 0x01000000] (mem window)
> pci 0000:01:00.0: BAR 2: failed to assign [mem size 0x00200000]
> pci 0000:01:00.0: BAR 1: failed to assign [mem size 0x00004000]
> pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00000100]
>
> The 00:00.0 mem window needs to be at least 3MB: the 01:00.0 device needs
> 0x204100 of space, and mem windows are megabyte-aligned.
>
> Bus sizing can increase a bridge window size, but never *decrease* it (see
> d65245c3297a ("PCI: don't shrink bridge resources")). Prior to
> dff22d2054b5, ARM didn't read bridge windows at all, so the "original size"
> was zero, and we assigned a 3MB window.
>
> After dff22d2054b5, we read the bridge windows before sizing the bus. The
> firmware programmed a 16MB window (size 0x01000000) in 00:00.0, and since
> we never decrease the size, we kept 16MB even though we only needed 3MB.
> But 16MB doesn't fit in the host bridge aperture, so we failed to assign
> space for the window and the downstream devices.
>
> I think this is a defect in the PCI core: we shouldn't rely on the firmware
> to assign sensible windows.
>
> Ray reported a similar problem, also on ARM, with Broadcom iProc.
>
> Issues like this are too hard to fix right now, so revert dff22d2054b5.
>
> Reported-by: Hannes <oe5hpm@xxxxxxxxx>
> Reported-by: Ray Jui <rjui@xxxxxxxxxxxx>
> Link: http://lkml.kernel.org/r/CAAa04yFQEUJm7Jj1qMT57-LG7ZGtnhNDBe=PpSRa70Mj+XhW-A@xxxxxxxxxxxxxx
> Link: http://lkml.kernel.org/r/55F75BB8.4070405@xxxxxxxxxxxx
> Signed-off-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
Acked-by: Yinghai Lu <yinghai@xxxxxxxxxx>
--
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
