All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: linux-arch@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
	"Paul E. McKenney" <paulmck@linux.ibm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Arnd Bergmann <arnd@arndb.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrea Parri <andrea.parri@amarulasolutions.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	Daniel Lustig <dlustig@nvidia.com>,
	David Howells <dhowells@redhat.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Paul Burton <paul.burton@mips.com>,
	Ingo Molnar <mingo@kernel.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, Tony Luck <tony.luck@intel.com>,
	Mikulas Patocka <mpatoc>
Subject: [PATCH v2 14/21] riscv/mmiowb: Hook up mmwiob() implementation to asm-generic code
Date: Fri,  5 Apr 2019 14:59:29 +0100	[thread overview]
Message-ID: <20190405135936.7266-15-will.deacon@arm.com> (raw)
In-Reply-To: <20190405135936.7266-1-will.deacon@arm.com>

In a bid to kill off explicit mmiowb() usage in driver code, hook up
the asm-generic mmiowb() tracking code for riscv, so that an mmiowb()
is automatically issued from spin_unlock() if an I/O write was performed
in the critical section.

Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/riscv/Kconfig              |  1 +
 arch/riscv/include/asm/Kbuild   |  1 -
 arch/riscv/include/asm/io.h     | 15 ++-------------
 arch/riscv/include/asm/mmiowb.h | 14 ++++++++++++++
 4 files changed, 17 insertions(+), 14 deletions(-)
 create mode 100644 arch/riscv/include/asm/mmiowb.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index eb56c82d8aa1..6e30e8126799 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -48,6 +48,7 @@ config RISCV
 	select RISCV_TIMER
 	select GENERIC_IRQ_MULTI_HANDLER
 	select ARCH_HAS_PTE_SPECIAL
+	select ARCH_HAS_MMIOWB
 	select HAVE_EBPF_JIT if 64BIT
 
 config MMU
diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
index 221cd2ec78a4..cccd12cf27d4 100644
--- a/arch/riscv/include/asm/Kbuild
+++ b/arch/riscv/include/asm/Kbuild
@@ -21,7 +21,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mm-arch-hooks.h
-generic-y += mmiowb.h
 generic-y += mutex.h
 generic-y += percpu.h
 generic-y += preempt.h
diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h
index 1d9c1376dc64..744fd92e77bc 100644
--- a/arch/riscv/include/asm/io.h
+++ b/arch/riscv/include/asm/io.h
@@ -20,6 +20,7 @@
 #define _ASM_RISCV_IO_H
 
 #include <linux/types.h>
+#include <asm/mmiowb.h>
 
 extern void __iomem *ioremap(phys_addr_t offset, unsigned long size);
 
@@ -100,18 +101,6 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
 #endif
 
 /*
- * FIXME: I'm flip-flopping on whether or not we should keep this or enforce
- * the ordering with I/O on spinlocks like PowerPC does.  The worry is that
- * drivers won't get this correct, but I also don't want to introduce a fence
- * into the lock code that otherwise only uses AMOs (and is essentially defined
- * by the ISA to be correct).   For now I'm leaving this here: "o,w" is
- * sufficient to ensure that all writes to the device have completed before the
- * write to the spinlock is allowed to commit.  I surmised this from reading
- * "ACQUIRES VS I/O ACCESSES" in memory-barriers.txt.
- */
-#define mmiowb()	__asm__ __volatile__ ("fence o,w" : : : "memory");
-
-/*
  * Unordered I/O memory access primitives.  These are even more relaxed than
  * the relaxed versions, as they don't even order accesses between successive
  * operations to the I/O regions.
@@ -165,7 +154,7 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
 #define __io_br()	do {} while (0)
 #define __io_ar(v)	__asm__ __volatile__ ("fence i,r" : : : "memory");
 #define __io_bw()	__asm__ __volatile__ ("fence w,o" : : : "memory");
-#define __io_aw()	do {} while (0)
+#define __io_aw()	mmiowb_set_pending()
 
 #define readb(c)	({ u8  __v; __io_br(); __v = readb_cpu(c); __io_ar(__v); __v; })
 #define readw(c)	({ u16 __v; __io_br(); __v = readw_cpu(c); __io_ar(__v); __v; })
diff --git a/arch/riscv/include/asm/mmiowb.h b/arch/riscv/include/asm/mmiowb.h
new file mode 100644
index 000000000000..5d7e3a2b4e3b
--- /dev/null
+++ b/arch/riscv/include/asm/mmiowb.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_RISCV_MMIOWB_H
+#define _ASM_RISCV_MMIOWB_H
+
+/*
+ * "o,w" is sufficient to ensure that all writes to the device have completed
+ * before the write to the spinlock is allowed to commit.
+ */
+#define mmiowb()	__asm__ __volatile__ ("fence o,w" : : : "memory");
+
+#include <asm-generic/mmiowb.h>
+
+#endif	/* ASM_RISCV_MMIOWB_H */
-- 
2.11.0

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: linux-arch@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
	"Paul E. McKenney" <paulmck@linux.ibm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Arnd Bergmann <arnd@arndb.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrea Parri <andrea.parri@amarulasolutions.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	Daniel Lustig <dlustig@nvidia.com>,
	David Howells <dhowells@redhat.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Paul Burton <paul.burton@mips.com>,
	Ingo Molnar <mingo@kernel.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, Tony Luck <tony.luck@intel.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	Akira Yokosawa <akiyks@gmail.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>
