lkml.org 
[lkml]   [2006]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-10-06 01:39    [W:0.118 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site