[patch 1/2] powerpc: rmb fix
Nick Piggin
npiggin at suse.de
Wed Aug 22 13:15:06 EST 2007
On Tue, Aug 21, 2007 at 09:43:17PM +0200, Segher Boessenkool wrote:
> >> #define mb() __asm__ __volatile__ ("sync" : : : "memory")
> >>-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
> >>"memory")
> >>+#define rmb() __asm__ __volatile__ ("sync" : : : "memory")
> >> #define wmb() __asm__ __volatile__ ("sync" : : : "memory")
> >> #define read_barrier_depends() do { } while(0)
> >>
> >>@@ -42,7 +42,7 @@
> >> #ifdef __KERNEL__
> >> #ifdef CONFIG_SMP
> >> #define smp_mb() mb()
> >>-#define smp_rmb() rmb()
> >>+#define smp_rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : :
> >>"memory")
> >> #define smp_wmb() eieio()
> >> #define smp_read_barrier_depends() read_barrier_depends()
> >> #else
> >
> >I had to think about this one for awhile. It looks at first glance to
> >be the right
> >thing to do. But I do wonder how long rmb() has been lwsync
>
> Since the {ppc,ppc64} -> powerpc merge.
>
> >and if as a practical matter that has caused any problems?
>
> It has not as far as I know.
>
> >If this isn't causing any problems maybe there
> >is some loigic we are overlooking?
>
> The I/O accessor functions enforce the necessary ordering
> already I believe.
Hmm, I never followed those discussions last year about IO ordering, and
I can't see where (if) it was documented anywhere :(
It appears that legacy code is handled by defining the old IO accessors to
be completely ordered, and introducing new __raw_ variants that are not
(OTOH, it seems like other architectures are implementing __raw prefix as
inorder unless there is a _relaxed postfix).
Drivers are definitely using these __raw_ accessors, and from a quick
look, they do appear to be hoping that *mb() is going to order access for
them.
More information about the Linuxppc-dev
mailing list