Re: [PATCH] Don't touch BARs of host bridges

[Maciej W. Rozycki]

On Sat, 11 Dec 2004, Benjamin Herrenschmidt wrote:

> >  Well, some of these bridges may be used for peripheral devices (option
> > cards) built around a CPU, typically after reprogramming the class code to
> > something corresponding to their actual function.  Why should the address
> > decoder circuitry suddenly change in this case?
> 
> To stay in the PCI spec ? :) They would need at least a way to "lock"
> the BARs.

 What do you mean?  If used in an option card, you may want some of the
device's internal address space to be accessible from your host somehow,
e.g. as a way of interfacing the device's firmware, so you need a BAR to
map it somewhere in the PCI address space.

> >  These are pre-2.0 PCI devices -- from before the detailed classification
> > was agreed upon.  AFAIK, just a couple of them exist -- I can name:  
> > Intel's 82424 and 82425 families of i486 host bridges, their 82375 family
> > of PCI-EISA bridges and their 82378/9 family of PCI-ISA bridges (also used
> > in a few DEC Alpha systems).  There are probably a handful of other chips,
> > all of them about ten years old.  Our i386 and ppc resource managers skip
> > over them as well and I suppose this is a safe default.  If any of them
> > needs BAR setup (none of these Intel ones), it can be added explicitly by
> > means of its vendor:device ID.
> 
> Ok.

 And BTW, we fix it up for the 82375 as a quirk, by substituting the
"right" class code.  It can be done for others if there's a need.

  Maciej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/