Re: [PATCH]PCI:disable resource decode in PCI BAR detection

[Ivan Kokshaysky <ink@jurassic.park.msu.ru>]

On Sun, Sep 16, 2007 at 10:01:52PM +0200, Benjamin Herrenschmidt wrote:
> Agreed. I have a similar problem on ppc where it's common to have things
> like the main PIC on a PCI device. Note that another problem is (or at
> least was, i haven't checked recently) the P2P bridge scanning code
> that, in a similar way, can block the path to all devices below it. I
> -do- have a case for example with Apple Xserve G4's where the main Apple
> IO ASIC, which is a PCI device containing the PIC, the power management
> controller, and various low level system control IOs is behind a pair of
> P2P bridges.

I think the P2P probing code is pretty safe now - there are read-only
accesses to the bridge config, unless you request to reassign the bus
numbers. Though it won't be safe anymore with the patch in question.

> One solution for us (PPC) is to enforce those devices and bridges to be
> described in the OF tree, and generalize a bit the code we have for some
> 64 bits machines, that synthetizes the pci_dev's from the OF nodes
> rather than probing. But that's not going to help other archs.

If you can get reliable PCI info from firmware, it should be relatively easy
to avoid at least a bar sizing. You can install an "early" fixup for
PCI_ANY_ID and fill the resource fields of the pci_dev with values obtained
from firmware. Then all we need in probe.c is just to check that the resource
is already non-zero and skip the sizing of respective BAR, if so.

> In fact, that's a problem we also have with
> pci_assign_unassigned_resources() which will happily move things around
> that must not be moved, especially when sitting behind P2P bridges.

It's not supposed to do that. Certainly, there were problems of that sort,
but hopefully they are in the past.

Ivan.