[PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Will Deacon]

Hello everybody,

This is version three of the series I've originally posted here:

  v1: https://lkml.org/lkml/2014/4/17/269
  v2: https://lkml.org/lkml/2014/5/22/468

This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
(which was merged into mainline).

I looked at reworking the non-relaxed accessors to imply mmiowb, but it
quickly got messy as some architectures (e.g. mips) deliberately keep
mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
drivers to get mmiowb correct, so add barriers to both. Given that
arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
an architecture that does care.

In order to get this lot merged, we probably want to merge the asm-generic
patch (1/17) first, so Acks would be much appreciated on the architecture
bits.

As before, I've included the original cover letter below, as that describes
what I'm trying to do in more detail.

Thanks,

Will

--->8

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.

The two main motivations for this series are:

 (1) To promote use of the _relaxed MMIO accessors on weakly-ordered
     architectures, where they can bring significant performance improvements
     over their non-relaxed counterparts.

 (2) To allow COMPILE_TEST to build drivers using the relaxed accessors across
     all architectures.

The proposed semantics largely match exactly those provided by the ARM
implementation (i.e. no weaker), with one exception (see below).

Informally:

  - Relaxed accesses to the same device are ordered with respect to each other.

  - Relaxed accesses are *not* guaranteed to be ordered with respect to normal
    memory accesses (e.g. DMA buffers -- this is what gives us the performance
    boost over the non-relaxed versions).

  - Relaxed accesses are not guaranteed to be ordered with respect to
    LOCK/UNLOCK operations.

In actual fact, the relaxed accessors *are* ordered with respect to LOCK/UNLOCK
operations on ARM[64], but I have added this constraint for the benefit of
PowerPC, which has expensive I/O barriers in the spin_unlock path for the
non-relaxed accessors.

A corollary to this is that mmiowb() probably needs rethinking. As it currently
stands, an mmiowb() is required to order MMIO writes to a device from multiple
CPUs, even if that device is protected by a lock. However, this isn't often used
in practice, leading to PowerPC implementing both mmiowb() *and* synchronising
I/O in spin_unlock.

I would propose making the non-relaxed I/O accessors ordered with respect to
LOCK/UNLOCK, leaving mmiowb() to be used with the relaxed accessors, if
required, but would welcome thoughts/suggestions on this topic.


Will Deacon (17):
  asm-generic: io: implement relaxed accessor macros as conditional
    wrappers
  microblaze: io: remove dummy relaxed accessor macros
  s390: io: remove dummy relaxed accessor macros for reads
  xtensa: io: remove dummy relaxed accessor macros for reads
  frv: io: implement dummy relaxed accessor macros for writes
  cris: io: implement dummy relaxed accessor macros for writes
  ia64: io: implement dummy relaxed accessor macros for writes
  m32r: io: implement dummy relaxed accessor macros for writes
  m68k: io: implement dummy relaxed accessor macros for writes
  mn10300: io: implement dummy relaxed accessor macros for writes
  parisc: io: implement dummy relaxed accessor macros for writes
  powerpc: io: implement dummy relaxed accessor macros for writes
  sparc: io: implement dummy relaxed accessor macros for writes
  tile: io: implement dummy relaxed accessor macros for writes
  x86: io: implement dummy relaxed accessor macros for writes
  documentation: memory-barriers: clarify relaxed io accessor semantics
  asm-generic: io: define relaxed accessor macros unconditionally

 Documentation/memory-barriers.txt | 13 +++++++++----
 arch/cris/include/asm/io.h        |  3 +++
 arch/frv/include/asm/io.h         |  3 +++
 arch/ia64/include/asm/io.h        |  4 ++++
 arch/m32r/include/asm/io.h        |  3 +++
 arch/m68k/include/asm/io.h        |  8 ++++++++
 arch/m68k/include/asm/io_no.h     |  4 ----
 arch/microblaze/include/asm/io.h  |  8 --------
 arch/mn10300/include/asm/io.h     |  4 ++++
 arch/parisc/include/asm/io.h      | 12 ++++++++----
 arch/powerpc/include/asm/io.h     | 12 ++++++++----
 arch/s390/include/asm/io.h        |  5 -----
 arch/sparc/include/asm/io.h       |  9 +++++++++
 arch/sparc/include/asm/io_32.h    |  4 ----
 arch/sparc/include/asm/io_64.h    |  8 ++------
 arch/tile/include/asm/io.h        |  4 ++++
 arch/x86/include/asm/io.h         |  4 ++++
 arch/xtensa/include/asm/io.h      |  7 -------
 include/asm-generic/io.h          | 10 ++++++++++
 19 files changed, 79 insertions(+), 46 deletions(-)

-- 
2.1.0

[PATCH v3 01/17] asm-generic: io: implement relaxed accessor macros as conditional wrappers

[Will Deacon]

{read,write}{b,w,l,q}_relaxed are implemented by some architectures in
order to permit memory-mapped I/O accesses with weaker barrier semantics
than the non-relaxed variants.

This patch adds wrappers to asm-generic so that drivers can rely on the
relaxed accessors being available, even if they don't always provide
weaker ordering guarantees. Since some architectures both include
asm-generic/io.h and define some relaxed accessors, the definitions here
are conditional for the time being.

Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 include/asm-generic/io.h | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 975e1cc75edb..9ccedeb06522 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -53,18 +53,27 @@ static inline u32 __raw_readl(const volatile void __iomem *addr)
 #endif
 
 #define readb __raw_readb
+#ifndef readb_relaxed
+#define readb_relaxed readb
+#endif
 
 #define readw readw
 static inline u16 readw(const volatile void __iomem *addr)
 {
 	return __le16_to_cpu(__raw_readw(addr));
 }
+#ifndef readw_relaxed
+#define readw_relaxed readw
+#endif
 
 #define readl readl
 static inline u32 readl(const volatile void __iomem *addr)
 {
 	return __le32_to_cpu(__raw_readl(addr));
 }
+#ifndef readl_relaxed
+#define readl_relaxed readl
+#endif
 
 #ifndef __raw_writeb
 static inline void __raw_writeb(u8 b, volatile void __iomem *addr)
@@ -88,8 +97,19 @@ static inline void __raw_writel(u32 b, volatile void __iomem *addr)
 #endif
 
 #define writeb __raw_writeb
+#ifndef writeb_relaxed
+#define writeb_relaxed writeb
+#endif
+
 #define writew(b,addr) __raw_writew(__cpu_to_le16(b),addr)
+#ifndef writew_relaxed
+#define writew_relaxed writew
+#endif
+
 #define writel(b,addr) __raw_writel(__cpu_to_le32(b),addr)
+#ifndef writel_relaxed
+#define writel_relaxed writel
+#endif
 
 #ifdef CONFIG_64BIT
 #ifndef __raw_readq
@@ -104,6 +124,9 @@ static inline u64 readq(const volatile void __iomem *addr)
 {
 	return __le64_to_cpu(__raw_readq(addr));
 }
+#ifndef readq_relaxed
+#define readq_relaxed readq
+#endif
 
 #ifndef __raw_writeq
 static inline void __raw_writeq(u64 b, volatile void __iomem *addr)
@@ -113,6 +136,9 @@ static inline void __raw_writeq(u64 b, volatile void __iomem *addr)
 #endif
 
 #define writeq(b, addr) __raw_writeq(__cpu_to_le64(b), addr)
+#ifndef writeq_relaxed
+#define writeq_relaxed writeq
+#endif
 #endif /* CONFIG_64BIT */
 
 #ifndef PCI_IOBASE
-- 
2.1.0

Re: [PATCH v3 01/17] asm-generic: io: implement relaxed accessor macros as conditional wrappers

[Arnd Bergmann]

On Wednesday 24 September 2014 18:17:20 Will Deacon wrote:
> {read,write}{b,w,l,q}_relaxed are implemented by some architectures in
> order to permit memory-mapped I/O accesses with weaker barrier semantics
> than the non-relaxed variants.
> 
> This patch adds wrappers to asm-generic so that drivers can rely on the
> relaxed accessors being available, even if they don't always provide
> weaker ordering guarantees. Since some architectures both include
> asm-generic/io.h and define some relaxed accessors, the definitions here
> are conditional for the time being.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  include/asm-generic/io.h | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 

Acked-by: Arnd Bergmann <arnd@arndb.de>

Re: [PATCH v3 01/17] asm-generic: io: implement relaxed accessor macros as conditional wrappers

[Will Deacon]

On Thu, Sep 25, 2014 at 11:32:00AM +0100, Arnd Bergmann wrote:
> On Wednesday 24 September 2014 18:17:20 Will Deacon wrote:
> > {read,write}{b,w,l,q}_relaxed are implemented by some architectures in
> > order to permit memory-mapped I/O accesses with weaker barrier semantics
> > than the non-relaxed variants.
> > 
> > This patch adds wrappers to asm-generic so that drivers can rely on the
> > relaxed accessors being available, even if they don't always provide
> > weaker ordering guarantees. Since some architectures both include
> > asm-generic/io.h and define some relaxed accessors, the definitions here
> > are conditional for the time being.
> > 
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> >  include/asm-generic/io.h | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> > 
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Thanks, Arnd. Do you have other patches queued for asm-generic, or shall I
take this patch (on its own) via the arm64 tree?

Will

Re: [PATCH v3 01/17] asm-generic: io: implement relaxed accessor macros as conditional wrappers

[Will Deacon]

On Thu, Sep 25, 2014 at 11:32:00AM +0100, Arnd Bergmann wrote:
> On Wednesday 24 September 2014 18:17:20 Will Deacon wrote:
> > {read,write}{b,w,l,q}_relaxed are implemented by some architectures in
> > order to permit memory-mapped I/O accesses with weaker barrier semantics
> > than the non-relaxed variants.
> > 
> > This patch adds wrappers to asm-generic so that drivers can rely on the
> > relaxed accessors being available, even if they don't always provide
> > weaker ordering guarantees. Since some architectures both include
> > asm-generic/io.h and define some relaxed accessors, the definitions here
> > are conditional for the time being.
> > 
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> >  include/asm-generic/io.h | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> > 
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Thanks, Arnd. Do you have other patches queued for asm-generic, or shall I
take this patch (on its own) via the arm64 tree?

Will

Re: [PATCH v3 01/17] asm-generic: io: implement relaxed accessor macros as conditional wrappers

[Arnd Bergmann]

On Thursday 25 September 2014 11:38:46 Will Deacon wrote:
> On Thu, Sep 25, 2014 at 11:32:00AM +0100, Arnd Bergmann wrote:
> > On Wednesday 24 September 2014 18:17:20 Will Deacon wrote:
> > > {read,write}{b,w,l,q}_relaxed are implemented by some architectures in
> > > order to permit memory-mapped I/O accesses with weaker barrier semantics
> > > than the non-relaxed variants.
> > > 
> > > This patch adds wrappers to asm-generic so that drivers can rely on the
> > > relaxed accessors being available, even if they don't always provide
> > > weaker ordering guarantees. Since some architectures both include
> > > asm-generic/io.h and define some relaxed accessors, the definitions here
> > > are conditional for the time being.
> > > 
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > ---
> > >  include/asm-generic/io.h | 26 ++++++++++++++++++++++++++
> > >  1 file changed, 26 insertions(+)
> > > 
> > 
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> Thanks, Arnd. Do you have other patches queued for asm-generic, or shall I
> take this patch (on its own) via the arm64 tree?

I don't have other patches queued up yet, but Thierry has another patch
for asm-generic/io.h that I want to merge, so this time I'd prefer to
take it through my tree in case there are conflicts.

	Arnd

Re: [PATCH v3 01/17] asm-generic: io: implement relaxed accessor macros as conditional wrappers

[Arnd Bergmann]

On Thursday 25 September 2014 11:38:46 Will Deacon wrote:
> On Thu, Sep 25, 2014 at 11:32:00AM +0100, Arnd Bergmann wrote:
> > On Wednesday 24 September 2014 18:17:20 Will Deacon wrote:
> > > {read,write}{b,w,l,q}_relaxed are implemented by some architectures in
> > > order to permit memory-mapped I/O accesses with weaker barrier semantics
> > > than the non-relaxed variants.
> > > 
> > > This patch adds wrappers to asm-generic so that drivers can rely on the
> > > relaxed accessors being available, even if they don't always provide
> > > weaker ordering guarantees. Since some architectures both include
> > > asm-generic/io.h and define some relaxed accessors, the definitions here
> > > are conditional for the time being.
> > > 
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > ---
> > >  include/asm-generic/io.h | 26 ++++++++++++++++++++++++++
> > >  1 file changed, 26 insertions(+)
> > > 
> > 
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> Thanks, Arnd. Do you have other patches queued for asm-generic, or shall I
> take this patch (on its own) via the arm64 tree?

I don't have other patches queued up yet, but Thierry has another patch
for asm-generic/io.h that I want to merge, so this time I'd prefer to
take it through my tree in case there are conflicts.

	Arnd

Re: [PATCH v3 01/17] asm-generic: io: implement relaxed accessor macros as conditional wrappers

[Will Deacon]

On Thu, Sep 25, 2014 at 11:43:41AM +0100, Arnd Bergmann wrote:
> On Thursday 25 September 2014 11:38:46 Will Deacon wrote:
> > On Thu, Sep 25, 2014 at 11:32:00AM +0100, Arnd Bergmann wrote:
> > > On Wednesday 24 September 2014 18:17:20 Will Deacon wrote:
> > > > {read,write}{b,w,l,q}_relaxed are implemented by some architectures in
> > > > order to permit memory-mapped I/O accesses with weaker barrier semantics
> > > > than the non-relaxed variants.
> > > > 
> > > > This patch adds wrappers to asm-generic so that drivers can rely on the
> > > > relaxed accessors being available, even if they don't always provide
> > > > weaker ordering guarantees. Since some architectures both include
> > > > asm-generic/io.h and define some relaxed accessors, the definitions here
> > > > are conditional for the time being.
> > > > 
> > > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > > ---
> > > >  include/asm-generic/io.h | 26 ++++++++++++++++++++++++++
> > > >  1 file changed, 26 insertions(+)
> > > > 
> > > 
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > 
> > Thanks, Arnd. Do you have other patches queued for asm-generic, or shall I
> > take this patch (on its own) via the arm64 tree?
> 
> I don't have other patches queued up yet, but Thierry has another patch
> for asm-generic/io.h that I want to merge, so this time I'd prefer to
> take it through my tree in case there are conflicts.

Ok, suits me. I'll drop this from my series when it hits mainline.

Will

Re: [PATCH v3 01/17] asm-generic: io: implement relaxed accessor macros as conditional wrappers

[Will Deacon]

On Thu, Sep 25, 2014 at 11:43:41AM +0100, Arnd Bergmann wrote:
> On Thursday 25 September 2014 11:38:46 Will Deacon wrote:
> > On Thu, Sep 25, 2014 at 11:32:00AM +0100, Arnd Bergmann wrote:
> > > On Wednesday 24 September 2014 18:17:20 Will Deacon wrote:
> > > > {read,write}{b,w,l,q}_relaxed are implemented by some architectures in
> > > > order to permit memory-mapped I/O accesses with weaker barrier semantics
> > > > than the non-relaxed variants.
> > > > 
> > > > This patch adds wrappers to asm-generic so that drivers can rely on the
> > > > relaxed accessors being available, even if they don't always provide
> > > > weaker ordering guarantees. Since some architectures both include
> > > > asm-generic/io.h and define some relaxed accessors, the definitions here
> > > > are conditional for the time being.
> > > > 
> > > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > > ---
> > > >  include/asm-generic/io.h | 26 ++++++++++++++++++++++++++
> > > >  1 file changed, 26 insertions(+)
> > > > 
> > > 
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > 
> > Thanks, Arnd. Do you have other patches queued for asm-generic, or shall I
> > take this patch (on its own) via the arm64 tree?
> 
> I don't have other patches queued up yet, but Thierry has another patch
> for asm-generic/io.h that I want to merge, so this time I'd prefer to
> take it through my tree in case there are conflicts.

Ok, suits me. I'll drop this from my series when it hits mainline.

Will

[PATCH v3 02/17] microblaze: io: remove dummy relaxed accessor macros

[Will Deacon]

These are now defined by asm-generic/io.h, so we don't need the private
definitions anymore.

