On Fri, 6 Oct 2006, Andi Kleen wrote:
>
> > In other words, right now we have
> >
> > int pci_read_config_byte(struct pci_dev *dev, int where, u8 *val)
> >
> > and maybe we will simply have to add a totally new function like
> >
> > int pci_read_mmio_config_byte(struct pci_dev *dev, int where, u8 *val)
> >
> > for drivers that literally _require_ the mmio accesses for one reason or
> > another.
>
> That's easy to decide: if (where >= 256) mmconfig is required.
>
> I'm just afraid it probably won't help if the MCFG is totally broken and
> points to some other devices (like on the Intel boards). Then these drivers will
> just hang and all of Alan's warning messages won't help with that.
Sure. I'd actually prefer a separate interface partly for that reason, and
partly also because I think the whole "pci_read_config_xxx()" interface
has always been horrible.
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).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
