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

[Maciej W. Rozycki]

On Fri, 10 Dec 2004, Benjamin Herrenschmidt wrote:

> >  BARs of host bridges often have special meaning and AFAIK are best left 
> > to be setup by the firmware or system-specific startup code and kept 
> > intact by the generic resource handler.  For example a couple of host 
> > bridges used for MIPS processors interpret BARs as target-mode decoders 
> > for accessing host memory by PCI masters (which is quite reasonable).  
> 
> Not very reasonable in fact imho but that happens on some embedded PPCs

 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?

 Also even in the "host mode" another device may wish to examine what
resources have been reserved by the host bridge (unlikely, I admit, but 
in principle why not?).

> was well :) So I agree, that would be useful to skip them. I'm not sure
> about PCI_CLASS_NOT_DEFINED tho ...

 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.

  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/