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.
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.
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).