Acked-by: Michal Simek <monstr@monstr.eu>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/microblaze/include/asm/io.h | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/microblaze/include/asm/io.h b/arch/microblaze/include/asm/io.h
index 433751b2a003..940f5fc1d1da 100644
--- a/arch/microblaze/include/asm/io.h
+++ b/arch/microblaze/include/asm/io.h
@@ -69,12 +69,4 @@ extern void __iomem *ioremap(phys_addr_t address, unsigned long size);
 
 #include <asm-generic/io.h>
 
-#define readb_relaxed	readb
-#define readw_relaxed	readw
-#define readl_relaxed	readl
-
-#define writeb_relaxed	writeb
-#define writew_relaxed	writew
-#define writel_relaxed	writel
-
 #endif /* _ASM_MICROBLAZE_IO_H */
-- 
2.1.0

[PATCH v3 03/17] s390: io: remove dummy relaxed accessor macros for reads

[Will Deacon]

These are now defined by asm-generic/io.h, so we don't need the private
definitions anymore.

Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/s390/include/asm/io.h | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h
index cd6b9ee7b69c..722befdf8332 100644
--- a/arch/s390/include/asm/io.h
+++ b/arch/s390/include/asm/io.h
@@ -60,11 +60,6 @@ static inline void iounmap(volatile void __iomem *addr)
 #define __raw_writel	zpci_write_u32
 #define __raw_writeq	zpci_write_u64
 
-#define readb_relaxed	readb
-#define readw_relaxed	readw
-#define readl_relaxed	readl
-#define readq_relaxed	readq
-
 #endif /* CONFIG_PCI */
 
 #include <asm-generic/io.h>
-- 
2.1.0

[PATCH v3 04/17] xtensa: io: remove dummy relaxed accessor macros for reads

[Will Deacon]

These are now defined by asm-generic/io.h, so we don't need the private
definitions anymore.

Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/xtensa/include/asm/io.h | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/arch/xtensa/include/asm/io.h b/arch/xtensa/include/asm/io.h
index 74944207167e..fe1600a09438 100644
--- a/arch/xtensa/include/asm/io.h
+++ b/arch/xtensa/include/asm/io.h
@@ -74,13 +74,6 @@ static inline void iounmap(volatile void __iomem *addr)
 
 #endif /* CONFIG_MMU */
 
-/*
- * Generic I/O
- */
-#define readb_relaxed readb
-#define readw_relaxed readw
-#define readl_relaxed readl
-
 #endif	/* __KERNEL__ */
 
 #include <asm-generic/io.h>
-- 
2.1.0

Re: [PATCH v3 04/17] xtensa: io: remove dummy relaxed accessor macros for reads

[Max Filippov]

On Wed, Sep 24, 2014 at 9:17 PM, Will Deacon <will.deacon@arm.com> wrote:
> These are now defined by asm-generic/io.h, so we don't need the private
> definitions anymore.
>
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  arch/xtensa/include/asm/io.h | 7 -------
>  1 file changed, 7 deletions(-)

Acked-by: Max Filippov <jcmvbkbc@gmail.com>

-- 
Thanks.
-- Max

Re: [PATCH v3 04/17] xtensa: io: remove dummy relaxed accessor macros for reads

[Max Filippov]

On Wed, Sep 24, 2014 at 9:17 PM, Will Deacon <will.deacon@arm.com> wrote:
> These are now defined by asm-generic/io.h, so we don't need the private
> definitions anymore.
>
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  arch/xtensa/include/asm/io.h | 7 -------
>  1 file changed, 7 deletions(-)

Acked-by: Max Filippov <jcmvbkbc@gmail.com>

-- 
Thanks.
-- Max

[PATCH v3 05/17] frv: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to frv, in the same
vein as the dummy definitions for the relaxed read accessors.

Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/frv/include/asm/io.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index 8cb50a2fbcb2..99bb7efaf9b7 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -243,6 +243,9 @@ static inline void writel(uint32_t datum, volatile void __iomem *addr)
 		__flush_PCI_writes();
 }
 
+#define writeb_relaxed writeb
+#define writew_relaxed writew
+#define writel_relaxed writel
 
 /* Values for nocacheflag and cmode */
 #define IOMAP_FULL_CACHING		0
-- 
2.1.0

[PATCH v3 06/17] cris: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to Cris, in the same
vein as the dummy definitions for the relaxed read accessors.

Cc: Mikael Starvik <starvik@axis.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/cris/include/asm/io.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/cris/include/asm/io.h b/arch/cris/include/asm/io.h
index e59dba12ce94..752a3f45df60 100644
--- a/arch/cris/include/asm/io.h
+++ b/arch/cris/include/asm/io.h
@@ -112,6 +112,9 @@ static inline void writel(unsigned int b, volatile void __iomem *addr)
 	else
 		*(volatile unsigned int __force *) addr = b;
 }
+#define writeb_relaxed(b, addr) writeb(b, addr)
+#define writew_relaxed(b, addr) writew(b, addr)
+#define writel_relaxed(b, addr) writel(b, addr)
 #define __raw_writeb writeb
 #define __raw_writew writew
 #define __raw_writel writel
-- 
2.1.0

[PATCH v3 07/17] ia64: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to ia64, which may
be able to be optimised in a similar manner to the relaxed read
accessors at a later date.

Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/ia64/include/asm/io.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
index bee0acd52f7e..80a7e34be009 100644
--- a/arch/ia64/include/asm/io.h
+++ b/arch/ia64/include/asm/io.h
@@ -393,6 +393,10 @@ __writeq (unsigned long val, volatile void __iomem *addr)
 #define writew(v,a)	__writew((v), (a))
 #define writel(v,a)	__writel((v), (a))
 #define writeq(v,a)	__writeq((v), (a))
+#define writeb_relaxed(v,a)	__writeb((v), (a))
+#define writew_relaxed(v,a)	__writew((v), (a))
+#define writel_relaxed(v,a)	__writel((v), (a))
+#define writeq_relaxed(v,a)	__writeq((v), (a))
 #define __raw_writeb	writeb
 #define __raw_writew	writew
 #define __raw_writel	writel
-- 
2.1.0

[PATCH v3 08/17] m32r: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to m32r, in the
same vein as the dummy definitions for the relaxed read accessors.

Cc: Hirokazu Takata <takata@linux-m32r.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/m32r/include/asm/io.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 4010f1fc5b65..6e7787f3dac7 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -161,6 +161,9 @@ static inline void _writel(unsigned long l, unsigned long addr)
 #define __raw_writeb writeb
 #define __raw_writew writew
 #define __raw_writel writel
+#define writeb_relaxed writeb
+#define writew_relaxed writew
+#define writel_relaxed writel
 
 #define ioread8 read
 #define ioread16 readw
-- 
2.1.0

[PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to m68k, in the
same vein as the dummy definitions for the relaxed read accessors.
Additionally, the existing relaxed read accessors are moved into
asm/io.h, so that they can be used by m68k targets with an MMU.

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/m68k/include/asm/io.h    | 8 ++++++++
 arch/m68k/include/asm/io_no.h | 4 ----
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index c70cc9155003..bccd5a914eb6 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -3,3 +3,11 @@
 #else
 #include <asm/io_mm.h>
 #endif
+
+#define readb_relaxed(addr)	readb(addr)
+#define readw_relaxed(addr)	readw(addr)
+#define readl_relaxed(addr)	readl(addr)
+
+#define writeb_relaxed(b, addr)	writeb(b, addr)
+#define writew_relaxed(b, addr)	writew(b, addr)
+#define writel_relaxed(b, addr)	writel(b, addr)
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 52f7e8499172..19c237c63dc2 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -40,10 +40,6 @@ static inline unsigned int _swapl(volatile unsigned long v)
 #define readl(addr) \
     ({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
 
-#define readb_relaxed(addr) readb(addr)
-#define readw_relaxed(addr) readw(addr)
-#define readl_relaxed(addr) readl(addr)
-
 #define writeb(b,addr) (void)((*(volatile unsigned char *) (addr)) = (b))
 #define writew(b,addr) (void)((*(volatile unsigned short *) (addr)) = (b))
 #define writel(b,addr) (void)((*(volatile unsigned int *) (addr)) = (b))
-- 
2.1.0

Re: [PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

[Greg Ungerer]

Hi Will

On 25/09/14 03:17, Will Deacon wrote:
> write{b,w,l}_relaxed are implemented by some architectures in order to
> permit memory-mapped I/O accesses with weaker barrier semantics than the
> non-relaxed variants.
> 
> This patch adds dummy macros for the write accessors to m68k, in the
> same vein as the dummy definitions for the relaxed read accessors.
> Additionally, the existing relaxed read accessors are moved into
> asm/io.h, so that they can be used by m68k targets with an MMU.
> 
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  arch/m68k/include/asm/io.h    | 8 ++++++++
>  arch/m68k/include/asm/io_no.h | 4 ----
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
> index c70cc9155003..bccd5a914eb6 100644
> --- a/arch/m68k/include/asm/io.h
> +++ b/arch/m68k/include/asm/io.h
> @@ -3,3 +3,11 @@
>  #else
>  #include <asm/io_mm.h>
>  #endif
> +
> +#define readb_relaxed(addr)	readb(addr)
> +#define readw_relaxed(addr)	readw(addr)
> +#define readl_relaxed(addr)	readl(addr)
> +
> +#define writeb_relaxed(b, addr)	writeb(b, addr)
> +#define writew_relaxed(b, addr)	writew(b, addr)
> +#define writel_relaxed(b, addr)	writel(b, addr)

Putting them here means they won't have any multiple include protection
(there is no "#ifndef _IO_H" around them). Doesn't seem to lead to
any problems in practice. Just flagging it...

Regards
Greg



> diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
> index 52f7e8499172..19c237c63dc2 100644
> --- a/arch/m68k/include/asm/io_no.h
> +++ b/arch/m68k/include/asm/io_no.h
> @@ -40,10 +40,6 @@ static inline unsigned int _swapl(volatile unsigned long v)
>  #define readl(addr) \
>      ({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
>  
> -#define readb_relaxed(addr) readb(addr)
> -#define readw_relaxed(addr) readw(addr)
> -#define readl_relaxed(addr) readl(addr)
> -
>  #define writeb(b,addr) (void)((*(volatile unsigned char *) (addr)) = (b))
>  #define writew(b,addr) (void)((*(volatile unsigned short *) (addr)) = (b))
>  #define writel(b,addr) (void)((*(volatile unsigned int *) (addr)) = (b))
> 

Re: [PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

[Greg Ungerer]

Hi Will

On 25/09/14 03:17, Will Deacon wrote:
> write{b,w,l}_relaxed are implemented by some architectures in order to
> permit memory-mapped I/O accesses with weaker barrier semantics than the
> non-relaxed variants.
> 
> This patch adds dummy macros for the write accessors to m68k, in the
> same vein as the dummy definitions for the relaxed read accessors.
> Additionally, the existing relaxed read accessors are moved into
> asm/io.h, so that they can be used by m68k targets with an MMU.
> 
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  arch/m68k/include/asm/io.h    | 8 ++++++++
>  arch/m68k/include/asm/io_no.h | 4 ----
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
> index c70cc9155003..bccd5a914eb6 100644
> --- a/arch/m68k/include/asm/io.h
> +++ b/arch/m68k/include/asm/io.h
> @@ -3,3 +3,11 @@
>  #else
>  #include <asm/io_mm.h>
>  #endif
> +
> +#define readb_relaxed(addr)	readb(addr)
> +#define readw_relaxed(addr)	readw(addr)
> +#define readl_relaxed(addr)	readl(addr)
> +
> +#define writeb_relaxed(b, addr)	writeb(b, addr)
> +#define writew_relaxed(b, addr)	writew(b, addr)
> +#define writel_relaxed(b, addr)	writel(b, addr)

Putting them here means they won't have any multiple include protection
(there is no "#ifndef _IO_H" around them). Doesn't seem to lead to
any problems in practice. Just flagging it...

Regards
Greg



> diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
> index 52f7e8499172..19c237c63dc2 100644
> --- a/arch/m68k/include/asm/io_no.h
> +++ b/arch/m68k/include/asm/io_no.h
> @@ -40,10 +40,6 @@ static inline unsigned int _swapl(volatile unsigned long v)
>  #define readl(addr) \
>      ({ unsigned int __v = (*(volatile unsigned int *) (addr)); __v; })
>  
> -#define readb_relaxed(addr) readb(addr)
> -#define readw_relaxed(addr) readw(addr)
> -#define readl_relaxed(addr) readl(addr)
> -
>  #define writeb(b,addr) (void)((*(volatile unsigned char *) (addr)) = (b))
>  #define writew(b,addr) (void)((*(volatile unsigned short *) (addr)) = (b))
>  #define writel(b,addr) (void)((*(volatile unsigned int *) (addr)) = (b))
> 

Re: [PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

On Thu, Sep 25, 2014 at 02:05:43AM +0100, Greg Ungerer wrote:
> Hi Will

Hi Greg,

Thanks for taking a look.

> On 25/09/14 03:17, Will Deacon wrote:
> > write{b,w,l}_relaxed are implemented by some architectures in order to
> > permit memory-mapped I/O accesses with weaker barrier semantics than the
> > non-relaxed variants.
> > 
> > This patch adds dummy macros for the write accessors to m68k, in the
> > same vein as the dummy definitions for the relaxed read accessors.
> > Additionally, the existing relaxed read accessors are moved into
> > asm/io.h, so that they can be used by m68k targets with an MMU.
> > 
> > Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> >  arch/m68k/include/asm/io.h    | 8 ++++++++
> >  arch/m68k/include/asm/io_no.h | 4 ----
> >  2 files changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
> > index c70cc9155003..bccd5a914eb6 100644
> > --- a/arch/m68k/include/asm/io.h
> > +++ b/arch/m68k/include/asm/io.h
> > @@ -3,3 +3,11 @@
> >  #else
> >  #include <asm/io_mm.h>
> >  #endif
> > +
> > +#define readb_relaxed(addr)	readb(addr)
> > +#define readw_relaxed(addr)	readw(addr)
> > +#define readl_relaxed(addr)	readl(addr)
> > +
> > +#define writeb_relaxed(b, addr)	writeb(b, addr)
> > +#define writew_relaxed(b, addr)	writew(b, addr)
> > +#define writel_relaxed(b, addr)	writel(b, addr)
> 
> Putting them here means they won't have any multiple include protection
> (there is no "#ifndef _IO_H" around them). Doesn't seem to lead to
> any problems in practice. Just flagging it...

That's easy enough to fix, and actually, we should have __KERNEL__ checks
here too. Fixup below.

Will

--->8

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index bccd5a914eb6..ded201916560 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -1,9 +1,14 @@
+#ifndef _M68K_IO_H
+#define _M68K_IO_H
+
 #ifdef __uClinux__
 #include <asm/io_no.h>
 #else
 #include <asm/io_mm.h>
 #endif
 
+#ifdef __KERNEL__
+
 #define readb_relaxed(addr)    readb(addr)
 #define readw_relaxed(addr)    readw(addr)
 #define readl_relaxed(addr)    readl(addr)
@@ -11,3 +16,6 @@
 #define writeb_relaxed(b, addr)        writeb(b, addr)
 #define writew_relaxed(b, addr)        writew(b, addr)
 #define writel_relaxed(b, addr)        writel(b, addr)
+
+#endif /* __KERNEL__ */
+#endif /* _M68K_IO_H */

Re: [PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

On Thu, Sep 25, 2014 at 02:05:43AM +0100, Greg Ungerer wrote:
> Hi Will

Hi Greg,

Thanks for taking a look.

> On 25/09/14 03:17, Will Deacon wrote:
> > write{b,w,l}_relaxed are implemented by some architectures in order to
> > permit memory-mapped I/O accesses with weaker barrier semantics than the
> > non-relaxed variants.
> > 
> > This patch adds dummy macros for the write accessors to m68k, in the
> > same vein as the dummy definitions for the relaxed read accessors.
> > Additionally, the existing relaxed read accessors are moved into
> > asm/io.h, so that they can be used by m68k targets with an MMU.
> > 
> > Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> >  arch/m68k/include/asm/io.h    | 8 ++++++++
> >  arch/m68k/include/asm/io_no.h | 4 ----
> >  2 files changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
> > index c70cc9155003..bccd5a914eb6 100644
> > --- a/arch/m68k/include/asm/io.h
> > +++ b/arch/m68k/include/asm/io.h
> > @@ -3,3 +3,11 @@
> >  #else
> >  #include <asm/io_mm.h>
> >  #endif
> > +
> > +#define readb_relaxed(addr)	readb(addr)
> > +#define readw_relaxed(addr)	readw(addr)
> > +#define readl_relaxed(addr)	readl(addr)
> > +
> > +#define writeb_relaxed(b, addr)	writeb(b, addr)
> > +#define writew_relaxed(b, addr)	writew(b, addr)
> > +#define writel_relaxed(b, addr)	writel(b, addr)
> 
> Putting them here means they won't have any multiple include protection
> (there is no "#ifndef _IO_H" around them). Doesn't seem to lead to
> any problems in practice. Just flagging it...

That's easy enough to fix, and actually, we should have __KERNEL__ checks
here too. Fixup below.

Will

--->8

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index bccd5a914eb6..ded201916560 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -1,9 +1,14 @@
+#ifndef _M68K_IO_H
+#define _M68K_IO_H
+
 #ifdef __uClinux__
 #include <asm/io_no.h>
 #else
 #include <asm/io_mm.h>
 #endif
 
+#ifdef __KERNEL__
+
 #define readb_relaxed(addr)    readb(addr)
 #define readw_relaxed(addr)    readw(addr)
 #define readl_relaxed(addr)    readl(addr)
@@ -11,3 +16,6 @@
 #define writeb_relaxed(b, addr)        writeb(b, addr)
 #define writew_relaxed(b, addr)        writew(b, addr)
 #define writel_relaxed(b, addr)        writel(b, addr)
+
+#endif /* __KERNEL__ */
+#endif /* _M68K_IO_H */

Re: [PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

[Geert Uytterhoeven]

On Thu, Sep 25, 2014 at 11:33 AM, Will Deacon <will.deacon@arm.com> wrote:
>> Putting them here means they won't have any multiple include protection
>> (there is no "#ifndef _IO_H" around them). Doesn't seem to lead to
>> any problems in practice. Just flagging it...
>
> That's easy enough to fix, and actually, we should have __KERNEL__ checks
> here too. Fixup below.

Why do we need __KERNEL__ checks? <asm/io.h> is not exported.
BTW, it seems there are many __KERNEL__ checks in arch/*/include/asm/
we don't need.

Or do I need more coffee?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

[Geert Uytterhoeven]

On Thu, Sep 25, 2014 at 11:33 AM, Will Deacon <will.deacon@arm.com> wrote:
>> Putting them here means they won't have any multiple include protection
>> (there is no "#ifndef _IO_H" around them). Doesn't seem to lead to
>> any problems in practice. Just flagging it...
>
> That's easy enough to fix, and actually, we should have __KERNEL__ checks
> here too. Fixup below.

Why do we need __KERNEL__ checks? <asm/io.h> is not exported.
BTW, it seems there are many __KERNEL__ checks in arch/*/include/asm/
we don't need.

Or do I need more coffee?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

On Thu, Sep 25, 2014 at 10:51:10AM +0100, Geert Uytterhoeven wrote:
> On Thu, Sep 25, 2014 at 11:33 AM, Will Deacon <will.deacon@arm.com> wrote:
> >> Putting them here means they won't have any multiple include protection
> >> (there is no "#ifndef _IO_H" around them). Doesn't seem to lead to
> >> any problems in practice. Just flagging it...
> >
> > That's easy enough to fix, and actually, we should have __KERNEL__ checks
> > here too. Fixup below.
> 
> Why do we need __KERNEL__ checks? <asm/io.h> is not exported.
> BTW, it seems there are many __KERNEL__ checks in arch/*/include/asm/
> we don't need.
> 
> Or do I need more coffee?

No, I think you're quite right. I just saw the __KERNEL__ checks in io_no.h
and io_mm.h -- the latter even has some code outside of the guards:


#endif /* __KERNEL__ */

#define __ARCH_HAS_NO_PAGE_ZERO_MAPPED		1

/*
 * Convert a physical pointer to a virtual kernel pointer for /dev/mem
 * access
 */
#define xlate_dev_mem_ptr(p)	__va(p)

/*
 * Convert a virtual cached pointer to an uncached pointer
 */
#define xlate_dev_kmem_ptr(p)	p

#define ioport_map(port, nr)	((void __iomem *)(port))

#endif /* _IO_H */


Will

Re: [PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

On Thu, Sep 25, 2014 at 10:51:10AM +0100, Geert Uytterhoeven wrote:
> On Thu, Sep 25, 2014 at 11:33 AM, Will Deacon <will.deacon@arm.com> wrote:
> >> Putting them here means they won't have any multiple include protection
> >> (there is no "#ifndef _IO_H" around them). Doesn't seem to lead to
> >> any problems in practice. Just flagging it...
> >
> > That's easy enough to fix, and actually, we should have __KERNEL__ checks
> > here too. Fixup below.
> 
> Why do we need __KERNEL__ checks? <asm/io.h> is not exported.
> BTW, it seems there are many __KERNEL__ checks in arch/*/include/asm/
> we don't need.
> 
> Or do I need more coffee?

No, I think you're quite right. I just saw the __KERNEL__ checks in io_no.h
and io_mm.h -- the latter even has some code outside of the guards:


#endif /* __KERNEL__ */

#define __ARCH_HAS_NO_PAGE_ZERO_MAPPED		1

/*
 * Convert a physical pointer to a virtual kernel pointer for /dev/mem
 * access
 */
#define xlate_dev_mem_ptr(p)	__va(p)

/*
 * Convert a virtual cached pointer to an uncached pointer
 */
#define xlate_dev_kmem_ptr(p)	p

#define ioport_map(port, nr)	((void __iomem *)(port))

#endif /* _IO_H */


Will

[PATCH v3 10/17] mn10300: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to mn10300, in the
same vein as the dummy definitions for the relaxed read accessors.

Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/mn10300/include/asm/io.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/mn10300/include/asm/io.h b/arch/mn10300/include/asm/io.h
index e6ed0d897ccc..897ba3c12b32 100644
--- a/arch/mn10300/include/asm/io.h
+++ b/arch/mn10300/include/asm/io.h
@@ -67,6 +67,10 @@ static inline void writel(u32 b, volatile void __iomem *addr)
 #define __raw_writew writew
 #define __raw_writel writel
 
+#define writeb_relaxed writeb
+#define writew_relaxed writew
+#define writel_relaxed writel
+
 /*****************************************************************************/
 /*
  * traditional input/output functions
-- 
2.1.0

[PATCH v3 11/17] parisc: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to parisc, in the
same vein as the dummy definitions for the relaxed read accessors.

Cc: Helge Deller <deller@gmx.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/parisc/include/asm/io.h | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/parisc/include/asm/io.h b/arch/parisc/include/asm/io.h
index 1f6d2ae7aba5..8cd0abf28ffb 100644
--- a/arch/parisc/include/asm/io.h
+++ b/arch/parisc/include/asm/io.h
@@ -217,10 +217,14 @@ static inline void writeq(unsigned long long q, volatile void __iomem *addr)
 #define writel	writel
 #define writeq	writeq
 
-#define readb_relaxed(addr) readb(addr)
-#define readw_relaxed(addr) readw(addr)
-#define readl_relaxed(addr) readl(addr)
-#define readq_relaxed(addr) readq(addr)
+#define readb_relaxed(addr)	readb(addr)
+#define readw_relaxed(addr)	readw(addr)
+#define readl_relaxed(addr)	readl(addr)
+#define readq_relaxed(addr)	readq(addr)
+#define writeb_relaxed(b, addr)	writeb(b, addr)
+#define writew_relaxed(w, addr)	writew(w, addr)
+#define writel_relaxed(l, addr)	writel(l, addr)
+#define writeq_relaxed(q, addr)	writeq(q, addr)
 
 #define mmiowb() do { } while (0)
 
-- 
2.1.0

Re: [PATCH v3 11/17] parisc: io: implement dummy relaxed accessor macros for writes

[Helge Deller]

On 09/24/2014 07:17 PM, Will Deacon wrote:
> This patch adds dummy macros for the write accessors to parisc, in the
> same vein as the dummy definitions for the relaxed read accessors.
>
> Cc: Helge Deller <deller@gmx.de>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>   arch/parisc/include/asm/io.h | 12 ++++++++----
>   1 file changed, 8 insertions(+), 4 deletions(-)

Acked-by: Helge Deller <deller@gmx.de>

Thanks!
Helge

[PATCH v3 12/17] powerpc: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to powerpc, in the
same vein as the dummy definitions for the relaxed read accessors.

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/powerpc/include/asm/io.h | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 97d3869991ca..9eaf301ac952 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -617,10 +617,14 @@ static inline void name at					\
 /*
  * We don't do relaxed operations yet, at least not with this semantic
  */
-#define readb_relaxed(addr) readb(addr)
-#define readw_relaxed(addr) readw(addr)
-#define readl_relaxed(addr) readl(addr)
-#define readq_relaxed(addr) readq(addr)
+#define readb_relaxed(addr)	readb(addr)
+#define readw_relaxed(addr)	readw(addr)
+#define readl_relaxed(addr)	readl(addr)
+#define readq_relaxed(addr)	readq(addr)
+#define writeb_relaxed(v, addr)	writeb(v, addr)
+#define writew_relaxed(v, addr)	writew(v, addr)
+#define writel_relaxed(v, addr)	writel(v, addr)
+#define writeq_relaxed(v, addr)	writeq(v, addr)
 
 #ifdef CONFIG_PPC32
 #define mmiowb()
-- 
2.1.0

[PATCH v3 13/17] sparc: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to sparc, in the
same vein as the dummy definitions for the relaxed read accessors. The
existing relaxed read{b,w,l} accessors are moved into asm/io.h, since
they are identical between 32-bit and 64-bit machines.

Acked-by: "David S. Miller" <davem@davemloft.net>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/sparc/include/asm/io.h    | 9 +++++++++
 arch/sparc/include/asm/io_32.h | 4 ----
 arch/sparc/include/asm/io_64.h | 8 ++------
 3 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/sparc/include/asm/io.h b/arch/sparc/include/asm/io.h
index f6902cf3cbe9..493f22c4684f 100644
--- a/arch/sparc/include/asm/io.h
+++ b/arch/sparc/include/asm/io.h
@@ -10,6 +10,15 @@
  * Defines used for both SPARC32 and SPARC64
  */
 
+/* Relaxed accessors for MMIO */
+#define readb_relaxed(__addr)		readb(__addr)
+#define readw_relaxed(__addr)		readw(__addr)
+#define readl_relaxed(__addr)		readl(__addr)
+
+#define writeb_relaxed(__b, __addr)	writeb(__b, __addr)
+#define writew_relaxed(__w, __addr)	writew(__w, __addr)
+#define writel_relaxed(__l, __addr)	writel(__l, __addr)
+
 /* Big endian versions of memory read/write routines */
 #define readb_be(__addr)	__raw_readb(__addr)
 #define readw_be(__addr)	__raw_readw(__addr)
diff --git a/arch/sparc/include/asm/io_32.h b/arch/sparc/include/asm/io_32.h
index 9f532902627c..407ac14295f4 100644
--- a/arch/sparc/include/asm/io_32.h
+++ b/arch/sparc/include/asm/io_32.h
@@ -4,10 +4,6 @@
 #include <linux/kernel.h>
 #include <linux/ioport.h>  /* struct resource */
 
-#define readb_relaxed(__addr)	readb(__addr)
-#define readw_relaxed(__addr)	readw(__addr)
-#define readl_relaxed(__addr)	readl(__addr)
-
 #define IO_SPACE_LIMIT 0xffffffff
 
 #define memset_io(d,c,sz)     _memset_io(d,c,sz)
diff --git a/arch/sparc/include/asm/io_64.h b/arch/sparc/include/asm/io_64.h
index 80b54b326d49..d50e6127325d 100644
--- a/arch/sparc/include/asm/io_64.h
+++ b/arch/sparc/include/asm/io_64.h
@@ -136,6 +136,7 @@ static inline u32 readl(const volatile void __iomem *addr)
 }
 
 #define readq readq
+#define readq_relaxed readq
 static inline u64 readq(const volatile void __iomem *addr)
 {	u64 ret;
 
@@ -175,6 +176,7 @@ static inline void writel(u32 l, volatile void __iomem *addr)
 }
 
 #define writeq writeq
+#define writeq_relaxed writeq
 static inline void writeq(u64 q, volatile void __iomem *addr)
 {
 	__asm__ __volatile__("stxa\t%r0, [%1] %2\t/* pci_writeq */"
@@ -183,7 +185,6 @@ static inline void writeq(u64 q, volatile void __iomem *addr)
 			     : "memory");
 }
 
-
 #define inb inb
 static inline u8 inb(unsigned long addr)
 {
@@ -264,11 +265,6 @@ static inline void iowrite32_rep(void __iomem *port, const void *buf, unsigned l
 	outsl((unsigned long __force)port, buf, count);
 }
 
-#define readb_relaxed(__addr)	readb(__addr)
-#define readw_relaxed(__addr)	readw(__addr)
-#define readl_relaxed(__addr)	readl(__addr)
-#define readq_relaxed(__addr)	readq(__addr)
-
 /* Valid I/O Space regions are anywhere, because each PCI bus supported
  * can live in an arbitrary area of the physical address range.
  */
-- 
2.1.0

[PATCH v3 14/17] tile: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to tile, in the
same vein as the dummy definitions for the relaxed read accessors.

Acked-by: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/tile/include/asm/io.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h
index 9fe434969fab..d372641054d9 100644
--- a/arch/tile/include/asm/io.h
+++ b/arch/tile/include/asm/io.h
@@ -241,6 +241,10 @@ static inline void writeq(u64 val, unsigned long addr)
 #define readw_relaxed readw
 #define readl_relaxed readl
 #define readq_relaxed readq
+#define writeb_relaxed writeb
+#define writew_relaxed writew
+#define writel_relaxed writel
+#define writeq_relaxed writeq
 
 #define ioread8 readb
 #define ioread16 readw
-- 
2.1.0

[PATCH v3 15/17] x86: io: implement dummy relaxed accessor macros for writes

[Will Deacon]

write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.

This patch adds dummy macros for the write accessors to x86, in the
same vein as the dummy definitions for the relaxed read accessors.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/x86/include/asm/io.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index b8237d8a1e0c..2ea07f5ec7b7 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -74,6 +74,9 @@ build_mmio_write(__writel, "l", unsigned int, "r", )
 #define __raw_readw __readw
 #define __raw_readl __readl
 
+#define writeb_relaxed(v, a) __writeb(v, a)
+#define writew_relaxed(v, a) __writew(v, a)
+#define writel_relaxed(v, a) __writel(v, a)
 #define __raw_writeb __writeb
 #define __raw_writew __writew
 #define __raw_writel __writel
@@ -86,6 +89,7 @@ build_mmio_read(readq, "q", unsigned long, "=r", :"memory")
 build_mmio_write(writeq, "q", unsigned long, "r", :"memory")
 
 #define readq_relaxed(a)	readq(a)
+#define writeq_relaxed(v, a)	writeq(v, a)
 
 #define __raw_readq(a)		readq(a)
 #define __raw_writeq(val, addr)	writeq(val, addr)
-- 
2.1.0

[PATCH v3 16/17] documentation: memory-barriers: clarify relaxed io accessor semantics

[Will Deacon]

This patch extends the paragraph describing the relaxed read io accessors
so that the relaxed accessors are defined to be:

 - Ordered with respect to each other if accessing the same peripheral

 - Unordered with respect to normal memory accesses

 - Unordered with respect to LOCK/UNLOCK operations

Whilst many architectures will provide stricter semantics, ARM, Alpha and
PPC can achieve significant performance gains by taking advantage of some
or all of the above relaxations.

Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 Documentation/memory-barriers.txt | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index a4de88fb55f0..6b2b4d735a5b 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -2461,10 +2461,15 @@ functions:
      Please refer to the PCI specification for more information on interactions
      between PCI transactions.
 
- (*) readX_relaxed()
-
-     These are similar to readX(), but are not guaranteed to be ordered in any
-     way. Be aware that there is no I/O read barrier available.
+ (*) readX_relaxed(), writeX_relaxed()
+
+     These are similar to readX() and writeX(), but provide weaker memory
+     ordering guarantees. Specifically, they do not guarantee ordering with
+     respect to normal memory accesses (e.g. DMA buffers) nor do they guarantee
+     ordering with respect to LOCK or UNLOCK operations. If the latter is
+     required, an mmiowb() barrier can be used. Note that relaxed accesses to
+     the same peripheral are guaranteed to be ordered with respect to each
+     other.
 
  (*) ioreadX(), iowriteX()
 
-- 
2.1.0

[PATCH v3 17/17] asm-generic: io: define relaxed accessor macros unconditionally

[Will Deacon]

Now that no architectures using asm-generic/io.h define their own relaxed
accessors, the dummy definitions can be used unconditionally.

Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 include/asm-generic/io.h | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 9ccedeb06522..f5611abb82ed 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -53,27 +53,21 @@ static inline u32 __raw_readl(const volatile void __iomem *addr)
 #endif
 
 #define readb __raw_readb
-#ifndef readb_relaxed
 #define readb_relaxed readb
-#endif
 
 #define readw readw
 static inline u16 readw(const volatile void __iomem *addr)
 {
 	return __le16_to_cpu(__raw_readw(addr));
 }
-#ifndef readw_relaxed
 #define readw_relaxed readw
-#endif
 
 #define readl readl
 static inline u32 readl(const volatile void __iomem *addr)
 {
 	return __le32_to_cpu(__raw_readl(addr));
 }
-#ifndef readl_relaxed
 #define readl_relaxed readl
-#endif
 
 #ifndef __raw_writeb
 static inline void __raw_writeb(u8 b, volatile void __iomem *addr)
@@ -97,19 +91,13 @@ static inline void __raw_writel(u32 b, volatile void __iomem *addr)
 #endif
 
 #define writeb __raw_writeb
-#ifndef writeb_relaxed
 #define writeb_relaxed writeb
-#endif
 
 #define writew(b,addr) __raw_writew(__cpu_to_le16(b),addr)
-#ifndef writew_relaxed
 #define writew_relaxed writew
-#endif
 
 #define writel(b,addr) __raw_writel(__cpu_to_le32(b),addr)
-#ifndef writel_relaxed
 #define writel_relaxed writel
-#endif
 
 #ifdef CONFIG_64BIT
 #ifndef __raw_readq
@@ -124,9 +112,7 @@ static inline u64 readq(const volatile void __iomem *addr)
 {
 	return __le64_to_cpu(__raw_readq(addr));
 }
-#ifndef readq_relaxed
 #define readq_relaxed readq
-#endif
 
 #ifndef __raw_writeq
 static inline void __raw_writeq(u64 b, volatile void __iomem *addr)
@@ -136,9 +122,7 @@ static inline void __raw_writeq(u64 b, volatile void __iomem *addr)
 #endif
 
 #define writeq(b, addr) __raw_writeq(__cpu_to_le64(b), addr)
-#ifndef writeq_relaxed
 #define writeq_relaxed writeq
-#endif
 #endif /* CONFIG_64BIT */
 
 #ifndef PCI_IOBASE
-- 
2.1.0

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> 
> This is version three of the series I've originally posted here:
> 
>   v1: https://lkml.org/lkml/2014/4/17/269
>   v2: https://lkml.org/lkml/2014/5/22/468
> 
> This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> (which was merged into mainline).
> 
> I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> quickly got messy as some architectures (e.g. mips) deliberately keep
> mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> drivers to get mmiowb correct, so add barriers to both. Given that
> arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> an architecture that does care.
> 
> In order to get this lot merged, we probably want to merge the asm-generic
> patch (1/17) first, so Acks would be much appreciated on the architecture
> bits.
> 
> As before, I've included the original cover letter below, as that describes
> what I'm trying to do in more detail.
> 

I'm definitely happy to merge that first patch in the asm-generic tree, or
have it go through some other tree along with architecture specific patches.
Anything that helps get these functions across all architectures really.

I don't think there is any controversy about whether or not we should
have the functions, or what the default should be on architectures that
don't provide their own, so I wonder why we can't just add the conditional
definitions to linux/io.h and remove the trivial definitions from
architectures afterwards.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> Hello everybody,
> 
> This is version three of the series I've originally posted here:
> 
>   v1: https://lkml.org/lkml/2014/4/17/269
>   v2: https://lkml.org/lkml/2014/5/22/468
> 
> This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> (which was merged into mainline).
> 
> I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> quickly got messy as some architectures (e.g. mips) deliberately keep
> mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> drivers to get mmiowb correct, so add barriers to both. Given that
> arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> an architecture that does care.
> 
> In order to get this lot merged, we probably want to merge the asm-generic
> patch (1/17) first, so Acks would be much appreciated on the architecture
> bits.
> 
> As before, I've included the original cover letter below, as that describes
> what I'm trying to do in more detail.
> 

I've now applied the parts of your series that are required to have
every architecture provide all the 'relaxed' accessors to the
asm-generic tree, on top of Thierry's series.

I had to change your first patch significantly because all the context
changed in his patches. See below for the new version. Thierry, can
you also confirm that this matches up with the intention of your
series? Since that now adds a separate #ifdef for each symbol, I
ended up putting the #ifdef for the relaxed version inside of the
#ifdef for the non-relaxed version, but it could alternatively
be defined outside of it as well.

The entire series of both Thierry's and Will's changes is now in
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
and should show up in linux-next tomorrow. There are currently
no conflicts against anything else in linux-next.

Since we're rather close to the merge window, I'd probably leave
this in linux-next for a while longer and submit it all for inclusion
in 3.18 in the second week after 3.17.

If anybody still has concerns, please let me know.

	Arnd

---
Thierry Reding (8):
      ARC: Remove redundant PCI_IOBASE declaration
      serial: sunzilog: Remove unnecessary volatile keyword
      sparc: Remove unnecessary volatile usage
      [IA64] Change xlate_dev_{kmem,mem}_ptr() prototypes
      /dev/mem: Use more consistent data types
      asm-generic/io.h: Implement generic {read,write}s*()
      ARM: Use include/asm-generic/io.h
      arm64: Use include/asm-generic/io.h

Will Deacon (13):
      documentation: memory-barriers: clarify relaxed io accessor semantics
      frv: io: implement dummy relaxed accessor macros for writes
      ia64: io: implement dummy relaxed accessor macros for writes
      cris: io: implement dummy relaxed accessor macros for writes
      x86: io: implement dummy relaxed accessor macros for writes
      tile: io: implement dummy relaxed accessor macros for writes
      parisc: io: implement dummy relaxed accessor macros for writes
      m32r: io: implement dummy relaxed accessor macros for writes
      mn10300: io: implement dummy relaxed accessor macros for writes
      powerpc: io: implement dummy relaxed accessor macros for writes
      m68k: io: implement dummy relaxed accessor macros for writes
      sparc: io: implement dummy relaxed accessor macros for writes
      asm-generic: io: implement relaxed accessor macros as conditional wrappers

 Documentation/memory-barriers.txt |  13 +-
 arch/arc/include/asm/io.h         |   2 -
 arch/arm/include/asm/io.h         |  75 +++----
 arch/arm/include/asm/memory.h     |   2 +
 arch/arm64/Kconfig                |   1 -
 arch/arm64/include/asm/io.h       | 122 +++--------
 arch/arm64/include/asm/memory.h   |   2 +
 arch/cris/include/asm/io.h        |   3 +
 arch/frv/include/asm/io.h         |   3 +
 arch/ia64/include/asm/io.h        |   4 +
 arch/ia64/include/asm/uaccess.h   |  16 +-
 arch/m32r/include/asm/io.h        |   3 +
 arch/m68k/include/asm/io.h        |   8 +
 arch/m68k/include/asm/io_no.h     |   4 -
 arch/mn10300/include/asm/io.h     |   4 +
 arch/parisc/include/asm/io.h      |  12 +-
 arch/powerpc/include/asm/io.h     |  12 +-
 arch/s390/include/asm/io.h        |   5 +-
 arch/s390/mm/maccess.c            |   4 +-
 arch/sparc/include/asm/io.h       |   9 +
 arch/sparc/include/asm/io_32.h    |  22 +-
 arch/sparc/include/asm/io_64.h    |   8 +-
 arch/tile/include/asm/io.h        |   4 +
 arch/x86/include/asm/io.h         |   8 +-
 arch/x86/mm/ioremap.c             |   4 +-
 drivers/char/mem.c                |  13 +-
 drivers/tty/serial/sunzilog.h     |   8 +-
 include/asm-generic/io.h          | 705 ++++++++++++++++++++++++++++++++++++++++++++++++++++------------
 28 files changed, 739 insertions(+), 337 deletions(-)


commit 3c8c4968a36c76245fd6dc37648327602106ae11
Author: Will Deacon <will.deacon@arm.com>
Date:   Wed Sep 24 18:17:20 2014 +0100

    asm-generic: io: implement relaxed accessor macros as conditional wrappers
    
    {read,write}{b,w,l,q}_relaxed are implemented by some architectures in
    order to permit memory-mapped I/O accesses with weaker barrier semantics
    than the non-relaxed variants.
    
    This patch adds wrappers to asm-generic so that drivers can rely on the
    relaxed accessors being available, even if they don't always provide
    weaker ordering guarantees. Since some architectures both include
    asm-generic/io.h and define some relaxed accessors, the definitions here
    are conditional for the time being.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 508a57257de5..3344044a7e4f 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -111,6 +111,9 @@ static inline u8 readb(const void __iomem *addr)
 {
 	return __raw_readb(addr);
 }
+#ifndef readb_relaxed
+#define readb_relaxed readb
+#endif
 #endif
 
 #ifndef readw
@@ -119,6 +122,9 @@ static inline u16 readw(const void __iomem *addr)
 {
 	return __le16_to_cpu(__raw_readw(addr));
 }
+#ifndef readw_relaxed
+#define readw_relaxed readw
+#endif
 #endif
 
 #ifndef readl
@@ -127,6 +133,9 @@ static inline u32 readl(const void __iomem *addr)
 {
 	return __le32_to_cpu(__raw_readl(addr));
 }
+#ifndef readl_relaxed
+#define readl_relaxed readl
+#endif
 #endif
 
 #ifdef CONFIG_64BIT
@@ -136,6 +145,9 @@ static inline u64 readq(const void __iomem *addr)
 {
 	return __le64_to_cpu(__raw_readq(addr));
 }
+#ifndef readq_relaxed
+#define readq_relaxed readq
+#endif
 #endif
 #endif /* CONFIG_64BIT */
 
@@ -145,6 +157,9 @@ static inline void writeb(u8 value, void __iomem *addr)
 {
 	__raw_writeb(value, addr);
 }
+#ifndef writeb_relaxed
+#define writeb_relaxed writeb
+#endif
 #endif
 
 #ifndef writew
@@ -153,6 +168,9 @@ static inline void writew(u16 value, void __iomem *addr)
 {
 	__raw_writew(cpu_to_le16(value), addr);
 }
+#ifndef writew_relaxed
+#define writew_relaxed writew
+#endif
 #endif
 
 #ifndef writel
@@ -161,6 +179,9 @@ static inline void writel(u32 value, void __iomem *addr)
 {
 	__raw_writel(__cpu_to_le32(value), addr);
 }
+#ifndef writel_relaxed
+#define writel_relaxed writel
+#endif
 #endif
 
 #ifdef CONFIG_64BIT
@@ -170,6 +191,9 @@ static inline void writeq(u64 value, void __iomem *addr)
 {
 	__raw_writeq(__cpu_to_le64(value), addr);
 }
+#ifndef writeq_relaxed
+#define writeq_relaxed writeq
+#endif
 #endif
 #endif /* CONFIG_64BIT */
 

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Will Deacon]

On Thu, Sep 25, 2014 at 02:15:10PM +0100, Arnd Bergmann wrote:
> On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> > This is version three of the series I've originally posted here:
> > 
> >   v1: https://lkml.org/lkml/2014/4/17/269
> >   v2: https://lkml.org/lkml/2014/5/22/468
> > 
> > This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> > (which was merged into mainline).
> > 
> > I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> > quickly got messy as some architectures (e.g. mips) deliberately keep
> > mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> > drivers to get mmiowb correct, so add barriers to both. Given that
> > arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> > an architecture that does care.
> > 
> > In order to get this lot merged, we probably want to merge the asm-generic
> > patch (1/17) first, so Acks would be much appreciated on the architecture
> > bits.
> > 
> > As before, I've included the original cover letter below, as that describes
> > what I'm trying to do in more detail.
> > 
> 
> I've now applied the parts of your series that are required to have
> every architecture provide all the 'relaxed' accessors to the
> asm-generic tree, on top of Thierry's series.

Brill, thanks Arnd! I'll repost what's left during the next cycle, however
I think you also need to pick the microblaze patch as it includes
<asm-generic/io.h> before defining its relaxed accessors, so I think
you'll get a redefinition warning from the preprocessor.

> I had to change your first patch significantly because all the context
> changed in his patches. See below for the new version. Thierry, can
> you also confirm that this matches up with the intention of your
> series? Since that now adds a separate #ifdef for each symbol, I
> ended up putting the #ifdef for the relaxed version inside of the
> #ifdef for the non-relaxed version, but it could alternatively
> be defined outside of it as well.

I think both work, as I can't find any architectures that define the
relaxed variants but not the non-relaxed versions.

> The entire series of both Thierry's and Will's changes is now in
> git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
> and should show up in linux-next tomorrow. There are currently
> no conflicts against anything else in linux-next.
> 
> Since we're rather close to the merge window, I'd probably leave
> this in linux-next for a while longer and submit it all for inclusion
> in 3.18 in the second week after 3.17.

Makes sense.

Will

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Will Deacon]

On Thu, Sep 25, 2014 at 02:15:10PM +0100, Arnd Bergmann wrote:
> On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> > This is version three of the series I've originally posted here:
> > 
> >   v1: https://lkml.org/lkml/2014/4/17/269
> >   v2: https://lkml.org/lkml/2014/5/22/468
> > 
> > This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> > (which was merged into mainline).
> > 
> > I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> > quickly got messy as some architectures (e.g. mips) deliberately keep
> > mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> > drivers to get mmiowb correct, so add barriers to both. Given that
> > arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> > an architecture that does care.
> > 
> > In order to get this lot merged, we probably want to merge the asm-generic
> > patch (1/17) first, so Acks would be much appreciated on the architecture
> > bits.
> > 
> > As before, I've included the original cover letter below, as that describes
> > what I'm trying to do in more detail.
> > 
> 
> I've now applied the parts of your series that are required to have
> every architecture provide all the 'relaxed' accessors to the
> asm-generic tree, on top of Thierry's series.

Brill, thanks Arnd! I'll repost what's left during the next cycle, however
I think you also need to pick the microblaze patch as it includes
<asm-generic/io.h> before defining its relaxed accessors, so I think
you'll get a redefinition warning from the preprocessor.

> I had to change your first patch significantly because all the context
> changed in his patches. See below for the new version. Thierry, can
> you also confirm that this matches up with the intention of your
> series? Since that now adds a separate #ifdef for each symbol, I
> ended up putting the #ifdef for the relaxed version inside of the
> #ifdef for the non-relaxed version, but it could alternatively
> be defined outside of it as well.

I think both work, as I can't find any architectures that define the
relaxed variants but not the non-relaxed versions.

> The entire series of both Thierry's and Will's changes is now in
> git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
> and should show up in linux-next tomorrow. There are currently
> no conflicts against anything else in linux-next.
> 
> Since we're rather close to the merge window, I'd probably leave
> this in linux-next for a while longer and submit it all for inclusion
> in 3.18 in the second week after 3.17.

Makes sense.

Will

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Thursday 25 September 2014 15:55:38 Will Deacon wrote:
> On Thu, Sep 25, 2014 at 02:15:10PM +0100, Arnd Bergmann wrote:
> > On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> > > This is version three of the series I've originally posted here:
> > > 
> > >   v1: https://lkml.org/lkml/2014/4/17/269
> > >   v2: https://lkml.org/lkml/2014/5/22/468
> > > 
> > > This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> > > (which was merged into mainline).
> > > 
> > > I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> > > quickly got messy as some architectures (e.g. mips) deliberately keep
> > > mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> > > drivers to get mmiowb correct, so add barriers to both. Given that
> > > arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> > > an architecture that does care.
> > > 
> > > In order to get this lot merged, we probably want to merge the asm-generic
> > > patch (1/17) first, so Acks would be much appreciated on the architecture
> > > bits.
> > > 
> > > As before, I've included the original cover letter below, as that describes
> > > what I'm trying to do in more detail.
> > > 
> > 
> > I've now applied the parts of your series that are required to have
> > every architecture provide all the 'relaxed' accessors to the
> > asm-generic tree, on top of Thierry's series.
> 
> Brill, thanks Arnd! I'll repost what's left during the next cycle, however
> I think you also need to pick the microblaze patch as it includes
> <asm-generic/io.h> before defining its relaxed accessors, so I think
> you'll get a redefinition warning from the preprocessor.

Good point, I'll add that on top then.

> > I had to change your first patch significantly because all the context
> > changed in his patches. See below for the new version. Thierry, can
> > you also confirm that this matches up with the intention of your
> > series? Since that now adds a separate #ifdef for each symbol, I
> > ended up putting the #ifdef for the relaxed version inside of the
> > #ifdef for the non-relaxed version, but it could alternatively
> > be defined outside of it as well.
> 
> I think both work, as I can't find any architectures that define the
> relaxed variants but not the non-relaxed versions.

Actually I just made up my mind about that: Architectures are actually
supposed to provide the non-relaxed versions themselves using inline
assembly, but they don't need to provide the relaxed version.

The current version doesn't let you do that, so I'll keel the #ifdef
sections separate. This also means that I won't apply your patch 17:
we will keep needing the #ifdef to support all three relevant combinations:

a) architectures that provide neither and want to get the defaults
   from asm-generic
b) architectures that provide the non-relaxed versions and want tog
   to get just the relaxed version from asm-generic
c) architectures that provide both

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Thursday 25 September 2014 15:55:38 Will Deacon wrote:
> On Thu, Sep 25, 2014 at 02:15:10PM +0100, Arnd Bergmann wrote:
> > On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> > > This is version three of the series I've originally posted here:
> > > 
> > >   v1: https://lkml.org/lkml/2014/4/17/269
> > >   v2: https://lkml.org/lkml/2014/5/22/468
> > > 
> > > This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> > > (which was merged into mainline).
> > > 
> > > I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> > > quickly got messy as some architectures (e.g. mips) deliberately keep
> > > mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> > > drivers to get mmiowb correct, so add barriers to both. Given that
> > > arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> > > an architecture that does care.
> > > 
> > > In order to get this lot merged, we probably want to merge the asm-generic
> > > patch (1/17) first, so Acks would be much appreciated on the architecture
> > > bits.
> > > 
> > > As before, I've included the original cover letter below, as that describes
> > > what I'm trying to do in more detail.
> > > 
> > 
> > I've now applied the parts of your series that are required to have
> > every architecture provide all the 'relaxed' accessors to the
> > asm-generic tree, on top of Thierry's series.
> 
> Brill, thanks Arnd! I'll repost what's left during the next cycle, however
> I think you also need to pick the microblaze patch as it includes
> <asm-generic/io.h> before defining its relaxed accessors, so I think
> you'll get a redefinition warning from the preprocessor.

Good point, I'll add that on top then.

> > I had to change your first patch significantly because all the context
> > changed in his patches. See below for the new version. Thierry, can
> > you also confirm that this matches up with the intention of your
> > series? Since that now adds a separate #ifdef for each symbol, I
> > ended up putting the #ifdef for the relaxed version inside of the
> > #ifdef for the non-relaxed version, but it could alternatively
> > be defined outside of it as well.
> 
> I think both work, as I can't find any architectures that define the
> relaxed variants but not the non-relaxed versions.

Actually I just made up my mind about that: Architectures are actually
supposed to provide the non-relaxed versions themselves using inline
assembly, but they don't need to provide the relaxed version.

The current version doesn't let you do that, so I'll keel the #ifdef
sections separate. This also means that I won't apply your patch 17:
we will keep needing the #ifdef to support all three relevant combinations:

a) architectures that provide neither and want to get the defaults
   from asm-generic
b) architectures that provide the non-relaxed versions and want tog
   to get just the relaxed version from asm-generic
c) architectures that provide both

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Thursday 25 September 2014 17:07:47 Arnd Bergmann wrote:

> The current version doesn't let you do that, so I'll keel the #ifdef
> sections separate. This also means that I won't apply your patch 17:
> we will keep needing the #ifdef to support all three relevant combinations:
> 
> a) architectures that provide neither and want to get the defaults
>    from asm-generic
> b) architectures that provide the non-relaxed versions and want tog
>    to get just the relaxed version from asm-generic
> c) architectures that provide both
> 

