TI CardBus bridge problem

[Adam Belay]

On Wed, Jul 06, 2005 at 10:13:42PM +0100, Russell King wrote:
> On Wed, Jul 06, 2005 at 04:22:51PM -0400, Adam Belay wrote:
> > Another major issue is that we reserve 4 bus numbers for cardbus bridges.
> > Last I've looked at it, this code is very broken.  It ignores the busnr
> > configuration of peer bridges.  I think it should be removed.
> 
> Doing that breaks cardbus cards with P2P bridges on them, which we already
> support today and was one of the reasons for me reworking the cardbus code.
> 

But the PCI bus numbering is incorrect and unreliable.  I'd rather avoid
bus number conflicts for on-board hardware than support cardbus P2P
bridges.  At the very least we need to check if it's safe.  If the BIOS
didn't leave room for more bus numbers with the current cardbus bus
number assignment, then supporting P2P cardbus bridges is not
necessarily a stable option.  Resizing a bus number range is fine, but
it's important to ensure it's not conflicting with a peer device.

Consider the following:

We try to register bios configured devices first, with the exception of
cardbus bridges. So immediately we scan BUS 2.  The recursive algorithm
then sets up its children. (first bus 4, then a reassigment of cardbus
3)  Then BUS 5 is scanned, we don't touch its configuration because it's
bios configured.

HOST BUS 0
|
[snip]
|
\PCI BUS 2 (2-4) (bios configured) -> (2-7) (linux configured)
||
|\- CARD BUS 3 (3-3) (bios configured) -> (5-7) (linux configured)
|\- PCI BUS 4 (4-4) (bios configured) -> no change
|
\PCI BUS 5 (5-5) (bios configured) -> no change (ugly conflict problem)

Here's another example of this behavior from a post rmk made on
bugzilla:

http://bugzilla.kernel.org/show_bug.cgi?id=2944#c7

It seems like the PCI probing code needs to be redesigned.  It would be
useful if we could decide on a target bus numbering behavior.

Thanks,
Adam