Re: PATCH: New fix for CardBus bridge behind a PCI bridge

From: H. J. Lu (
Date: Sat Aug 17 2002 - 10:36:01 EST

On Sat, Aug 17, 2002 at 11:26:08AM -0400, Jeff Garzik wrote:
> H. J. Lu wrote:> On Fri, Aug 16, 2002 at 07:48:25PM +0400, Ivan
> Kokshaysky wrote:
> >
> >>On Mon, Aug 12, 2002 at 08:29:42PM -0700, H. J. Lu wrote:
> >>
> >>>I was told all PCI_CLASS_BRIDGE_PCI bridges were transparent. The non-
> >>>transparent ones have class code PCI_CLASS_BRIDGE_OTHER. This new patch
> >>>only checks PCI_CLASS_BRIDGE_PCI and works for me.
> >>
> >>I guess that info came from Intel ;-) Interesting, but completely wrong.
> >>The devices they call "non-transparent PCI-to-PCI bridges" aren't classic
> >>PCI-to-PCI bridges at all, that's why they are PCI_CLASS_BRIDGE_OTHER.
> >>It's more to do with CPU-to-CPU bridges.
> >>In our terms, "transparent" PCI-to-PCI bridge means subtractive decoding one.
> >>Your previous patch makes much more sense, although a) it should belong to
> >>generic pci code b) is way incomplete.
> >>
> >>Please try this one instead.
> >>
> >
> >
> > CardBus works now. But I can no longer load usb-uhci. My X server no
> > longer works. Your patch is not right.
> I would be willing to bet there is some silliness in the X server, at
> least. It's PCI code has always left a lot to be desired...

It could be. But I doubt it. At least, I don't think you can treat a
AGP bridge like a 82801BAM/CAM bridge. I think 82801BAM/CAM is a
special case. You really have to read the datasheet to know for sure.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Aug 23 2002 - 22:00:13 EST