Subject: [PATCH v2 14/21] riscv/mmiowb: Hook up mmwiob() implementation to asm-generic code
Date: Fri,  5 Apr 2019 14:59:29 +0100	[thread overview]
Message-ID: <20190405135936.7266-15-will.deacon@arm.com> (raw)
Message-ID: <20190405135929.OcVix29wJJOef1kvBIhF358I-UaWQFBD2yAwX5_c9gk@z> (raw)
In-Reply-To: <20190405135936.7266-1-will.deacon@arm.com>

In a bid to kill off explicit mmiowb() usage in driver code, hook up
the asm-generic mmiowb() tracking code for riscv, so that an mmiowb()
is automatically issued from spin_unlock() if an I/O write was performed
in the critical section.

Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/riscv/Kconfig              |  1 +
 arch/riscv/include/asm/Kbuild   |  1 -
 arch/riscv/include/asm/io.h     | 15 ++-------------
 arch/riscv/include/asm/mmiowb.h | 14 ++++++++++++++
 4 files changed, 17 insertions(+), 14 deletions(-)
 create mode 100644 arch/riscv/include/asm/mmiowb.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index eb56c82d8aa1..6e30e8126799 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -48,6 +48,7 @@ config RISCV
 	select RISCV_TIMER
 	select GENERIC_IRQ_MULTI_HANDLER
 	select ARCH_HAS_PTE_SPECIAL
+	select ARCH_HAS_MMIOWB
 	select HAVE_EBPF_JIT if 64BIT
 
 config MMU
diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
index 221cd2ec78a4..cccd12cf27d4 100644
--- a/arch/riscv/include/asm/Kbuild
+++ b/arch/riscv/include/asm/Kbuild
@@ -21,7 +21,6 @@ generic-y += kvm_para.h
 generic-y += local.h
 generic-y += local64.h
 generic-y += mm-arch-hooks.h
-generic-y += mmiowb.h
 generic-y += mutex.h
 generic-y += percpu.h
 generic-y += preempt.h
diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h
index 1d9c1376dc64..744fd92e77bc 100644
--- a/arch/riscv/include/asm/io.h
+++ b/arch/riscv/include/asm/io.h
@@ -20,6 +20,7 @@
 #define _ASM_RISCV_IO_H
 
 #include <linux/types.h>
+#include <asm/mmiowb.h>
 
 extern void __iomem *ioremap(phys_addr_t offset, unsigned long size);
 