And here is the new version I applied:

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 508a57257de5..3e976be3bdd4 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -174,6 +174,43 @@ static inline void writeq(u64 value, void __iomem *addr)
 #endif /* CONFIG_64BIT */
 
 /*
+ * {read,write}{b,w,l,q}_relaxed() are like the regular version, but
+ * are not guaranteed to provide ordering against spinlocks or memory
+ * accesses.
+ */
+#ifndef readb_relaxed
+#define readb_relaxed readb
+#endif
+
+#ifndef readw_relaxed
+#define readw_relaxed readw
+#endif
+
+#ifndef readl_relaxed
+#define readl_relaxed readl
+#endif
+
+#ifndef readq_relaxed
+#define readq_relaxed readq
+#endif
+
+#ifndef writeb_relaxed
+#define writeb_relaxed writeb
+#endif
+
+#ifndef writew_relaxed
+#define writew_relaxed writew
+#endif
+
+#ifndef writel_relaxed
+#define writel_relaxed writel
+#endif
+
+#ifndef writeq_relaxed
+#define writeq_relaxed writeq
+#endif
+
+/*
  * {read,write}s{b,w,l,q}() repeatedly access the same memory address in
  * native endianness in 8-, 16-, 32- or 64-bit chunks (@count times).
  */

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Thursday 25 September 2014 17:07:47 Arnd Bergmann wrote:

