On Mon, 2005-12-19 at 14:51 -0800, David S. Miller wrote: > And if the PCI write gets posted for "X" usec, we'll still do the PCI > read back-to-back with the write it will thus still hang. This change > makes the "_f()" part totally pointless. There is nothing to flush > out if we're going to use a delay to wait for the write to take > effect. By definition the write has been flushed already if it has > already taken effect within the device. > > Yes, this delay works most of the time, but there are legitimate cases > where it would not. > > That isn't to say I won't apply the patch. I'm just pointing out how > incredibly silly this is :-) It would be nice if the hardware > actually would function correctly in the presence of deeply delayed > posted PCI writes, but aparently there are very few chips that do. >
Totally agreed. But I cannot think of a better way to handle this. The delays have generous margins built-in, so hopefully it won't be a problem. BTW, I have considered always using config. cycles for such registers. Config. cycles are non-posted and do not require read back. But our hw engineers told me that it would still be safer to use mem. cycles even with the risk of an extended posting delay. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
