* Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 2011-05-18 at 21:16 -0700, Roland Dreier wrote: > > On Wed, May 18, 2011 at 11:31 AM, Milton Miller <miltonm@xxxxxxx> wrote: > > > So the real question should be why is x86-32 supplying a broken writeq > > > instead of letting drivers work out what to do it when needed? > > > > Sounds a lot like what I was asking a couple of years ago :) > > http://lkml.org/lkml/2009/4/19/164 > > > > But Ingo insisted that non-atomic writeq would be fine: > > http://lkml.org/lkml/2009/4/19/167 > > Yuck... Ingo, I think that was very wrong. > > Those are for MMIO, which must almost ALWAYS know precisely what the > resulting access size is going to be. It's not even about atomicity > between multiple CPUs. I have seen plenty of HW for which a 64-bit > access to a register is -not- equivalent to two 32-bit ones. In fact, in > some case, you can get the side effects twice ... or none at all. > > The only case where you can be lax is when you explicitely know that > there is no side effects -and- the HW cope with different access sizes. > This is not the general case and drivers need at the very least a way to > know what the behaviour will be. Ok, that's pretty convincing. Unless hpa or tglx disagrees with reverting this, could any of you send a patch with a proper changelog etc. that applies cleanly to v2.6.39? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