> The current version doesn't let you do that, so I'll keel the #ifdef
> sections separate. This also means that I won't apply your patch 17:
> we will keep needing the #ifdef to support all three relevant combinations:
> 
> a) architectures that provide neither and want to get the defaults
>    from asm-generic
> b) architectures that provide the non-relaxed versions and want tog
>    to get just the relaxed version from asm-generic
> c) architectures that provide both
> 

And here is the new version I applied:

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 508a57257de5..3e976be3bdd4 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -174,6 +174,43 @@ static inline void writeq(u64 value, void __iomem *addr)
 #endif /* CONFIG_64BIT */
 
 /*
+ * {read,write}{b,w,l,q}_relaxed() are like the regular version, but
+ * are not guaranteed to provide ordering against spinlocks or memory
+ * accesses.
+ */
+#ifndef readb_relaxed
+#define readb_relaxed readb
+#endif
+
+#ifndef readw_relaxed
+#define readw_relaxed readw
+#endif
+
+#ifndef readl_relaxed
+#define readl_relaxed readl
+#endif
+
+#ifndef readq_relaxed
+#define readq_relaxed readq
+#endif
+
+#ifndef writeb_relaxed
+#define writeb_relaxed writeb
+#endif
+
+#ifndef writew_relaxed
+#define writew_relaxed writew
+#endif
+
+#ifndef writel_relaxed
+#define writel_relaxed writel
+#endif
+
+#ifndef writeq_relaxed
+#define writeq_relaxed writeq
+#endif
+
+/*
  * {read,write}s{b,w,l,q}() repeatedly access the same memory address in
  * native endianness in 8-, 16-, 32- or 64-bit chunks (@count times).
  */

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Daniel Thompson]

On 25/09/14 16:15, Arnd Bergmann wrote:
> On Thursday 25 September 2014 17:07:47 Arnd Bergmann wrote:
> 
>> The current version doesn't let you do that, so I'll keel the #ifdef
>> sections separate. This also means that I won't apply your patch 17:
>> we will keep needing the #ifdef to support all three relevant combinations:
>>
>> a) architectures that provide neither and want to get the defaults
>>    from asm-generic
>> b) architectures that provide the non-relaxed versions and want tog
>>    to get just the relaxed version from asm-generic
>> c) architectures that provide both
>>
> 
> And here is the new version I applied:
> 
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 508a57257de5..3e976be3bdd4 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -174,6 +174,43 @@ static inline void writeq(u64 value, void __iomem *addr)
>  #endif /* CONFIG_64BIT */
>  
>  /*
> + * {read,write}{b,w,l,q}_relaxed() are like the regular version, but
> + * are not guaranteed to provide ordering against spinlocks or memory
> + * accesses.
> + */
> +#ifndef readb_relaxed
> +#define readb_relaxed readb
> +#endif
> +
> +#ifndef readw_relaxed
> +#define readw_relaxed readw
> +#endif
> +
> +#ifndef readl_relaxed
> +#define readl_relaxed readl
> +#endif
> +
> +#ifndef readq_relaxed
> +#define readq_relaxed readq
> +#endif

Not really sure if it matters but this gives a rather surprising
behaviour to #ifdef readq_relaxed given that readq may not be defined.

> +
> +#ifndef writeb_relaxed
> +#define writeb_relaxed writeb
> +#endif
> +
> +#ifndef writew_relaxed
> +#define writew_relaxed writew
> +#endif
> +
> +#ifndef writel_relaxed
> +#define writel_relaxed writel
> +#endif
> +
> +#ifndef writeq_relaxed
> +#define writeq_relaxed writeq
> +#endif

Ditto.


> +
> +/*
>   * {read,write}s{b,w,l,q}() repeatedly access the same memory address in
>   * native endianness in 8-, 16-, 32- or 64-bit chunks (@count times).
>   */
> 
> 

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Daniel Thompson]

On 25/09/14 16:15, Arnd Bergmann wrote:
> On Thursday 25 September 2014 17:07:47 Arnd Bergmann wrote:
> 
>> The current version doesn't let you do that, so I'll keel the #ifdef
>> sections separate. This also means that I won't apply your patch 17:
>> we will keep needing the #ifdef to support all three relevant combinations:
>>
>> a) architectures that provide neither and want to get the defaults
>>    from asm-generic
>> b) architectures that provide the non-relaxed versions and want tog
>>    to get just the relaxed version from asm-generic
>> c) architectures that provide both
>>
> 
> And here is the new version I applied:
> 
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 508a57257de5..3e976be3bdd4 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -174,6 +174,43 @@ static inline void writeq(u64 value, void __iomem *addr)
>  #endif /* CONFIG_64BIT */
>  
>  /*
> + * {read,write}{b,w,l,q}_relaxed() are like the regular version, but
> + * are not guaranteed to provide ordering against spinlocks or memory
> + * accesses.
> + */
> +#ifndef readb_relaxed
> +#define readb_relaxed readb
> +#endif
> +
> +#ifndef readw_relaxed
> +#define readw_relaxed readw
> +#endif
> +
> +#ifndef readl_relaxed
> +#define readl_relaxed readl
> +#endif
> +
> +#ifndef readq_relaxed
> +#define readq_relaxed readq
> +#endif

Not really sure if it matters but this gives a rather surprising
behaviour to #ifdef readq_relaxed given that readq may not be defined.

> +
> +#ifndef writeb_relaxed
> +#define writeb_relaxed writeb
> +#endif
> +
> +#ifndef writew_relaxed
> +#define writew_relaxed writew
> +#endif
> +
> +#ifndef writel_relaxed
> +#define writel_relaxed writel
> +#endif
> +
> +#ifndef writeq_relaxed
> +#define writeq_relaxed writeq
> +#endif

Ditto.


> +
> +/*
>   * {read,write}s{b,w,l,q}() repeatedly access the same memory address in
>   * native endianness in 8-, 16-, 32- or 64-bit chunks (@count times).
>   */
> 
> 

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Thursday 25 September 2014, Daniel Thompson wrote:
> > +
> > +#ifndef readq_relaxed
> > +#define readq_relaxed readq
> > +#endif
> 
> Not really sure if it matters but this gives a rather surprising
> behaviour to #ifdef readq_relaxed given that readq may not be defined.
> 

It was intentional. I could have written this as

#if !defined(readq_relaxed) && defined(readq)

but the effect would be almost the same, and the version I picked looks
simpler. Note that 32-bit architectures could provide readq, it's just
the generic code that doesn't, because most you typically don't get
atomic 64-bit accesses from dereferencing a 64-bit pointer as the
generic readq() function does.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Thursday 25 September 2014, Daniel Thompson wrote:
> > +
> > +#ifndef readq_relaxed
> > +#define readq_relaxed readq
> > +#endif
> 
> Not really sure if it matters but this gives a rather surprising
> behaviour to #ifdef readq_relaxed given that readq may not be defined.
> 

It was intentional. I could have written this as

#if !defined(readq_relaxed) && defined(readq)

but the effect would be almost the same, and the version I picked looks
simpler. Note that 32-bit architectures could provide readq, it's just
the generic code that doesn't, because most you typically don't get
atomic 64-bit accesses from dereferencing a 64-bit pointer as the
generic readq() function does.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Geert Uytterhoeven]

Hi Arnd,

On Thu, Sep 25, 2014 at 9:17 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 25 September 2014, Daniel Thompson wrote:
>> > +
>> > +#ifndef readq_relaxed
>> > +#define readq_relaxed readq
>> > +#endif
>>
>> Not really sure if it matters but this gives a rather surprising
>> behaviour to #ifdef readq_relaxed given that readq may not be defined.
>
> It was intentional. I could have written this as
>
> #if !defined(readq_relaxed) && defined(readq)
>
> but the effect would be almost the same, and the version I picked looks
> simpler.

However, as soon as a driver has code like

#ifdef readq_relaxed
        do something using readq_relaxed
#else
...
#endif

this will fail if readq is not defined.

Currently no code has such an #ifdef, though.
There are #ifdefs for checking for the presence of readq.

The same is true for writeq_relaxed.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Geert Uytterhoeven]

Hi Arnd,

On Thu, Sep 25, 2014 at 9:17 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 25 September 2014, Daniel Thompson wrote:
>> > +
>> > +#ifndef readq_relaxed
>> > +#define readq_relaxed readq
>> > +#endif
>>
>> Not really sure if it matters but this gives a rather surprising
>> behaviour to #ifdef readq_relaxed given that readq may not be defined.
>
> It was intentional. I could have written this as
>
> #if !defined(readq_relaxed) && defined(readq)
>
> but the effect would be almost the same, and the version I picked looks
> simpler.

However, as soon as a driver has code like

#ifdef readq_relaxed
        do something using readq_relaxed
#else
...
#endif

this will fail if readq is not defined.

Currently no code has such an #ifdef, though.
There are #ifdefs for checking for the presence of readq.

The same is true for writeq_relaxed.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Russell King - ARM Linux]

On Thu, Sep 25, 2014 at 09:17:19PM +0200, Arnd Bergmann wrote:
> On Thursday 25 September 2014, Daniel Thompson wrote:
> > > +
> > > +#ifndef readq_relaxed
> > > +#define readq_relaxed readq
> > > +#endif
> > 
> > Not really sure if it matters but this gives a rather surprising
> > behaviour to #ifdef readq_relaxed given that readq may not be defined.
> > 
> 
> It was intentional. I could have written this as
> 
> #if !defined(readq_relaxed) && defined(readq)
> 
> but the effect would be almost the same, and the version I picked looks
> simpler. Note that 32-bit architectures could provide readq, it's just
> the generic code that doesn't, because most you typically don't get
> atomic 64-bit accesses from dereferencing a 64-bit pointer as the
> generic readq() function does.

32-bit architectures should *not* provide readq().  Remember, we are
talking about devices here, and reading registers on devices *may* have
side effects.

Side effects such as clearing the pending interrupt status.

How would a 32-bit architecture know whether it should read the least
significant 32-bit or the most significant 32-bit part of the 64-bit
register first.  What would be right for one driver may not ben correct
for another.  Hence, this decision should only be made by the driver
wanting the accessor, and not having the accessor symbol defined should
be the trigger for the driver to handle the problem themselves.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Russell King - ARM Linux]

On Thu, Sep 25, 2014 at 09:17:19PM +0200, Arnd Bergmann wrote:
> On Thursday 25 September 2014, Daniel Thompson wrote:
> > > +
> > > +#ifndef readq_relaxed
> > > +#define readq_relaxed readq
> > > +#endif
> > 
> > Not really sure if it matters but this gives a rather surprising
> > behaviour to #ifdef readq_relaxed given that readq may not be defined.
> > 
> 
> It was intentional. I could have written this as
> 
> #if !defined(readq_relaxed) && defined(readq)
> 
> but the effect would be almost the same, and the version I picked looks
> simpler. Note that 32-bit architectures could provide readq, it's just
> the generic code that doesn't, because most you typically don't get
> atomic 64-bit accesses from dereferencing a 64-bit pointer as the
> generic readq() function does.

