All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"monstr@monstr.eu" <monstr@monstr.eu>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"broonie@linaro.org" <broonie@linaro.org>,
	"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH 00/18] Cross-architecture definitions of relaxed MMIO accessors
Date: Thu, 17 Apr 2014 16:47:15 +0100	[thread overview]
Message-ID: <20140417154714.GD30553@arm.com> (raw)
In-Reply-To: <20140417153638.GA7317@ravnborg.org>

Hi Sam,

On Thu, Apr 17, 2014 at 04:36:38PM +0100, Sam Ravnborg wrote:
> On Thu, Apr 17, 2014 at 02:44:03PM +0100, Will Deacon wrote:
> > Hello,
> > 
> > This RFC series attempts to define a portable (i.e. cross-architecture)
> > definition of the {readX,writeX}_relaxed MMIO accessor functions. These
> > functions are already in widespread use amongst drivers (mainly those supporting
> > devices embedded in ARM SoCs), but lack any well-defined semantics and,
> > subsequently, any portable definitions to allow these drivers to be compiled for
> > other architectures.
> 
> Could this be made in such a way that only architectures that need
> to provide their own versions actually have to add them?
> 
> The current patch-set adds the same dummy defines all over,
> and will put this burden also on new architectures.

It shouldn't be a burden for new architectures, as they will use
asm-generic/io.h and get the definitions from there.

Will

  reply	other threads:[~2014-04-17 15:48 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-17 13:44 [PATCH 00/18] Cross-architecture definitions of relaxed MMIO accessors Will Deacon
2014-04-17 13:44 ` [PATCH 01/18] asm-generic: io: implement relaxed accessor macros as conditional wrappers Will Deacon
2014-04-17 13:44 ` [PATCH 02/18] microblaze: io: remove dummy relaxed accessor macros Will Deacon
2014-04-22 13:53   ` Michal Simek
2014-04-17 13:44 ` [PATCH 03/18] s390: io: remove dummy relaxed accessor macros for reads Will Deacon
2014-04-17 13:44 ` [PATCH 04/18] xtensa: " Will Deacon
2014-04-17 13:44 ` [PATCH 05/18] alpha: io: implement relaxed accessor macros for writes Will Deacon
2014-04-17 13:44 ` [PATCH 06/18] frv: io: implement dummy " Will Deacon
2014-04-17 13:44 ` [PATCH 07/18] cris: " Will Deacon
2014-04-22 13:47   ` Jesper Nilsson
2014-04-17 13:44 ` [PATCH 08/18] ia64: " Will Deacon
2014-04-17 13:44 ` [PATCH 09/18] m32r: " Will Deacon
2014-04-17 13:44 ` [PATCH 10/18] m68k: " Will Deacon
2014-04-17 16:07   ` Geert Uytterhoeven
2014-04-17 13:44 ` [PATCH 11/18] mn10300: " Will Deacon
2014-04-17 13:44 ` [PATCH 12/18] parisc: " Will Deacon
2014-04-17 13:44 ` [PATCH 13/18] powerpc: " Will Deacon
2014-04-17 13:44 ` [PATCH 14/18] sparc: " Will Deacon
2014-04-17 13:44 ` [PATCH 15/18] tile: " Will Deacon
2014-04-17 14:52   ` Chris Metcalf
2014-04-17 14:52     ` Chris Metcalf
2014-04-17 13:44 ` [PATCH 16/18] x86: " Will Deacon
2014-04-22 16:08   ` Will Deacon
2014-05-21  1:53     ` Brian Norris
2014-05-21  9:22       ` Will Deacon
2014-04-17 13:44 ` [PATCH 17/18] documentation: memory-barriers: clarify relaxed io accessor semantics Will Deacon
2014-04-17 13:44 ` [PATCH 18/18] asm-generic: io: define relaxed accessor macros unconditionally Will Deacon
2014-04-22 14:09   ` Michal Simek
2014-04-22 15:18     ` Will Deacon
2014-04-23  7:12       ` Michal Simek
2014-04-23  7:23     ` Sam Ravnborg
2014-04-23  7:36       ` Michal Simek
2014-04-17 14:00 ` [PATCH 00/18] Cross-architecture definitions of relaxed MMIO accessors Peter Zijlstra
2014-04-17 14:15   ` Will Deacon
2014-04-17 21:36   ` Benjamin Herrenschmidt
2014-05-01 11:10     ` Will Deacon
2014-04-17 15:36 ` Sam Ravnborg
2014-04-17 15:47   ` Will Deacon [this message]
2014-04-17 19:15     ` Sam Ravnborg
2014-04-22 13:43       ` Will Deacon
2014-04-22 14:30         ` Sam Ravnborg

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=20140417154714.GD30553@arm.com \
    --to=will.deacon@arm.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=broonie@linaro.org \
    --cc=dhowells@redhat.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=monstr@monstr.eu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.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 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.