* Robert Hancock <[email protected]> wrote:
>> unfortunately this hack's side-effects are mis-used by an unknown
>> number of drivers to mask PCI posting bugs. We want to figure out
>> those bugs (safely and carefully) and we want to remove this hack
>> from modern machines that dont need it. Doing anything else would be
>> superstition.
>
> Are there any such examples known of such drivers? It doesn't seem to
> make much sense.. PCI IO writes are not posted on any known system
> (the spec allows them to be posted in the host bus bridge, but if they
> were they could only be flushed by a read, not a write) and PCI MMIO
> writes are only guaranteed to flush by doing a read from that device,
> not by other random port accesses. I suppose using the _p versions of
> port accesses might happen to mask such problems on certain machines..
yeah, that's the fear - that timing sensitivities or outright races are
hidden via _p() uses. It's a bit like the BKL - nobody really knows why
it's still needed in some places but there's "fear" that "stuff might
break" so removal is very slow. So we should get rid of all _p() uses,
by either removing them (concluding that the _p() was not needed), or by
adding in an udelay(2) (documenting that the device indeed relies on the
delay from the host side) or by adding whatever posting/flushing is
needed. That will gradually reduce the amount of code that uses _p()
methods, and will improve the quality of the kernel.
Ingo
--
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]
