Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 21 Oct 2021 12:20:05 +0200 (CEST)
From:   "Maciej W. Rozycki" <macro@orcam.me.uk>
To:     Thomas Bogendoerfer <tsbogend@alpha.franken.de>
cc:     linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org
Subject: Re: [PATCH] MIPS: Fix assembly error from MIPSr2 code used within
 MIPS_ISA_ARCH_LEVEL
In-Reply-To: <alpine.DEB.2.21.2110210054080.31442@angie.orcam.me.uk>
Message-ID: <alpine.DEB.2.21.2110211213090.31442@angie.orcam.me.uk>
References: <alpine.DEB.2.21.2110210054080.31442@angie.orcam.me.uk>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Thu, 21 Oct 2021, Maciej W. Rozycki wrote:

> The assembly architecture override is only there for the LLD/SCD 
> instructions, so fix the problem by wrapping these instructions on their 
> own only, following the practice established with commit cfd54de3b0e4 
> ("MIPS: Avoid move psuedo-instruction whilst using MIPS_ISA_LEVEL") and 
> commit 378ed6f0e3c5 ("MIPS: Avoid using .set mips0 to restore ISA").

 Scrap it!  There's so much accumulated cruft around the handling of LL/SC 
sequences that I forgot what the original intent was.  The whole sequence 
has to be assembled for an explicit 64-bit ISA of course as it's meant to 
work with 32-bit kernels.  The commits referred above are red herrings, 
and should not have been needed in the first place if not for the cruft.

 I don't think I'll get to cleaning up the cruft anytime soon, but I'll 
post v2 tonight to address this specific issue.  Long-term perhaps we can 
make some extraneous hacks (ones to address issues with earlier hacks) go 
away.

  Maciej