32-bit architectures should *not* provide readq().  Remember, we are
talking about devices here, and reading registers on devices *may* have
side effects.

Side effects such as clearing the pending interrupt status.

How would a 32-bit architecture know whether it should read the least
significant 32-bit or the most significant 32-bit part of the 64-bit
register first.  What would be right for one driver may not ben correct
for another.  Hence, this decision should only be made by the driver
wanting the accessor, and not having the accessor symbol defined should
be the trigger for the driver to handle the problem themselves.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Friday 26 September 2014 09:40:19 Russell King - ARM Linux wrote:
> 
> How would a 32-bit architecture know whether it should read the least
> significant 32-bit or the most significant 32-bit part of the 64-bit
> register first.  What would be right for one driver may not ben correct
> for another.  Hence, this decision should only be made by the driver
> wanting the accessor, and not having the accessor symbol defined should
> be the trigger for the driver to handle the problem themselves.

Some 32-bit architectures can trigger 64-bit bus cycles using well
defined accesses using register pairs. Meta seems to fit into this
category:

static inline u64 __raw_readq(const volatile void __iomem *addr)
{
       u64 ret;
       asm volatile("GETL %0,%t0,[%1]"
                    : "=da" (ret)
                    : "da" (addr)
                    : "memory");
       return ret;
}

Most other architectures I think cannot do this however, and would
turn the access into two separate bus cycles, which in addition to
the problem you mentioned could also result in side-effects from
doing an access at the wrong offset, so we definitely can't rely
on having these functions.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Friday 26 September 2014 09:40:19 Russell King - ARM Linux wrote:
> 
> How would a 32-bit architecture know whether it should read the least
> significant 32-bit or the most significant 32-bit part of the 64-bit
> register first.  What would be right for one driver may not ben correct
> for another.  Hence, this decision should only be made by the driver
> wanting the accessor, and not having the accessor symbol defined should
> be the trigger for the driver to handle the problem themselves.

Some 32-bit architectures can trigger 64-bit bus cycles using well
defined accesses using register pairs. Meta seems to fit into this
category:

static inline u64 __raw_readq(const volatile void __iomem *addr)
{
       u64 ret;
       asm volatile("GETL %0,%t0,[%1]"
                    : "=da" (ret)
                    : "da" (addr)
                    : "memory");
       return ret;
}

Most other architectures I think cannot do this however, and would
turn the access into two separate bus cycles, which in addition to
the problem you mentioned could also result in side-effects from
doing an access at the wrong offset, so we definitely can't rely
on having these functions.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]

On Thu, Sep 25, 2014 at 05:15:14PM +0200, Arnd Bergmann wrote:
> On Thursday 25 September 2014 17:07:47 Arnd Bergmann wrote:
> 
> > The current version doesn't let you do that, so I'll keel the #ifdef
> > sections separate. This also means that I won't apply your patch 17:
> > we will keep needing the #ifdef to support all three relevant combinations:
> > 
> > a) architectures that provide neither and want to get the defaults
> >    from asm-generic
> > b) architectures that provide the non-relaxed versions and want tog
> >    to get just the relaxed version from asm-generic
> > c) architectures that provide both
> > 
> 
> And here is the new version I applied:
> 
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 508a57257de5..3e976be3bdd4 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -174,6 +174,43 @@ static inline void writeq(u64 value, void __iomem *addr)
>  #endif /* CONFIG_64BIT */
>  
>  /*
> + * {read,write}{b,w,l,q}_relaxed() are like the regular version, but
> + * are not guaranteed to provide ordering against spinlocks or memory
> + * accesses.
> + */
> +#ifndef readb_relaxed
> +#define readb_relaxed readb
> +#endif

My original patch to consolidate the read*/write*() and friends
explicitly avoided the use of macros to do this. The reason was that if
we have static inline functions in asm-generic/io.h it defines the
canonical prototype of these functions, so that architectures that want
to override them can just copy the prototype from there.

So for consistency the above would become:

	#ifndef readb_relaxed
	#define readb_relaxed readb_relaxed
	static inline u8 readb_relaxed(const void __iomem *addr)
	{
		return readb(addr);
	}
	#endif

And analogously for the others. For the *_relaxed variants it's perhaps
not as important because the signature is the same as for the plain
variants, so I'm not objecting very strongly to the plain macros.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]

On Thu, Sep 25, 2014 at 05:15:14PM +0200, Arnd Bergmann wrote:
> On Thursday 25 September 2014 17:07:47 Arnd Bergmann wrote:
> 
> > The current version doesn't let you do that, so I'll keel the #ifdef
> > sections separate. This also means that I won't apply your patch 17:
> > we will keep needing the #ifdef to support all three relevant combinations:
> > 
> > a) architectures that provide neither and want to get the defaults
> >    from asm-generic
> > b) architectures that provide the non-relaxed versions and want tog
> >    to get just the relaxed version from asm-generic
> > c) architectures that provide both
> > 
> 
> And here is the new version I applied:
> 
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index 508a57257de5..3e976be3bdd4 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -174,6 +174,43 @@ static inline void writeq(u64 value, void __iomem *addr)
>  #endif /* CONFIG_64BIT */
>  
>  /*
> + * {read,write}{b,w,l,q}_relaxed() are like the regular version, but
> + * are not guaranteed to provide ordering against spinlocks or memory
> + * accesses.
> + */
> +#ifndef readb_relaxed
> +#define readb_relaxed readb
> +#endif

My original patch to consolidate the read*/write*() and friends
explicitly avoided the use of macros to do this. The reason was that if
we have static inline functions in asm-generic/io.h it defines the
canonical prototype of these functions, so that architectures that want
to override them can just copy the prototype from there.

So for consistency the above would become:

	#ifndef readb_relaxed
	#define readb_relaxed readb_relaxed
	static inline u8 readb_relaxed(const void __iomem *addr)
	{
		return readb(addr);
	}
	#endif

And analogously for the others. For the *_relaxed variants it's perhaps
not as important because the signature is the same as for the plain
variants, so I'm not objecting very strongly to the plain macros.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Friday 26 September 2014 10:05:52 Thierry Reding wrote:

> My original patch to consolidate the read*/write*() and friends
> explicitly avoided the use of macros to do this. The reason was that if
> we have static inline functions in asm-generic/io.h it defines the
> canonical prototype of these functions, so that architectures that want
> to override them can just copy the prototype from there.
> 
> So for consistency the above would become:
> 
> 	#ifndef readb_relaxed
> 	#define readb_relaxed readb_relaxed
> 	static inline u8 readb_relaxed(const void __iomem *addr)
> 	{
> 		return readb(addr);
> 	}
> 	#endif
> 
> And analogously for the others. For the *_relaxed variants it's perhaps
> not as important because the signature is the same as for the plain
> variants, so I'm not objecting very strongly to the plain macros.

Ok. I'd prefer the brief version I think.

Russell found a number of other bugs with the series, the patch below
contains the fixes I've had to do so far.

I assume I'll add some more of these and then commit an update.

	Arnd

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 179ce4b93d9a..e9e70b19dc2f 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -347,10 +347,12 @@ extern void _memset_io(volatile void __iomem *, int, size_t);
 #define iowrite16be(v,p)	({ __iowmb(); __raw_writew((__force __u16)cpu_to_be16(v), p); })
 #define iowrite32be(v,p)	({ __iowmb(); __raw_writew((__force __u32)cpu_to_be32(v), p); })
 
+#ifndef ioport_map
 #define ioport_map ioport_map
 extern void __iomem *ioport_map(unsigned long port, unsigned int nr);
 #define ioport_unmap ioport_unmap
 extern void ioport_unmap(void __iomem *addr);
+#endif
 
 struct pci_dev;
 
diff --git a/arch/arm/mach-ebsa110/include/mach/io.h b/arch/arm/mach-ebsa110/include/mach/io.h
index 11bb0799424b..72232a198d83 100644
--- a/arch/arm/mach-ebsa110/include/mach/io.h
+++ b/arch/arm/mach-ebsa110/include/mach/io.h
@@ -62,20 +62,30 @@ void __writel(u32 val, void __iomem *addr);
 #define writew(v,b)		__writew(v,b)
 #define writel(v,b)		__writel(v,b)
 
+#define insb insb
 extern void insb(unsigned int port, void *buf, int sz);
+#define insw insw
 extern void insw(unsigned int port, void *buf, int sz);
+#define insl insl
 extern void insl(unsigned int port, void *buf, int sz);
 
+#define outsb outsb
 extern void outsb(unsigned int port, const void *buf, int sz);
+#define outsw outsw
 extern void outsw(unsigned int port, const void *buf, int sz);
+#define outsl outsl
 extern void outsl(unsigned int port, const void *buf, int sz);
 
 /* can't support writesb atm */
+#define writesw writesw
 extern void writesw(void __iomem *addr, const void *data, int wordlen);
+#define writesl writesl
 extern void writesl(void __iomem *addr, const void *data, int longlen);
 
 /* can't support readsb atm */
+#define readsw readsw
 extern void readsw(const void __iomem *addr, void *data, int wordlen);
+#define readsl readsl
 extern void readsl(const void __iomem *addr, void *data, int longlen);
 
 #endif
diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h
index 559c69a47731..3e74cd3be9bd 100644
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -225,7 +225,7 @@ static inline void __indirect_readsl(const volatile void __iomem *bus_addr,
  * transaction.  This means that we need to override the default
  * I/O functions.
  */
-
+#define outb outb
 static inline void outb(u8 value, u32 addr)
 {
 	u32 n, byte_enables, data;
@@ -235,12 +235,14 @@ static inline void outb(u8 value, u32 addr)
 	ixp4xx_pci_write(addr, byte_enables | NP_CMD_IOWRITE, data);
 }
 
+#define outsb outsb
 static inline void outsb(u32 io_addr, const u8 *vaddr, u32 count)
 {
 	while (count--)
 		outb(*vaddr++, io_addr);
 }
 
+#define outw outw
 static inline void outw(u16 value, u32 addr)
 {
 	u32 n, byte_enables, data;
@@ -250,23 +252,27 @@ static inline void outw(u16 value, u32 addr)
 	ixp4xx_pci_write(addr, byte_enables | NP_CMD_IOWRITE, data);
 }
 
+#define outsw outsw
 static inline void outsw(u32 io_addr, const u16 *vaddr, u32 count)
 {
 	while (count--)
 		outw(cpu_to_le16(*vaddr++), io_addr);
 }
 
+#define outl outl
 static inline void outl(u32 value, u32 addr)
 {
 	ixp4xx_pci_write(addr, NP_CMD_IOWRITE, value);
 }
 
+#define outsl outsl
 static inline void outsl(u32 io_addr, const u32 *vaddr, u32 count)
 {
 	while (count--)
 		outl(cpu_to_le32(*vaddr++), io_addr);
 }
 
+#define inb inb
 static inline u8 inb(u32 addr)
 {
 	u32 n, byte_enables, data;
@@ -278,12 +284,14 @@ static inline u8 inb(u32 addr)
 	return data >> (8*n);
 }
 
+#define insb insb
 static inline void insb(u32 io_addr, u8 *vaddr, u32 count)
 {
 	while (count--)
 		*vaddr++ = inb(io_addr);
 }
 
+#define inw inw
 static inline u16 inw(u32 addr)
 {
 	u32 n, byte_enables, data;
@@ -295,12 +303,14 @@ static inline u16 inw(u32 addr)
 	return data>>(8*n);
 }
 
+#define insw insw
 static inline void insw(u32 io_addr, u16 *vaddr, u32 count)
 {
 	while (count--)
 		*vaddr++ = le16_to_cpu(inw(io_addr));
 }
 
+#define inl inl
 static inline u32 inl(u32 addr)
 {
 	u32 data;
@@ -310,6 +320,7 @@ static inline u32 inl(u32 addr)
 	return data;
 }
 
+#define insl insl
 static inline void insl(u32 io_addr, u32 *vaddr, u32 count)
 {
 	while (count--)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 6aeb6add49a6..7872527c08db 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -560,35 +560,53 @@ static inline void outsl_p(unsigned long addr, const void *buffer,
 #endif
 
 #ifndef CONFIG_GENERIC_IOMAP
+#ifndef ioread8
+#define ioread8 ioread8
 static inline u8 ioread8(const void __iomem *addr)
 {
 	return readb(addr);
 }
+#endif
 
+#ifndef ioread16
+#define ioread16 ioread16
 static inline u16 ioread16(const void __iomem *addr)
 {
 	return readw(addr);
 }
+#endif
 
+#ifndef ioread32
+#define ioread32 ioread32
 static inline u32 ioread32(const void __iomem *addr)
 {
 	return readl(addr);
 }
+#endif
 
+#ifndef iowrite8
+#define iowrite8 iowrite8
 static inline void iowrite8(u8 value, void __iomem *addr)
 {
 	writeb(value, addr);
 }
+#endif
 
+#ifndef iowrite16
+#define iowrite16 iowrite16
 static inline void iowrite16(u16 value, void __iomem *addr)
 {
 	writew(value, addr);
 }
+#endif
 
+#ifndef iowrite32
+#define iowrite32 iowrite32
 static inline void iowrite32(u32 value, void __iomem *addr)
 {
 	writel(value, addr);
 }
+#endif
 
 #ifndef ioread16be
 #define ioread16be ioread16be

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Friday 26 September 2014 10:05:52 Thierry Reding wrote:

> My original patch to consolidate the read*/write*() and friends
> explicitly avoided the use of macros to do this. The reason was that if
> we have static inline functions in asm-generic/io.h it defines the
> canonical prototype of these functions, so that architectures that want
> to override them can just copy the prototype from there.
> 
> So for consistency the above would become:
> 
> 	#ifndef readb_relaxed
> 	#define readb_relaxed readb_relaxed
> 	static inline u8 readb_relaxed(const void __iomem *addr)
> 	{
> 		return readb(addr);
> 	}
> 	#endif
> 
> And analogously for the others. For the *_relaxed variants it's perhaps
> not as important because the signature is the same as for the plain
> variants, so I'm not objecting very strongly to the plain macros.

Ok. I'd prefer the brief version I think.

Russell found a number of other bugs with the series, the patch below
contains the fixes I've had to do so far.

I assume I'll add some more of these and then commit an update.

	Arnd

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 179ce4b93d9a..e9e70b19dc2f 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -347,10 +347,12 @@ extern void _memset_io(volatile void __iomem *, int, size_t);
 #define iowrite16be(v,p)	({ __iowmb(); __raw_writew((__force __u16)cpu_to_be16(v), p); })
 #define iowrite32be(v,p)	({ __iowmb(); __raw_writew((__force __u32)cpu_to_be32(v), p); })
 
+#ifndef ioport_map
 #define ioport_map ioport_map
 extern void __iomem *ioport_map(unsigned long port, unsigned int nr);
 #define ioport_unmap ioport_unmap
 extern void ioport_unmap(void __iomem *addr);
+#endif
 
 struct pci_dev;
 
diff --git a/arch/arm/mach-ebsa110/include/mach/io.h b/arch/arm/mach-ebsa110/include/mach/io.h
index 11bb0799424b..72232a198d83 100644
--- a/arch/arm/mach-ebsa110/include/mach/io.h
+++ b/arch/arm/mach-ebsa110/include/mach/io.h
@@ -62,20 +62,30 @@ void __writel(u32 val, void __iomem *addr);
 #define writew(v,b)		__writew(v,b)
 #define writel(v,b)		__writel(v,b)
 
+#define insb insb
 extern void insb(unsigned int port, void *buf, int sz);
+#define insw insw
 extern void insw(unsigned int port, void *buf, int sz);
+#define insl insl
 extern void insl(unsigned int port, void *buf, int sz);
 
+#define outsb outsb
 extern void outsb(unsigned int port, const void *buf, int sz);
+#define outsw outsw
 extern void outsw(unsigned int port, const void *buf, int sz);
+#define outsl outsl
 extern void outsl(unsigned int port, const void *buf, int sz);
 
 /* can't support writesb atm */
+#define writesw writesw
 extern void writesw(void __iomem *addr, const void *data, int wordlen);
+#define writesl writesl
 extern void writesl(void __iomem *addr, const void *data, int longlen);
 
 /* can't support readsb atm */
+#define readsw readsw
 extern void readsw(const void __iomem *addr, void *data, int wordlen);
+#define readsl readsl
 extern void readsl(const void __iomem *addr, void *data, int longlen);
 
 #endif
diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h
index 559c69a47731..3e74cd3be9bd 100644
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -225,7 +225,7 @@ static inline void __indirect_readsl(const volatile void __iomem *bus_addr,
  * transaction.  This means that we need to override the default
  * I/O functions.
  */
-
+#define outb outb
 static inline void outb(u8 value, u32 addr)
 {
 	u32 n, byte_enables, data;
@@ -235,12 +235,14 @@ static inline void outb(u8 value, u32 addr)
 	ixp4xx_pci_write(addr, byte_enables | NP_CMD_IOWRITE, data);
 }
 
+#define outsb outsb
 static inline void outsb(u32 io_addr, const u8 *vaddr, u32 count)
 {
 	while (count--)
 		outb(*vaddr++, io_addr);
 }
 
+#define outw outw
 static inline void outw(u16 value, u32 addr)
 {
 	u32 n, byte_enables, data;
@@ -250,23 +252,27 @@ static inline void outw(u16 value, u32 addr)
 	ixp4xx_pci_write(addr, byte_enables | NP_CMD_IOWRITE, data);
 }
 
+#define outsw outsw
 static inline void outsw(u32 io_addr, const u16 *vaddr, u32 count)
 {
 	while (count--)
 		outw(cpu_to_le16(*vaddr++), io_addr);
 }
 
+#define outl outl
 static inline void outl(u32 value, u32 addr)
 {
 	ixp4xx_pci_write(addr, NP_CMD_IOWRITE, value);
 }
 
+#define outsl outsl
 static inline void outsl(u32 io_addr, const u32 *vaddr, u32 count)
 {
 	while (count--)
 		outl(cpu_to_le32(*vaddr++), io_addr);
 }
 
+#define inb inb
 static inline u8 inb(u32 addr)
 {
 	u32 n, byte_enables, data;
@@ -278,12 +284,14 @@ static inline u8 inb(u32 addr)
 	return data >> (8*n);
 }
 
+#define insb insb
 static inline void insb(u32 io_addr, u8 *vaddr, u32 count)
 {
 	while (count--)
 		*vaddr++ = inb(io_addr);
 }
 
+#define inw inw
 static inline u16 inw(u32 addr)
 {
 	u32 n, byte_enables, data;
@@ -295,12 +303,14 @@ static inline u16 inw(u32 addr)
 	return data>>(8*n);
 }
 
+#define insw insw
 static inline void insw(u32 io_addr, u16 *vaddr, u32 count)
 {
 	while (count--)
 		*vaddr++ = le16_to_cpu(inw(io_addr));
 }
 
+#define inl inl
 static inline u32 inl(u32 addr)
 {
 	u32 data;
@@ -310,6 +320,7 @@ static inline u32 inl(u32 addr)
 	return data;
 }
 
+#define insl insl
 static inline void insl(u32 io_addr, u32 *vaddr, u32 count)
 {
 	while (count--)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 6aeb6add49a6..7872527c08db 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -560,35 +560,53 @@ static inline void outsl_p(unsigned long addr, const void *buffer,
 #endif
 
 #ifndef CONFIG_GENERIC_IOMAP
+#ifndef ioread8
+#define ioread8 ioread8
 static inline u8 ioread8(const void __iomem *addr)
 {
 	return readb(addr);
 }
+#endif
 
+#ifndef ioread16
+#define ioread16 ioread16
 static inline u16 ioread16(const void __iomem *addr)
 {
 	return readw(addr);
 }
+#endif
 
+#ifndef ioread32
+#define ioread32 ioread32
 static inline u32 ioread32(const void __iomem *addr)
 {
 	return readl(addr);
 }
+#endif
 
+#ifndef iowrite8
+#define iowrite8 iowrite8
 static inline void iowrite8(u8 value, void __iomem *addr)
 {
 	writeb(value, addr);
 }
+#endif
 
+#ifndef iowrite16
+#define iowrite16 iowrite16
 static inline void iowrite16(u16 value, void __iomem *addr)
 {
 	writew(value, addr);
 }
+#endif
 
+#ifndef iowrite32
+#define iowrite32 iowrite32
 static inline void iowrite32(u32 value, void __iomem *addr)
 {
 	writel(value, addr);
 }
+#endif
 
 #ifndef ioread16be
 #define ioread16be ioread16be

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Russell King - ARM Linux]

On Fri, Sep 26, 2014 at 03:39:49PM +0200, Arnd Bergmann wrote:
> On Friday 26 September 2014 10:05:52 Thierry Reding wrote:
> 
> > My original patch to consolidate the read*/write*() and friends
> > explicitly avoided the use of macros to do this. The reason was that if
> > we have static inline functions in asm-generic/io.h it defines the
> > canonical prototype of these functions, so that architectures that want
> > to override them can just copy the prototype from there.
> > 
> > So for consistency the above would become:
> > 
> > 	#ifndef readb_relaxed
> > 	#define readb_relaxed readb_relaxed
> > 	static inline u8 readb_relaxed(const void __iomem *addr)
> > 	{
> > 		return readb(addr);
> > 	}
> > 	#endif
> > 
> > And analogously for the others. For the *_relaxed variants it's perhaps
> > not as important because the signature is the same as for the plain
> > variants, so I'm not objecting very strongly to the plain macros.
> 
> Ok. I'd prefer the brief version I think.
> 
> Russell found a number of other bugs with the series, the patch below
> contains the fixes I've had to do so far.

Obviously, this does nothing for the:

include/asm-generic/io.h:804:29: error: redefinition of 'virt_to_bus'
include/asm-generic/io.h:809:21: error: redefinition of 'bus_to_virt'

errors which are also reported in Olof's build system.

Given how close we are to the merge window, I'd suggest this stuff gets
reverted so that it can have a better period of testing, rather than
stuffing it into -next at such a critical time.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Russell King - ARM Linux]

On Fri, Sep 26, 2014 at 03:39:49PM +0200, Arnd Bergmann wrote:
> On Friday 26 September 2014 10:05:52 Thierry Reding wrote:
> 
> > My original patch to consolidate the read*/write*() and friends
> > explicitly avoided the use of macros to do this. The reason was that if
> > we have static inline functions in asm-generic/io.h it defines the
> > canonical prototype of these functions, so that architectures that want
> > to override them can just copy the prototype from there.
> > 
> > So for consistency the above would become:
> > 
> > 	#ifndef readb_relaxed
> > 	#define readb_relaxed readb_relaxed
> > 	static inline u8 readb_relaxed(const void __iomem *addr)
> > 	{
> > 		return readb(addr);
> > 	}
> > 	#endif
> > 
> > And analogously for the others. For the *_relaxed variants it's perhaps
> > not as important because the signature is the same as for the plain
> > variants, so I'm not objecting very strongly to the plain macros.
> 
> Ok. I'd prefer the brief version I think.
> 
> Russell found a number of other bugs with the series, the patch below
> contains the fixes I've had to do so far.

Obviously, this does nothing for the:

include/asm-generic/io.h:804:29: error: redefinition of 'virt_to_bus'
include/asm-generic/io.h:809:21: error: redefinition of 'bus_to_virt'

errors which are also reported in Olof's build system.

Given how close we are to the merge window, I'd suggest this stuff gets
reverted so that it can have a better period of testing, rather than
stuffing it into -next at such a critical time.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Friday 26 September 2014 14:46:08 Russell King - ARM Linux wrote:
> 
> Obviously, this does nothing for the:
> 
> include/asm-generic/io.h:804:29: error: redefinition of 'virt_to_bus'
> include/asm-generic/io.h:809:21: error: redefinition of 'bus_to_virt'
> 
> errors which are also reported in Olof's build system.
> 
> Given how close we are to the merge window, I'd suggest this stuff gets
> reverted so that it can have a better period of testing, rather than
> stuffing it into -next at such a critical time.

Right, I've fixed these all up locally, but then found new warnings on
allmodconfig builds that I haven't been able to track down yet.

I've dropped everything from the asm-generic tree now, so we can get
a clean linux-next tree.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Friday 26 September 2014 14:46:08 Russell King - ARM Linux wrote:
> 
> Obviously, this does nothing for the:
> 
> include/asm-generic/io.h:804:29: error: redefinition of 'virt_to_bus'
> include/asm-generic/io.h:809:21: error: redefinition of 'bus_to_virt'
> 
> errors which are also reported in Olof's build system.
> 
> Given how close we are to the merge window, I'd suggest this stuff gets
> reverted so that it can have a better period of testing, rather than
> stuffing it into -next at such a critical time.

Right, I've fixed these all up locally, but then found new warnings on
allmodconfig builds that I haven't been able to track down yet.

I've dropped everything from the asm-generic tree now, so we can get
a clean linux-next tree.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Fri, Sep 26, 2014 at 11:36:13PM +0200, Arnd Bergmann wrote:
> On Friday 26 September 2014 14:46:08 Russell King - ARM Linux wrote:
> > 
> > Obviously, this does nothing for the:
> > 
> > include/asm-generic/io.h:804:29: error: redefinition of 'virt_to_bus'
> > include/asm-generic/io.h:809:21: error: redefinition of 'bus_to_virt'
> > 
> > errors which are also reported in Olof's build system.
> > 
> > Given how close we are to the merge window, I'd suggest this stuff gets
> > reverted so that it can have a better period of testing, rather than
> > stuffing it into -next at such a critical time.
> 
> Right, I've fixed these all up locally, but then found new warnings on
> allmodconfig builds that I haven't been able to track down yet.
> 
> I've dropped everything from the asm-generic tree now, so we can get
> a clean linux-next tree.

How about if I keep iterating this series? It seems like most failures
can be reproduced by doing ARM defconfig and allmodconfig builds, so
I'll do those and fix up any issues I find. Hopefully I can squash all
these before 3.18-rc1, then we can take it into linux-next early for
3.19? In the meantime perhaps I can work with Olof to get a branch with
these patches tested on his builder? And perhaps on the 0-day builder in
addition?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Fri, Sep 26, 2014 at 11:36:13PM +0200, Arnd Bergmann wrote:
> On Friday 26 September 2014 14:46:08 Russell King - ARM Linux wrote:
> > 
> > Obviously, this does nothing for the:
> > 
> > include/asm-generic/io.h:804:29: error: redefinition of 'virt_to_bus'
> > include/asm-generic/io.h:809:21: error: redefinition of 'bus_to_virt'
> > 
> > errors which are also reported in Olof's build system.
> > 
> > Given how close we are to the merge window, I'd suggest this stuff gets
> > reverted so that it can have a better period of testing, rather than
> > stuffing it into -next at such a critical time.
> 
> Right, I've fixed these all up locally, but then found new warnings on
> allmodconfig builds that I haven't been able to track down yet.
> 
> I've dropped everything from the asm-generic tree now, so we can get
> a clean linux-next tree.

How about if I keep iterating this series? It seems like most failures
can be reproduced by doing ARM defconfig and allmodconfig builds, so
I'll do those and fix up any issues I find. Hopefully I can squash all
these before 3.18-rc1, then we can take it into linux-next early for
3.19? In the meantime perhaps I can work with Olof to get a branch with
these patches tested on his builder? And perhaps on the 0-day builder in
addition?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Monday 29 September 2014 10:23:25 Thierry Reding wrote:
> 
> How about if I keep iterating this series? It seems like most failures
> can be reproduced by doing ARM defconfig and allmodconfig builds, so
> I'll do those and fix up any issues I find. Hopefully I can squash all
> these before 3.18-rc1, then we can take it into linux-next early for
> 3.19? In the meantime perhaps I can work with Olof to get a branch with
> these patches tested on his builder? And perhaps on the 0-day builder in
> addition?

Yes, definitely!

Note that I saw a lot of problems only in randconfig build tests but
not in any of the default configurations. I'll send you the fixup patch
soon so you can integrate that in your series.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Monday 29 September 2014 10:23:25 Thierry Reding wrote:
> 
> How about if I keep iterating this series? It seems like most failures
> can be reproduced by doing ARM defconfig and allmodconfig builds, so
> I'll do those and fix up any issues I find. Hopefully I can squash all
> these before 3.18-rc1, then we can take it into linux-next early for
> 3.19? In the meantime perhaps I can work with Olof to get a branch with
> these patches tested on his builder? And perhaps on the 0-day builder in
> addition?

Yes, definitely!

Note that I saw a lot of problems only in randconfig build tests but
not in any of the default configurations. I'll send you the fixup patch
soon so you can integrate that in your series.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Mon, Sep 29, 2014 at 11:50:13AM +0200, Arnd Bergmann wrote:
> On Monday 29 September 2014 10:23:25 Thierry Reding wrote:
> > 
> > How about if I keep iterating this series? It seems like most failures
> > can be reproduced by doing ARM defconfig and allmodconfig builds, so
> > I'll do those and fix up any issues I find. Hopefully I can squash all
> > these before 3.18-rc1, then we can take it into linux-next early for
> > 3.19? In the meantime perhaps I can work with Olof to get a branch with
> > these patches tested on his builder? And perhaps on the 0-day builder in
> > addition?
> 
> Yes, definitely!
> 
> Note that I saw a lot of problems only in randconfig build tests but
> not in any of the default configurations. I'll send you the fixup patch
> soon so you can integrate that in your series.

One of the things I've seen a lot is warnings about volatile being
ignored. This is caused by my latest series dropping the volatile
keyword for the I/O accessors. The rationale being that use of volatile
should be an implementation detail of the accessors rather than the
function signature.

Unfortunately there seems to be a *lot* of code in the kernel that uses
volatile where it probably doesn't make sense. In fact all the warnings
that I've been getting are from code that uses I/O accessors on the I/O
memory, hence shouldn't have to worry about volatile. See also
Documentation/volatile-considered-harmful.txt.

Given the massive amount of changes needed to remove these warnings, is
it better to just keep the volatile keyword even if it's clearly wrong
in the context of the I/O accessors? Or should we bite the bullet and
remove all the wrong uses while at it?

I suppose if we decide to remove them we can always make that a separate
patch series.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Mon, Sep 29, 2014 at 11:50:13AM +0200, Arnd Bergmann wrote:
> On Monday 29 September 2014 10:23:25 Thierry Reding wrote:
> > 
> > How about if I keep iterating this series? It seems like most failures
> > can be reproduced by doing ARM defconfig and allmodconfig builds, so
> > I'll do those and fix up any issues I find. Hopefully I can squash all
> > these before 3.18-rc1, then we can take it into linux-next early for
> > 3.19? In the meantime perhaps I can work with Olof to get a branch with
> > these patches tested on his builder? And perhaps on the 0-day builder in
> > addition?
> 
> Yes, definitely!
> 
> Note that I saw a lot of problems only in randconfig build tests but
> not in any of the default configurations. I'll send you the fixup patch
> soon so you can integrate that in your series.

One of the things I've seen a lot is warnings about volatile being
ignored. This is caused by my latest series dropping the volatile
keyword for the I/O accessors. The rationale being that use of volatile
should be an implementation detail of the accessors rather than the
function signature.

Unfortunately there seems to be a *lot* of code in the kernel that uses
volatile where it probably doesn't make sense. In fact all the warnings
that I've been getting are from code that uses I/O accessors on the I/O
memory, hence shouldn't have to worry about volatile. See also
Documentation/volatile-considered-harmful.txt.

Given the massive amount of changes needed to remove these warnings, is
it better to just keep the volatile keyword even if it's clearly wrong
in the context of the I/O accessors? Or should we bite the bullet and
remove all the wrong uses while at it?

I suppose if we decide to remove them we can always make that a separate
patch series.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Wednesday 01 October 2014 17:23:58 Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 11:50:13AM +0200, Arnd Bergmann wrote:
> > On Monday 29 September 2014 10:23:25 Thierry Reding wrote:
> > > 
> > > How about if I keep iterating this series? It seems like most failures
> > > can be reproduced by doing ARM defconfig and allmodconfig builds, so
> > > I'll do those and fix up any issues I find. Hopefully I can squash all
> > > these before 3.18-rc1, then we can take it into linux-next early for
> > > 3.19? In the meantime perhaps I can work with Olof to get a branch with
> > > these patches tested on his builder? And perhaps on the 0-day builder in
> > > addition?
> > 
> > Yes, definitely!
> > 
> > Note that I saw a lot of problems only in randconfig build tests but
> > not in any of the default configurations. I'll send you the fixup patch
> > soon so you can integrate that in your series.
> 
> One of the things I've seen a lot is warnings about volatile being
> ignored. This is caused by my latest series dropping the volatile
> keyword for the I/O accessors. The rationale being that use of volatile
> should be an implementation detail of the accessors rather than the
> function signature.

The reason those accessors have the volatile keyword in the argument
list is purely to silence the compiler when a driver passes a variable
that is marked volatile.

> Given the massive amount of changes needed to remove these warnings, is
> it better to just keep the volatile keyword even if it's clearly wrong
> in the context of the I/O accessors? Or should we bite the bullet and
> remove all the wrong uses while at it?
> 
> I suppose if we decide to remove them we can always make that a separate
> patch series.

Right, let's not do that now. We could put it on the kernel janitor wiki
as a task for newbies though.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Wednesday 01 October 2014 17:23:58 Thierry Reding wrote:
> On Mon, Sep 29, 2014 at 11:50:13AM +0200, Arnd Bergmann wrote:
> > On Monday 29 September 2014 10:23:25 Thierry Reding wrote:
> > > 
> > > How about if I keep iterating this series? It seems like most failures
> > > can be reproduced by doing ARM defconfig and allmodconfig builds, so
> > > I'll do those and fix up any issues I find. Hopefully I can squash all
> > > these before 3.18-rc1, then we can take it into linux-next early for
> > > 3.19? In the meantime perhaps I can work with Olof to get a branch with
> > > these patches tested on his builder? And perhaps on the 0-day builder in
> > > addition?
> > 
> > Yes, definitely!
> > 
> > Note that I saw a lot of problems only in randconfig build tests but
> > not in any of the default configurations. I'll send you the fixup patch
> > soon so you can integrate that in your series.
> 
> One of the things I've seen a lot is warnings about volatile being
> ignored. This is caused by my latest series dropping the volatile
> keyword for the I/O accessors. The rationale being that use of volatile
> should be an implementation detail of the accessors rather than the
> function signature.

The reason those accessors have the volatile keyword in the argument
list is purely to silence the compiler when a driver passes a variable
that is marked volatile.

> Given the massive amount of changes needed to remove these warnings, is
> it better to just keep the volatile keyword even if it's clearly wrong
> in the context of the I/O accessors? Or should we bite the bullet and
> remove all the wrong uses while at it?
> 
> I suppose if we decide to remove them we can always make that a separate
> patch series.

Right, let's not do that now. We could put it on the kernel janitor wiki
as a task for newbies though.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Will Deacon]

Hi Arnd,

On Fri, Sep 26, 2014 at 10:36:13PM +0100, Arnd Bergmann wrote:
> On Friday 26 September 2014 14:46:08 Russell King - ARM Linux wrote:
> > 
> > Obviously, this does nothing for the:
> > 
> > include/asm-generic/io.h:804:29: error: redefinition of 'virt_to_bus'
> > include/asm-generic/io.h:809:21: error: redefinition of 'bus_to_virt'
> > 
> > errors which are also reported in Olof's build system.
> > 
> > Given how close we are to the merge window, I'd suggest this stuff gets
> > reverted so that it can have a better period of testing, rather than
> > stuffing it into -next at such a critical time.
> 
> Right, I've fixed these all up locally, but then found new warnings on
> allmodconfig builds that I haven't been able to track down yet.
> 
> I've dropped everything from the asm-generic tree now, so we can get
> a clean linux-next tree.

Did you actually see any failures due to the relaxed I/O stuff, or was this
all in the unrelated rework of the asm-generic/io.h file? If the latter, it
would be a pity to postpone the former series.

Will

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Will Deacon]

Hi Arnd,

On Fri, Sep 26, 2014 at 10:36:13PM +0100, Arnd Bergmann wrote:
> On Friday 26 September 2014 14:46:08 Russell King - ARM Linux wrote:
> > 
> > Obviously, this does nothing for the:
> > 
> > include/asm-generic/io.h:804:29: error: redefinition of 'virt_to_bus'
> > include/asm-generic/io.h:809:21: error: redefinition of 'bus_to_virt'
> > 
> > errors which are also reported in Olof's build system.
> > 
> > Given how close we are to the merge window, I'd suggest this stuff gets
> > reverted so that it can have a better period of testing, rather than
> > stuffing it into -next at such a critical time.
> 
> Right, I've fixed these all up locally, but then found new warnings on
> allmodconfig builds that I haven't been able to track down yet.
> 
> I've dropped everything from the asm-generic tree now, so we can get
> a clean linux-next tree.

Did you actually see any failures due to the relaxed I/O stuff, or was this
all in the unrelated rework of the asm-generic/io.h file? If the latter, it
would be a pity to postpone the former series.

Will

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Monday 29 September 2014 10:25:10 Will Deacon wrote:
> On Fri, Sep 26, 2014 at 10:36:13PM +0100, Arnd Bergmann wrote:
> > On Friday 26 September 2014 14:46:08 Russell King - ARM Linux wrote:
> > > 
> > > Obviously, this does nothing for the:
> > > 
> > > include/asm-generic/io.h:804:29: error: redefinition of 'virt_to_bus'
> > > include/asm-generic/io.h:809:21: error: redefinition of 'bus_to_virt'
> > > 
> > > errors which are also reported in Olof's build system.
> > > 
> > > Given how close we are to the merge window, I'd suggest this stuff gets
> > > reverted so that it can have a better period of testing, rather than
> > > stuffing it into -next at such a critical time.
> > 
> > Right, I've fixed these all up locally, but then found new warnings on
> > allmodconfig builds that I haven't been able to track down yet.
> > 
> > I've dropped everything from the asm-generic tree now, so we can get
> > a clean linux-next tree.
> 
> Did you actually see any failures due to the relaxed I/O stuff, or was this
> all in the unrelated rework of the asm-generic/io.h file? If the latter, it
> would be a pity to postpone the former series.
> 

I believe all the problems I've seen were because of Thierry's series,
I haven't tried separating the two again yet, which is something I'd
probably try today.

However, I saw a lot of different problems with the combined series
and I have a patch to fix them up here, will post that once I see no
new regressions.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Monday 29 September 2014 10:25:10 Will Deacon wrote:
> On Fri, Sep 26, 2014 at 10:36:13PM +0100, Arnd Bergmann wrote:
> > On Friday 26 September 2014 14:46:08 Russell King - ARM Linux wrote:
> > > 
> > > Obviously, this does nothing for the:
> > > 
> > > include/asm-generic/io.h:804:29: error: redefinition of 'virt_to_bus'
> > > include/asm-generic/io.h:809:21: error: redefinition of 'bus_to_virt'
> > > 
> > > errors which are also reported in Olof's build system.
> > > 
> > > Given how close we are to the merge window, I'd suggest this stuff gets
> > > reverted so that it can have a better period of testing, rather than
> > > stuffing it into -next at such a critical time.
> > 
> > Right, I've fixed these all up locally, but then found new warnings on
> > allmodconfig builds that I haven't been able to track down yet.
> > 
> > I've dropped everything from the asm-generic tree now, so we can get
> > a clean linux-next tree.
> 
> Did you actually see any failures due to the relaxed I/O stuff, or was this
> all in the unrelated rework of the asm-generic/io.h file? If the latter, it
> would be a pity to postpone the former series.
> 

I believe all the problems I've seen were because of Thierry's series,
I haven't tried separating the two again yet, which is something I'd
probably try today.

However, I saw a lot of different problems with the combined series
and I have a patch to fix them up here, will post that once I see no
new regressions.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Will Deacon]

Hi Arnd,

On Thu, Sep 25, 2014 at 02:15:10PM +0100, Arnd Bergmann wrote:
> On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> > Hello everybody,
> > 
> > This is version three of the series I've originally posted here:
> > 
> >   v1: https://lkml.org/lkml/2014/4/17/269
> >   v2: https://lkml.org/lkml/2014/5/22/468
> > 
> > This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> > (which was merged into mainline).
> > 
> > I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> > quickly got messy as some architectures (e.g. mips) deliberately keep
> > mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> > drivers to get mmiowb correct, so add barriers to both. Given that
> > arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> > an architecture that does care.
> > 
> > In order to get this lot merged, we probably want to merge the asm-generic
> > patch (1/17) first, so Acks would be much appreciated on the architecture
> > bits.
> > 
> > As before, I've included the original cover letter below, as that describes
> > what I'm trying to do in more detail.
> > 
> 
> I've now applied the parts of your series that are required to have
> every architecture provide all the 'relaxed' accessors to the
> asm-generic tree, on top of Thierry's series.

Since these didn't make it for 3.18, would you like me to repost the series,
or do you already have a branch suitable for 3.19?

Cheers,

Will

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Will Deacon]