@@ -100,18 +101,6 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
 #endif
 
 /*
- * FIXME: I'm flip-flopping on whether or not we should keep this or enforce
- * the ordering with I/O on spinlocks like PowerPC does.  The worry is that
- * drivers won't get this correct, but I also don't want to introduce a fence
- * into the lock code that otherwise only uses AMOs (and is essentially defined
- * by the ISA to be correct).   For now I'm leaving this here: "o,w" is
- * sufficient to ensure that all writes to the device have completed before the
- * write to the spinlock is allowed to commit.  I surmised this from reading
- * "ACQUIRES VS I/O ACCESSES" in memory-barriers.txt.
- */
-#define mmiowb()	__asm__ __volatile__ ("fence o,w" : : : "memory");
-
-/*
  * Unordered I/O memory access primitives.  These are even more relaxed than
  * the relaxed versions, as they don't even order accesses between successive
  * operations to the I/O regions.
@@ -165,7 +154,7 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
 #define __io_br()	do {} while (0)
 #define __io_ar(v)	__asm__ __volatile__ ("fence i,r" : : : "memory");
 #define __io_bw()	__asm__ __volatile__ ("fence w,o" : : : "memory");
-#define __io_aw()	do {} while (0)
+#define __io_aw()	mmiowb_set_pending()
 
 #define readb(c)	({ u8  __v; __io_br(); __v = readb_cpu(c); __io_ar(__v); __v; })
 #define readw(c)	({ u16 __v; __io_br(); __v = readw_cpu(c); __io_ar(__v); __v; })
diff --git a/arch/riscv/include/asm/mmiowb.h b/arch/riscv/include/asm/mmiowb.h
new file mode 100644
index 000000000000..5d7e3a2b4e3b
--- /dev/null
+++ b/arch/riscv/include/asm/mmiowb.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_RISCV_MMIOWB_H
+#define _ASM_RISCV_MMIOWB_H
+
+/*
+ * "o,w" is sufficient to ensure that all writes to the device have completed
+ * before the write to the spinlock is allowed to commit.
+ */
+#define mmiowb()	__asm__ __volatile__ ("fence o,w" : : : "memory");
+
+#include <asm-generic/mmiowb.h>
+
+#endif	/* ASM_RISCV_MMIOWB_H */
-- 
2.11.0

  parent reply	other threads:[~2019-04-05 13:59 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-05 13:59 [PATCH v2 00/21] Remove Mysterious Macro Intended to Obscure Weird Behaviours (mmiowb()) Will Deacon
2019-04-05 13:59 ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-10 10:58   ` Ingo Molnar
2019-04-10 10:58     ` Ingo Molnar
2019-04-10 12:28     ` Will Deacon
2019-04-10 12:28       ` Will Deacon
2019-04-10 12:28       ` Will Deacon
2019-04-11 11:00       ` Ingo Molnar
2019-04-11 11:00         ` Ingo Molnar
2019-04-11 22:12   ` Benjamin Herrenschmidt
2019-04-11 22:12     ` Benjamin Herrenschmidt
2019-04-11 22:34     ` Linus Torvalds
2019-04-11 22:34       ` Linus Torvalds
2019-04-12  2:07       ` Benjamin Herrenschmidt
2019-04-12  2:07         ` Benjamin Herrenschmidt
2019-04-12 13:17         ` Will Deacon
2019-04-12 13:17           ` Will Deacon
2019-04-15  4:05           ` Benjamin Herrenschmidt
2019-04-15  4:05             ` Benjamin Herrenschmidt
2019-04-16  9:13             ` Will Deacon
2019-04-16  9:13               ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 02/21] asm-generic/mmiowb: Add generic implementation of mmiowb() tracking Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 03/21] arch: Use asm-generic header for asm/mmiowb.h Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 04/21] mmiowb: Hook up mmiowb helpers to spinlocks and generic I/O accessors Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 05/21] ARM/io: Remove useless definition of mmiowb() Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 06/21] arm64/io: " Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 07/21] x86/io: " Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 14:14   ` Thomas Gleixner
2019-04-05 14:14     ` Thomas Gleixner
2019-04-05 13:59 ` [PATCH v2 08/21] nds32/io: " Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 09/21] m68k/io: " Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 10/21] sh/mmiowb: Add unconditional mmiowb() to arch_spin_unlock() Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 11/21] mips/mmiowb: " Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 12/21] ia64/mmiowb: " Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 13/21] powerpc/mmiowb: Hook up mmwiob() implementation to asm-generic code Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` Will Deacon [this message]
2019-04-05 13:59   ` [PATCH v2 14/21] riscv/mmiowb: " Will Deacon
2019-04-05 13:59 ` [PATCH v2 15/21] Documentation: Kill all references to mmiowb() Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 16/21] drivers: Remove useless trailing comments from mmiowb() invocations Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 17/21] drivers: Remove explicit invocations of mmiowb() Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 15:50   ` Linus Torvalds
2019-04-05 15:50     ` Linus Torvalds
2019-04-09  9:00     ` Nicholas Piggin
2019-04-09  9:00       ` Nicholas Piggin
2019-04-09 13:46       ` Will Deacon
2019-04-09 13:46         ` Will Deacon
2019-04-10  0:25         ` Nicholas Piggin
2019-04-10  0:25           ` Nicholas Piggin
2019-04-05 13:59 ` [PATCH v2 18/21] scsi/qla1280: Remove stale comment about mmiowb() Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 19/21] i40iw: Redefine i40iw_mmiowb() to do nothing Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 20/21] net/ethernet/silan/sc92031: Remove stale comment about mmiowb() Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 13:59 ` [PATCH v2 21/21] arch: Remove dummy mmiowb() definitions from arch code Will Deacon
2019-04-05 13:59   ` Will Deacon
2019-04-05 15:55 ` [PATCH v2 00/21] Remove Mysterious Macro Intended to Obscure Weird Behaviours (mmiowb()) Linus Torvalds
2019-04-05 15:55   ` Linus Torvalds
2019-04-05 16:09   ` Will Deacon
2019-04-05 16:09     ` Will Deacon
2019-04-05 16:15     ` Linus Torvalds
2019-04-05 16:15       ` Linus Torvalds
2019-04-05 16:30       ` Will Deacon
2019-04-05 16:30         ` Will Deacon

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20190405135936.7266-15-will.deacon@arm.com \
    --to=will.deacon@arm.com \
    --cc=andrea.parri@amarulasolutions.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=dalias@libc.org \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=palmer@sifive.com \
    --cc=paul.burton@mips.com \
    --cc=paulmck@linux.ibm.com \
    --cc=peterz@infradead.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=ysato@users.sourceforge.jp \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.