* 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/
