search for: metag_fence

...oved as they are > defined correctly by asm-generic/barriers.h > > Note: as __smp_XX macros should not depend on CONFIG_SMP, they can not > use the existing fence() macro since that is defined differently between > SMP and !SMP. For this reason, this patch introduces a wrapper > metag_fence() that doesn't depend on CONFIG_SMP. > fence() is then defined using that, depending on CONFIG_SMP. I'm not a fan of the inconsistent commit message wrapping. I wrap to 72 columns (although I now notice SubmittingPatches says to use 75...). > > Signed-off-by: Michael S. Tsirkin...

...oved as they are > defined correctly by asm-generic/barriers.h > > Note: as __smp_XX macros should not depend on CONFIG_SMP, they can not > use the existing fence() macro since that is defined differently between > SMP and !SMP. For this reason, this patch introduces a wrapper > metag_fence() that doesn't depend on CONFIG_SMP. > fence() is then defined using that, depending on CONFIG_SMP. I'm not a fan of the inconsistent commit message wrapping. I wrap to 72 columns (although I now notice SubmittingPatches says to use 75...). > > Signed-off-by: Michael S. Tsirkin...

...ion. smp_xxx barriers are removed as they are defined correctly by asm-generic/barriers.h Note: as __smp_XX macros should not depend on CONFIG_SMP, they can not use the existing fence() macro since that is defined differently between SMP and !SMP. For this reason, this patch introduces a wrapper metag_fence() that doesn't depend on CONFIG_SMP. fence() is then defined using that, depending on CONFIG_SMP. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Acked-by: Arnd Bergmann <arnd at arndb.de> --- arch/metag/include/asm/barrier.h | 32 +++++++++++++++----------------- 1 file cha...

On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote: > +#ifdef CONFIG_SMP > +#define fence() metag_fence() > +#else > +#define fence() do { } while (0) > #endif James, it strikes me as odd that fence() is a no-op instead of a barrier() for UP, can you verify/explain?

On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote: > +#ifdef CONFIG_SMP > +#define fence() metag_fence() > +#else > +#define fence() do { } while (0) > #endif James, it strikes me as odd that fence() is a no-op instead of a barrier() for UP, can you verify/explain?

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

Hi Peter, On Mon, Jan 04, 2016 at 02:41:28PM +0100, Peter Zijlstra wrote: > On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote: > > +#ifdef CONFIG_SMP > > +#define fence() metag_fence() > > +#else > > +#define fence() do { } while (0) > > #endif > > James, it strikes me as odd that fence() is a no-op instead of a > barrier() for UP, can you verify/explain? fence() is an unfortunate workaround for a specific issue on a certain SoC, where writes from...

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