18c2ecf20Sopenharmony_ci/* SPDX-License-Identifier: GPL-2.0 */
28c2ecf20Sopenharmony_ci#ifndef __TOOLS_LINUX_SPARC64_BARRIER_H
38c2ecf20Sopenharmony_ci#define __TOOLS_LINUX_SPARC64_BARRIER_H
48c2ecf20Sopenharmony_ci
58c2ecf20Sopenharmony_ci/* Copied from the kernel sources to tools/:
68c2ecf20Sopenharmony_ci *
78c2ecf20Sopenharmony_ci * These are here in an effort to more fully work around Spitfire Errata
88c2ecf20Sopenharmony_ci * #51.  Essentially, if a memory barrier occurs soon after a mispredicted
98c2ecf20Sopenharmony_ci * branch, the chip can stop executing instructions until a trap occurs.
108c2ecf20Sopenharmony_ci * Therefore, if interrupts are disabled, the chip can hang forever.
118c2ecf20Sopenharmony_ci *
128c2ecf20Sopenharmony_ci * It used to be believed that the memory barrier had to be right in the
138c2ecf20Sopenharmony_ci * delay slot, but a case has been traced recently wherein the memory barrier
148c2ecf20Sopenharmony_ci * was one instruction after the branch delay slot and the chip still hung.
158c2ecf20Sopenharmony_ci * The offending sequence was the following in sym_wakeup_done() of the
168c2ecf20Sopenharmony_ci * sym53c8xx_2 driver:
178c2ecf20Sopenharmony_ci *
188c2ecf20Sopenharmony_ci *	call	sym_ccb_from_dsa, 0
198c2ecf20Sopenharmony_ci *	 movge	%icc, 0, %l0
208c2ecf20Sopenharmony_ci *	brz,pn	%o0, .LL1303
218c2ecf20Sopenharmony_ci *	 mov	%o0, %l2
228c2ecf20Sopenharmony_ci *	membar	#LoadLoad
238c2ecf20Sopenharmony_ci *
248c2ecf20Sopenharmony_ci * The branch has to be mispredicted for the bug to occur.  Therefore, we put
258c2ecf20Sopenharmony_ci * the memory barrier explicitly into a "branch always, predicted taken"
268c2ecf20Sopenharmony_ci * delay slot to avoid the problem case.
278c2ecf20Sopenharmony_ci */
288c2ecf20Sopenharmony_ci#define membar_safe(type) \
298c2ecf20Sopenharmony_cido {	__asm__ __volatile__("ba,pt	%%xcc, 1f\n\t" \
308c2ecf20Sopenharmony_ci			     " membar	" type "\n" \
318c2ecf20Sopenharmony_ci			     "1:\n" \
328c2ecf20Sopenharmony_ci			     : : : "memory"); \
338c2ecf20Sopenharmony_ci} while (0)
348c2ecf20Sopenharmony_ci
358c2ecf20Sopenharmony_ci/* The kernel always executes in TSO memory model these days,
368c2ecf20Sopenharmony_ci * and furthermore most sparc64 chips implement more stringent
378c2ecf20Sopenharmony_ci * memory ordering than required by the specifications.
388c2ecf20Sopenharmony_ci */
398c2ecf20Sopenharmony_ci#define mb()	membar_safe("#StoreLoad")
408c2ecf20Sopenharmony_ci#define rmb()	__asm__ __volatile__("":::"memory")
418c2ecf20Sopenharmony_ci#define wmb()	__asm__ __volatile__("":::"memory")
428c2ecf20Sopenharmony_ci
438c2ecf20Sopenharmony_ci#define smp_store_release(p, v)			\
448c2ecf20Sopenharmony_cido {						\
458c2ecf20Sopenharmony_ci	barrier();				\
468c2ecf20Sopenharmony_ci	WRITE_ONCE(*p, v);			\
478c2ecf20Sopenharmony_ci} while (0)
488c2ecf20Sopenharmony_ci
498c2ecf20Sopenharmony_ci#define smp_load_acquire(p)			\
508c2ecf20Sopenharmony_ci({						\
518c2ecf20Sopenharmony_ci	typeof(*p) ___p1 = READ_ONCE(*p);	\
528c2ecf20Sopenharmony_ci	barrier();				\
538c2ecf20Sopenharmony_ci	___p1;					\
548c2ecf20Sopenharmony_ci})
558c2ecf20Sopenharmony_ci
568c2ecf20Sopenharmony_ci#endif /* !(__TOOLS_LINUX_SPARC64_BARRIER_H) */
57