TI CardBus bridge problem

[Adam Belay]

On Wed, Jul 06, 2005 at 11:43:51PM +0100, Russell King wrote:
> 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.

The bus in between the cardbus bridge can be allocated new numbers if it
wasn't BIOS configured.  Furthermore, it can be extended (by increasing
the subordinate value) as long as it doesn't conflict with a peer bridge.
Could you provide more details about these machines?  It's unlikely this
argument prevents us from supporting them.

My point is that, under the current approach, we can't assign bus numbers
unless the BIOS configuration left enough room.  We need to check every BIOS
assigned range for conflicts before allocating multiple bus numbers to a
cardbus bridge.  We should only give a cardbus bridge as much as is available,
even if that's only one bus number.  If there aren't any numbers available,
then the bridge needs to be disabled.  The alternative would be to renumber
every device, including some or all BIOS configured devices.

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

I didn't indicate that renumbering is "incorrect and unreliable", I indicated
that blindly renumbering without first checking for conflicts is unreliable.
This is a flaw in the current code.  The argument especially applies when we
try to keep BIOS assignments.

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

If we registered each bus number range in a fashion similar to IO/MEM
resources this problem could be avoided. We could then keep most BIOS
assignments and renumber anywhere it is necessary.  The code would be
somewhat complicated, but it would work well.

Also, as I said earlier, renumbering might break hotplug bridges if we don't
keep the range sizes intended by the BIOS.

Finally, we need to verify that ACPI and other firmware aren't negatively
affected by this behavior.

Thanks,
Adam