Hi Arnd,

On Thu, Sep 25, 2014 at 02:15:10PM +0100, Arnd Bergmann wrote:
> On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> > Hello everybody,
> > 
> > This is version three of the series I've originally posted here:
> > 
> >   v1: https://lkml.org/lkml/2014/4/17/269
> >   v2: https://lkml.org/lkml/2014/5/22/468
> > 
> > This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> > (which was merged into mainline).
> > 
> > I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> > quickly got messy as some architectures (e.g. mips) deliberately keep
> > mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> > drivers to get mmiowb correct, so add barriers to both. Given that
> > arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> > an architecture that does care.
> > 
> > In order to get this lot merged, we probably want to merge the asm-generic
> > patch (1/17) first, so Acks would be much appreciated on the architecture
> > bits.
> > 
> > As before, I've included the original cover letter below, as that describes
> > what I'm trying to do in more detail.
> > 
> 
> I've now applied the parts of your series that are required to have
> every architecture provide all the 'relaxed' accessors to the
> asm-generic tree, on top of Thierry's series.

Since these didn't make it for 3.18, would you like me to repost the series,
or do you already have a branch suitable for 3.19?

Cheers,

Will

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Thursday 30 October 2014 16:59:07 Will Deacon wrote:
> On Thu, Sep 25, 2014 at 02:15:10PM +0100, Arnd Bergmann wrote:
> > On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> > > Hello everybody,
> > > 
> > > This is version three of the series I've originally posted here:
> > > 
> > >   v1: https://lkml.org/lkml/2014/4/17/269
> > >   v2: https://lkml.org/lkml/2014/5/22/468
> > > 
> > > This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> > > (which was merged into mainline).
> > > 
> > > I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> > > quickly got messy as some architectures (e.g. mips) deliberately keep
> > > mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> > > drivers to get mmiowb correct, so add barriers to both. Given that
> > > arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> > > an architecture that does care.
> > > 
> > > In order to get this lot merged, we probably want to merge the asm-generic
> > > patch (1/17) first, so Acks would be much appreciated on the architecture
> > > bits.
> > > 
> > > As before, I've included the original cover letter below, as that describes
> > > what I'm trying to do in more detail.
> > > 
> > 
> > I've now applied the parts of your series that are required to have
> > every architecture provide all the 'relaxed' accessors to the
> > asm-generic tree, on top of Thierry's series.
> 
> Since these didn't make it for 3.18, would you like me to repost the series,
> or do you already have a branch suitable for 3.19?

I still need to figure out how to do this right in combination with Thierry's
patches. Last time I had his patches first and yours on top, and I didn't
manage to rebase your series when his broke.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Arnd Bergmann]

On Thursday 30 October 2014 16:59:07 Will Deacon wrote:
> On Thu, Sep 25, 2014 at 02:15:10PM +0100, Arnd Bergmann wrote:
> > On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> > > Hello everybody,
> > > 
> > > This is version three of the series I've originally posted here:
> > > 
> > >   v1: https://lkml.org/lkml/2014/4/17/269
> > >   v2: https://lkml.org/lkml/2014/5/22/468
> > > 
> > > This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> > > (which was merged into mainline).
> > > 
> > > I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> > > quickly got messy as some architectures (e.g. mips) deliberately keep
> > > mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> > > drivers to get mmiowb correct, so add barriers to both. Given that
> > > arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> > > an architecture that does care.
> > > 
> > > In order to get this lot merged, we probably want to merge the asm-generic
> > > patch (1/17) first, so Acks would be much appreciated on the architecture
> > > bits.
> > > 
> > > As before, I've included the original cover letter below, as that describes
> > > what I'm trying to do in more detail.
> > > 
> > 
> > I've now applied the parts of your series that are required to have
> > every architecture provide all the 'relaxed' accessors to the
> > asm-generic tree, on top of Thierry's series.
> 
> Since these didn't make it for 3.18, would you like me to repost the series,
> or do you already have a branch suitable for 3.19?

I still need to figure out how to do this right in combination with Thierry's
patches. Last time I had his patches first and yours on top, and I didn't
manage to rebase your series when his broke.

	Arnd

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]

On Thu, Oct 30, 2014 at 09:04:54PM +0100, Arnd Bergmann wrote:
> On Thursday 30 October 2014 16:59:07 Will Deacon wrote:
> > On Thu, Sep 25, 2014 at 02:15:10PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> > > > Hello everybody,
> > > > 
> > > > This is version three of the series I've originally posted here:
> > > > 
> > > >   v1: https://lkml.org/lkml/2014/4/17/269
> > > >   v2: https://lkml.org/lkml/2014/5/22/468
> > > > 
> > > > This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> > > > (which was merged into mainline).
> > > > 
> > > > I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> > > > quickly got messy as some architectures (e.g. mips) deliberately keep
> > > > mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> > > > drivers to get mmiowb correct, so add barriers to both. Given that
> > > > arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> > > > an architecture that does care.
> > > > 
> > > > In order to get this lot merged, we probably want to merge the asm-generic
> > > > patch (1/17) first, so Acks would be much appreciated on the architecture
> > > > bits.
> > > > 
> > > > As before, I've included the original cover letter below, as that describes
> > > > what I'm trying to do in more detail.
> > > > 
> > > 
> > > I've now applied the parts of your series that are required to have
> > > every architecture provide all the 'relaxed' accessors to the
> > > asm-generic tree, on top of Thierry's series.
> > 
> > Since these didn't make it for 3.18, would you like me to repost the series,
> > or do you already have a branch suitable for 3.19?
> 
> I still need to figure out how to do this right in combination with Thierry's
> patches. Last time I had his patches first and yours on top, and I didn't
> manage to rebase your series when his broke.

Would it help if we merged both series so that we have to rebase only
once? I'd really like to get the asm-generic/io.h series merged soon
because 64-bit Tegra support depends on it and we'd really like to get
started on that.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v3 00/17] Cross-architecture definitions of relaxed MMIO accessors

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]

On Thu, Oct 30, 2014 at 09:04:54PM +0100, Arnd Bergmann wrote:
> On Thursday 30 October 2014 16:59:07 Will Deacon wrote:
> > On Thu, Sep 25, 2014 at 02:15:10PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 24 September 2014 18:17:19 Will Deacon wrote:
> > > > Hello everybody,
> > > > 
> > > > This is version three of the series I've originally posted here:
> > > > 
> > > >   v1: https://lkml.org/lkml/2014/4/17/269
> > > >   v2: https://lkml.org/lkml/2014/5/22/468
> > > > 
> > > > This is basically just a rebase on top of 3.17-rc6, minus the alpha patch
> > > > (which was merged into mainline).
> > > > 
> > > > I looked at reworking the non-relaxed accessors to imply mmiowb, but it
> > > > quickly got messy as some architectures (e.g. mips) deliberately keep
> > > > mmiowb and readX/writeX separate whilst others (e.g. powerpc) don't trust
> > > > drivers to get mmiowb correct, so add barriers to both. Given that
> > > > arm/arm64/x86 don't care about mmiowb, I've left that as an exercise for
> > > > an architecture that does care.
> > > > 
> > > > In order to get this lot merged, we probably want to merge the asm-generic
> > > > patch (1/17) first, so Acks would be much appreciated on the architecture
> > > > bits.
> > > > 
> > > > As before, I've included the original cover letter below, as that describes
> > > > what I'm trying to do in more detail.
> > > > 
> > > 
> > > I've now applied the parts of your series that are required to have
> > > every architecture provide all the 'relaxed' accessors to the
> > > asm-generic tree, on top of Thierry's series.
> > 
> > Since these didn't make it for 3.18, would you like me to repost the series,
> > or do you already have a branch suitable for 3.19?
> 
> I still need to figure out how to do this right in combination with Thierry's
> patches. Last time I had his patches first and yours on top, and I didn't
> manage to rebase your series when his broke.

Would it help if we merged both series so that we have to rebase only
once? I'd really like to get the asm-generic/io.h series merged soon
because 64-bit Tegra support depends on it and we'd really like to get
started on that.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]