search for: linsysevent_wr_atomic_unlock

...+53,31 @@ static inline void wr_fence(void) > * incoherence). It is therefore ineffective if used after and on the same > * thread as a write. > */ > -static inline void fence(void) > +static inline void metag_fence(void) > { > volatile int *flushptr = (volatile int *) LINSYSEVENT_WR_ATOMIC_UNLOCK; > barrier(); > *flushptr = 0; > barrier(); > } > -#define smp_mb() fence() > -#define smp_rmb() fence() > -#define smp_wmb() barrier() > +#define __smp_mb() metag_fence() > +#define __smp_rmb() metag_fence() > +#define __smp_wmb(...

...+53,31 @@ static inline void wr_fence(void) > * incoherence). It is therefore ineffective if used after and on the same > * thread as a write. > */ > -static inline void fence(void) > +static inline void metag_fence(void) > { > volatile int *flushptr = (volatile int *) LINSYSEVENT_WR_ATOMIC_UNLOCK; > barrier(); > *flushptr = 0; > barrier(); > } > -#define smp_mb() fence() > -#define smp_rmb() fence() > -#define smp_wmb() barrier() > +#define __smp_mb() metag_fence() > +#define __smp_rmb() metag_fence() > +#define __smp_wmb(...

...ter (command 0). This is @@ -60,26 +53,31 @@ static inline void wr_fence(void) * incoherence). It is therefore ineffective if used after and on the same * thread as a write. */ -static inline void fence(void) +static inline void metag_fence(void) { volatile int *flushptr = (volatile int *) LINSYSEVENT_WR_ATOMIC_UNLOCK; barrier(); *flushptr = 0; barrier(); } -#define smp_mb() fence() -#define smp_rmb() fence() -#define smp_wmb() barrier() +#define __smp_mb() metag_fence() +#define __smp_rmb() metag_fence() +#define __smp_wmb() barrier() #else -#define fence() do { }...

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh