On Sat, Aug 30, 2008 at 8:00 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Sat, 30 Aug 2008, Yinghai Lu wrote: >> > >> > /* Don't touch classless devices or host bridges or ioapics. */ >> > if (class == PCI_CLASS_NOT_DEFINED || >> > class == PCI_CLASS_BRIDGE_HOST) >> > continue; >> > >> > >> > it skips the host bridge... >> >> what's story for not touching host bridges? > > Ahh. Exactly because of things like this. The hist bridge BAR's are often > special. > > That code comes from almost four years ago, the commit message was: > > Author: Maciej W. Rozycki <macro@xxxxxxxx> > Date: Thu Dec 16 21:44:31 2004 -0800 > > [PATCH] PCI: Don't touch BARs of host bridges > > 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). > For them it's desirable to keep their decoded address range overlapping > with the host RAM for simplicity if nothing else (I can imagine running > out of address space with lots of memory and 32-bit PCI with no DAC > support in the participating devices). > > This is already the case with the i386 and ppc platform-specific PCI > resource allocators. Please consider the following change for the generic > allocator. Currently we have a pile of hacks implemented for host bridges > to be left untouched and I'd be pleased to remove them. > > From: "Maciej W. Rozycki" <macro@xxxxxxxx> > Signed-off-by: Greg Kroah-Hartman <greg@xxxxxxxxx> > > and we've had other things where host bridges are special (ie iirc, if you > turn off PCI_COMMAND_MEM from a host bridge, it stops access to real RAM > from the CPU for some bridges - so you must never turn those things off or > you get a dead system). > > (But at least Intel host bridges will just ignore writes to the CMD > register, I think - you cannot turn MEM off). then 1. we should not probe them in probe.c 2. at least we should not try to request_resource for them in pcibios_resource_survey... just pretend that they are not existing. YH -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
