![]() | |||||||||||
Messages in this thread |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2005-03-22 14:08 [from the cache] ©2003-2008 | |||||||||||