Now I remembered reading something from 2013 on 'lwsync',
https://gcc.gnu.org/legacy-ml/gcc-patches/2006-11/msg01238.html
https://gcc.gnu.org/legacy-ml/gcc-patches/2012-07/msg01062.html
so that would end up something like
---
a/media/thread/12fd50d6-d14c-42af-ad1d-a595e5f080cd/dev/linux-main/linux/arch/powerpc/lib/sstep.c
+++ b/home/thread/dev/linus/linux/arch/powerpc/lib/sstep.c
@@ -3265,7 +3265,11 @@ void emulate_update_regs(struct pt_regs *regs,
struct instruction_op *op)
eieio();
break;
case BARRIER_LWSYNC:
+#if defined (CONFIG_40x || CONFIG_44x || CONFIG_E500 ||
CONFIG_PPA8548 || CONFIG_TQM8548 || CONFIG_MPC8540_ADS ||
CONFIG_PPC_BOOK3S_603)
+ asm volatile("sync" : : : "memory");
+#else
asm volatile("lwsync" : : : "memory");
+#endif
break;
#ifdef CONFIG_PPC64
case BARRIER_PTESYNC:
On Sun, 23 Jan 2022 at 15:18, Mike <michael.hel...@gmail.com> wrote:
>
> Maybe cite the correct parts of the patch where my questions arose for
> context.
> ---
> diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
> index a94b0cd0bdc5ca..4ffd6791b03ec0 100644
> --- a/arch/powerpc/lib/sstep.c
> +++ b/arch/powerpc/lib/sstep.c
> @@ -1465,7 +1465,7 @@ int analyse_instr(struct instruction_op *op,
> const struct pt_regs *regs,
> switch ((word >> 1) & 0x3ff) {
> case 598: /* sync */
> op->type = BARRIER + BARRIER_SYNC;
> -#ifdef __powerpc64__
> +#ifdef CONFIG_PPC64
> switch ((word >> 21) & 3) {
> case 1: /* lwsync */
> op->type = BARRIER + BARRIER_LWSYNC;
> @@ -3267,9 +3267,11 @@ void emulate_update_regs(struct pt_regs *regs,
> struct instruction_op *op)
> case BARRIER_LWSYNC:
> asm volatile("lwsync" : : : "memory");
> break;
> +#ifdef CONFIG_PPC64
> case BARRIER_PTESYNC:
> asm volatile("ptesync" : : : "memory");
> break;
> +#endif
> }
> break;
> -----
>
> On Sun, 23 Jan 2022 at 14:43, Mike <michael.hel...@gmail.com> wrote:
> >
> > As some have probably noticed, we are seeing errors like ' Error:
> > unrecognized opcode: `ptesync'' 'dssall' and 'stbcix' as a result of
> > binutils changes, making compiling all that more fun again. The only
> > question on my mind still is this:
> > ----
> > diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
> > index beba4979bff939..d3a9c91cd06a8b 100644
> > --- a/arch/powerpc/include/asm/io.h
> > +++ b/arch/powerpc/include/asm/io.h
> > @@ -334,7 +334,7 @@ static inline void __raw_writel(unsigned int v,
> > volatile void __iomem *addr)
> > }
> > #define __raw_writel __raw_writel
> >
> > -#ifdef __powerpc64__
> > +#ifdef CONFIG_PPC64
> > static inline unsigned long __raw_readq(const volatile void __iomem *addr)
> > {
> > return *(volatile unsigned long __force *)PCI_FIX_ADDR(addr);
> > @@ -352,7 +352,8 @@ static inline void __raw_writeq_be(unsigned long
> > v, volatile void __iomem *addr)
> > __raw_writeq((__force unsigned long)cpu_to_be64(v), addr);
> > }
> > #define __raw_writeq_be __raw_writeq_be
> > -
> > +#endif
> > +#ifdef CONFIG_POWER6_CPU
> > /*
> > * Real mode versions of the above. Those instructions are only supposed
> > * to be used in hypervisor real mode as per the architecture spec.
> > @@ -417,7 +418,7 @@ static inline u64 __raw_rm_readq(volatile void
> > __iomem *paddr)
> > : "=r" (ret) : "r" (paddr) : "memory");
> > return ret;
> > }
> > -#endif /* __powerpc64__ */
> >
> > +#endif /* CONFIG_POWER6_CPU */
> >
> > ---
> > Will there come a mail saying this broke the PPC6'ish based CPU
> > someone made in their garage? And lwesync is a valid PPC32
> > instruction, should i just follow the example above where
> > BARRIER_LWESYNC is PPC64 only?
> >
> > https://github.com/threader/linux/commits/master-build-ppc - linux-next
> >
> > Best regards.
> > Michael Heltne
