Messages in this thread | | | Date | Thu, 19 May 2011 20:15:00 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic |
| |
* Benjamin Herrenschmidt <benh@kernel.crashing.org> 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@bga.com> 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
| |