#ifndef __TOOLS_LINUX_SPARC64_BARRIER_H #define __TOOLS_LINUX_SPARC64_BARRIER_H /* Copied from the kernel sources to tools/: * * These are here in an effort to more fully work around Spitfire Errata * #51. Essentially, if a memory barrier occurs soon after a mispredicted * branch, the chip can stop executing instructions until a trap occurs. * Therefore, if interrupts are disabled, the chip can hang forever. * * It used to be believed that the memory barrier had to be right in the * delay slot, but a case has been traced recently wherein the memory barrier * was one instruction after the branch delay slot and the chip still hung. * The offending sequence was the following in sym_wakeup_done() of the * sym53c8xx_2 driver: * * call sym_ccb_from_dsa, 0 * movge %icc, 0, %l0 * brz,pn %o0, .LL1303 * mov %o0, %l2 * membar #LoadLoad * * The branch has to be mispredicted for the bug to occur. Therefore, we put * the memory barrier explicitly into a "branch always, predicted taken" * delay slot to avoid the problem case. */ #define membar_safe(type) \ do { __asm__ __volatile__("ba,pt %%xcc, 1f\n\t" \ " membar " type "\n" \ "1:\n" \ : : : "memory"); \ } while (0) /* The kernel always executes in TSO memory model these days, * and furthermore most sparc64 chips implement more stringent * memory ordering than required by the specifications. */ #define mb() membar_safe("#StoreLoad") #define rmb() __asm__ __volatile__("":::"memory") #define wmb() __asm__ __volatile__("":::"memory") #endif /* !(__TOOLS_LINUX_SPARC64_BARRIER_H) */ linux/net-next.git/refs/?h=nds-private-remove&id=d63ffc45c5d3df15f6fc8c73079458ce4a111995'>refslogtreecommitdiff
path: root/sound/soc/tegra/Makefile
text' onchange='this.form.submit();'>
AgeCommit message (Expand)AuthorFilesLines
space:
mode:
authorJiri Slaby <jslaby@suse.cz>2017-01-18 14:29:21 +0100
committerIngo Molnar <mingo@kernel.org>2017-01-19 08:39:44 +0100
commitb5b46c4740aed1538544f0fa849c5b76c7823469 (patch)
tree125e7aced4835bad6f6a0c0d02d012f333caf922 /sound/soc/codecs/wm8900.h
parentfa19a769f82fb9a5ca000b83cacd13fcaeda51ac (diff)
objtool: Fix IRET's opcode
The IRET opcode is 0xcf according to the Intel manual and also to objdump of my vmlinux: 1ea8: 48 cf iretq Fix the opcode in arch_decode_instruction(). The previous value (0xc5) seems to correspond to LDS. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20170118132921.19319-1-jslaby@suse.cz Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'sound/soc/codecs/wm8900.h')