Messages in this thread | | | Date | Thu, 05 Oct 2006 19:36:25 -0400 | From | Jeff Garzik <> | Subject | Re: [discuss] Re: Please pull x86-64 bug fixes |
| |
Linus Torvalds wrote: > If we had the > > void __iomem *cfg = mmiocfg_remap(dev); > > interface, we could (fairly easily) blacklist known-bad motherboards if we > needed to, and also, it would allow drivers to check whether mmiocfg is > available. It's possible that some drivers might want it if it exists, but > it wouldn't necessarily be somethign that they _require_, so they could > gracefully handle the case of getting a NULL config space handle back. > > For example, for some devices, maybe they'd lose some error handling > capability, but they'd still be able to work otherwise.
Ugh. Large PCI config space is going to be the norm real soon. That will just nasty up drivers.
> We _can_ do the same thing with checking the error return value from > "pci_read_config_xxxx()", and use the "use different access method if the > index is >= 256", but I have to say, that just makes my gag reflex > trigger. Having the same function just silently do two different things > depending on the offset just sounds like a recipe for disaster.
Agreed.
> I dunno. I'm not likely to care _that_ deeply about this all, but I do > think that machines that hang on device discovery is just about the worst > possible thing, so I'd much rather have ten machines that can't use their > very rare devices without some explicit kernel command line than have even > _one_ machine that just hangs because MMIOCFG is buggered. > > (And we should probably have the "pci=mmiocfg" kernel command line entry > that forces MMIOCFG regardless of any e820 issues, even for normal > accesses).
Agreed.
Jeff
- 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/
| |