Following Peter Z's patch ("asm-generic: Disallow no-op mb() for SMP
systems") which makes mb() mandatory for SMP architectures we define it
as l.msync. On OpenRISC this will flush the current cores write buffer
and trigger remote cores to invalidate their caches of the written
memory.
Signed-off-by: Stafford Horne <[email protected]>
Link: https://lkml.org/lkml/2018/1/31/254
Cc: Peter Zijlstra <[email protected]>
Cc: Will Deacon <[email protected]>
---
Notes:
- Sorry, its been a while since we discussed this patch is the parent to this
still going in Peter?
- I have not got around to updating our architecture spec for the TSO/PSO
notes we discussed.
arch/openrisc/include/asm/Kbuild | 1 -
arch/openrisc/include/asm/barrier.h | 8 ++++++++
2 files changed, 8 insertions(+), 1 deletion(-)
create mode 100644 arch/openrisc/include/asm/barrier.h
diff --git a/arch/openrisc/include/asm/Kbuild b/arch/openrisc/include/asm/Kbuild
index 6eb16719549e..fea95ee2fb84 100644
--- a/arch/openrisc/include/asm/Kbuild
+++ b/arch/openrisc/include/asm/Kbuild
@@ -1,4 +1,3 @@
-generic-y += barrier.h
generic-y += bug.h
generic-y += bugs.h
generic-y += checksum.h
diff --git a/arch/openrisc/include/asm/barrier.h b/arch/openrisc/include/asm/barrier.h
new file mode 100644
index 000000000000..77eaad9ba0c4
--- /dev/null
+++ b/arch/openrisc/include/asm/barrier.h
@@ -0,0 +1,8 @@
+#ifndef _ASM_OPENRISC_BARRIER_H
+#define _ASM_OPENRISC_BARRIER_H
+
+#define mb() asm volatile ("l.msync":::"memory")
+
+#include <asm-generic/barrier.h>
+
+#endif /* _ASM_OPENRISC_BARRIER_H */
--
2.13.6
On Sat, Apr 07, 2018 at 05:58:49AM +0900, Stafford Horne wrote:
> Following Peter Z's patch ("asm-generic: Disallow no-op mb() for SMP
> systems") which makes mb() mandatory for SMP architectures we define it
> as l.msync. On OpenRISC this will flush the current cores write buffer
> and trigger remote cores to invalidate their caches of the written
> memory.
>
> Signed-off-by: Stafford Horne <[email protected]>
> Link: https://lkml.org/lkml/2018/1/31/254
> Cc: Peter Zijlstra <[email protected]>
> Cc: Will Deacon <[email protected]>
> ---
>
> Notes:
> - Sorry, its been a while since we discussed this patch is the parent to this
> still going in Peter?
Oops.. yes it should. It seems I also lost track of it. Thanks for the
reminder!
On Sat, Apr 07, 2018 at 11:09:05AM +0200, Peter Zijlstra wrote:
> On Sat, Apr 07, 2018 at 05:58:49AM +0900, Stafford Horne wrote:
> > Following Peter Z's patch ("asm-generic: Disallow no-op mb() for SMP
> > systems") which makes mb() mandatory for SMP architectures we define it
> > as l.msync. On OpenRISC this will flush the current cores write buffer
> > and trigger remote cores to invalidate their caches of the written
> > memory.
> >
> > Signed-off-by: Stafford Horne <[email protected]>
> > Link: https://lkml.org/lkml/2018/1/31/254
> > Cc: Peter Zijlstra <[email protected]>
> > Cc: Will Deacon <[email protected]>
> > ---
> >
> > Notes:
> > - Sorry, its been a while since we discussed this patch is the parent to this
> > still going in Peter?
>
> Oops.. yes it should. It seems I also lost track of it. Thanks for the
> reminder!
No Problem,
If you think this patch makes sense I can just put it into my OpenRISC queue for
4.17. I dont see any reason to wait for yours. Any thoughts?
-Stafford
On Sun, Apr 08, 2018 at 09:07:29AM +0900, Stafford Horne wrote:
> On Sat, Apr 07, 2018 at 11:09:05AM +0200, Peter Zijlstra wrote:
> > On Sat, Apr 07, 2018 at 05:58:49AM +0900, Stafford Horne wrote:
> > > Following Peter Z's patch ("asm-generic: Disallow no-op mb() for SMP
> > > systems") which makes mb() mandatory for SMP architectures we define it
> > > as l.msync. On OpenRISC this will flush the current cores write buffer
> > > and trigger remote cores to invalidate their caches of the written
> > > memory.
> > >
> > > Signed-off-by: Stafford Horne <[email protected]>
> > > Link: https://lkml.org/lkml/2018/1/31/254
> > > Cc: Peter Zijlstra <[email protected]>
> > > Cc: Will Deacon <[email protected]>
> > > ---
> > >
> > > Notes:
> > > - Sorry, its been a while since we discussed this patch is the parent to this
> > > still going in Peter?
> >
> > Oops.. yes it should. It seems I also lost track of it. Thanks for the
> > reminder!
>
> No Problem,
>
> If you think this patch makes sense I can just put it into my OpenRISC queue for
> 4.17. I dont see any reason to wait for yours. Any thoughts?
I'm fine with you taking the patch, but I just saw the build robot found
two failure cases: PARISC and 32-bit SPARC. I send patches for both, if
their respective maintainers agree you could do the lot.