TI CardBus bridge problem

[Russell King]

On Wed, Jul 06, 2005 at 06:02:26PM -0400, Adam Belay wrote:
> 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.

However, the broken machines do not have a PCI bus number allocated
to the bus between the cardbus bridge and the cardbus card itself.
By your argument above, we therefore do not support Cardbus at all
on these machines.

> 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.

There are two solutions - renumber the whole bus or renumber the
problematical bus.  Either way, you're renumbering which from
what you're indicating above, this is "incorrect and unreliable".

That said, telling Linux to renumber all busses has worked in all
cases except one now, which is where bridges with higher devfns
have lower secondary/subordinate bus ids than bridges with lower
devfns - which is the opposite to how we assign them. (and hence
asking Linux to assign bus ids will mean we'll immediately end
up with two busses thinking they're both bus id 1, probably
causing a bus error on the first config cycle to that a device
with that bus id.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core