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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev