Re: [discuss] Re: Please pull x86-64 bug fixes

[Jeff Garzik <jeff@garzik.org>]

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/