linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Roland Dreier <roland@kernel.org>
Cc: linux-arch <linux-arch@vger.kernel.org>,
	"Prakash, Sathya" <Sathya.Prakash@lsi.com>,
	"Desai, Kashyap" <Kashyap.Desai@lsi.com>,
	linux scsi dev <linux-scsi@vger.kernel.org>,
	Matthew Wilcox <matthew@wil.cx>,
	Hitoshi Mitake <h.mitake@gmail.com>,
	linux powerpc dev <linuxppc-dev@lists.ozlabs.org>,
	Milton Miller <miltonm@bga.com>,
	linux kernel <linux-kernel@vger.kernel.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Ingo Molnar <mingo@redhat.com>,
	"paulus@samba.org" <paulus@samba.org>,
	linux pci <linux-pci@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>, Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic
Date: Thu, 19 May 2011 15:34:02 +1000	[thread overview]
Message-ID: <1305783242.7481.42.camel@pasglop> (raw)
In-Reply-To: <BANLkTimDktq8SxOU3HZkPpj=J9pdkzVX-w@mail.gmail.com>

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.

Cheers,
Ben.

  reply	other threads:[~2011-05-19  5:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20110504115324.GE17855@lsi.com>
     [not found] ` <1305616571.6008.23.camel@mulgrave.site>
     [not found]   ` <B2FD678A64EAAD45B089B123FDFC3ED70157F7BCE5@inbmail01.lsi.com>
2011-05-18  4:15     ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic Matthew Wilcox
2011-05-18  4:23       ` James Bottomley
2011-05-18  7:00         ` Benjamin Herrenschmidt
2011-05-18  8:23           ` Milton Miller
2011-05-18 15:35             ` Moore, Eric
2011-05-18 18:31               ` Milton Miller
2011-05-18 19:11                 ` Moore, Eric
2011-05-19  4:08                   ` Hitoshi Mitake
2011-05-19  4:46                     ` James Bottomley
2011-05-19  5:36                       ` Benjamin Herrenschmidt
2011-05-19  8:35                       ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic David Laight
2011-05-19  4:16                 ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic Roland Dreier
2011-05-19  5:34                   ` Benjamin Herrenschmidt [this message]
2011-05-19 18:15                     ` Ingo Molnar
2011-05-18 21:30               ` Benjamin Herrenschmidt
2011-05-18 22:05                 ` Moore, Eric
2011-05-18  8:04         ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic David Laight
2011-05-18  5:45       ` [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq is not atomic Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1305783242.7481.42.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=Kashyap.Desai@lsi.com \
    --cc=Sathya.Prakash@lsi.com \
    --cc=h.mitake@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=matthew@wil.cx \
    --cc=miltonm@bga.com \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=roland@kernel.org \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).