All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: corbet@lwn.net, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Arnd Bergmann <arnd@arndb.de>,
	David Laight <David.Laight@ACULAB.COM>,
	Alan Stern <stern@rowland.harvard.edu>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] docs/memory-barriers.txt: Enforce heavy ordering for port I/O accesses
Date: Mon, 26 Nov 2018 11:42:05 -0800	[thread overview]
Message-ID: <20181126194205.GL4170@linux.ibm.com> (raw)
In-Reply-To: <1543251134-29867-1-git-send-email-will.deacon@arm.com>

On Mon, Nov 26, 2018 at 04:52:14PM +0000, Will Deacon wrote:
> David Laight explains:
> 
>   | A long time ago there was a document from Intel that said that
>   | inb/outb weren't necessarily synchronised wrt memory accesses.
>   | (Might be P-pro era). However no processors actually behaved that
>   | way and more recent docs say that inb/outb are fully ordered.
> 
> This also reflects the situation on other architectures, the the port
> accessor macros tend to be implemented in terms of readX/writeX.
> 
> Update Documentation/memory-barriers.txt to reflect reality.
> 
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: David Laight <David.Laight@ACULAB.COM>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>

Queued, with the addition of Cc: of LKML, linux-arch, and linux-docs,
thank you!

(Otherwise, these lists can get lost when I send out the LKMM series.)

							Thanx, Paul

> ---
> 
> Just remembered I had this patch kicking around in my tree...
> 
>  Documentation/memory-barriers.txt | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index c1d913944ad8..0c34c5dac138 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -2619,10 +2619,8 @@ functions:
>       intermediary bridges (such as the PCI host bridge) may not fully honour
>       that.
> 
> -     They are guaranteed to be fully ordered with respect to each other.
> -
> -     They are not guaranteed to be fully ordered with respect to other types of
> -     memory and I/O operation.
> +     They are guaranteed to be fully ordered with respect to each other and
> +     also with respect to other types of memory and I/O operation.
> 
>   (*) readX(), writeX():
> 
> -- 
> 2.1.4
> 


      parent reply	other threads:[~2018-11-26 19:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 16:52 [PATCH] docs/memory-barriers.txt: Enforce heavy ordering for port I/O accesses Will Deacon
2018-11-26 19:33 ` Andrea Parri
2018-11-27 18:40   ` Paul E. McKenney
2018-11-27 19:22     ` Matthew Wilcox
2018-11-26 19:42 ` Paul E. McKenney [this message]

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=20181126194205.GL4170@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.