Received-SPF: pass (google.com: domain of linux-kernel+bounces-6654-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Feedback-ID: i36794607:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3
Precedence: bulk
MIME-Version: 1.0
Message-Id: <55c0b9a5-6ba3-4582-97f0-225d0119da5d@app.fastmail.com>
In-Reply-To: <9c4479a3d194450593d541ae02ad288a@AcuMS.aculab.com>
References: <20231219-sam-sparc32-sunset-v3-v1-0-64bb44b598c5@ravnborg.org>
 <01ea8c41-88cd-4123-95c7-391640845fc3@app.fastmail.com>
 <9c4479a3d194450593d541ae02ad288a@AcuMS.aculab.com>
Date: Wed, 20 Dec 2023 09:51:27 +0000
From: "Arnd Bergmann" <arnd@kernel.org>
To: "David Laight" <David.Laight@ACULAB.COM>,
 "Sam Ravnborg" <sam@ravnborg.org>, "David S . Miller" <davem@davemloft.net>,
 "Andreas Larsson" <andreas@gaisler.com>
Cc: "Helge Deller" <deller@gmx.de>,
 "Alexander Viro" <viro@zeniv.linux.org.uk>,
 "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
 "Alan Stern" <stern@rowland.harvard.edu>, "Jaroslav Kysela" <perex@perex.cz>,
 "Takashi Iwai" <tiwai@suse.com>,
 "sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
 "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
 "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
 "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
 "linux-sound@vger.kernel.org" <linux-sound@vger.kernel.org>
Subject: Re: [PATCH 00/27] sparc32: sunset sun4m and sun4d
Content-Type: text/plain

On Wed, Dec 20, 2023, at 09:34, David Laight wrote:
> From: Arnd Bergmann
>> Sent: 20 December 2023 08:37
>> 
>> On Tue, Dec 19, 2023, at 22:03, Sam Ravnborg via B4 Relay wrote:
>> > TODO before this can be applied:
>> > - Ack from davem - as he is the principal sparc maintainer
>> > - Tested-by: preferably on a target or QEMU (see above)
>> >   I expect bugs as there are some involved changes!
>> >
>> > Ideas for the future
>> > - Apply the most relevant downstream Gaisler patches
>> >   - The ones introducing CAS should have preference as we then
>> >     can drop the cmpxchg emulation
>> 
>> One note about the CAS -- as far as I can tell, the absence
>> of the futex() syscall on sparc32 kernels means that no glibc
>> from the past decade can work correctly as it now requires futex
>> for its internal locking, though it does work on sparc64 kernels
>> in compat32 mode as well as the LEON3 kernel that adds futex
>> support.
>
> Does the glibc mutex 'fast path' also require a CAS instruction?

I think that depends on whether glibc is built for a CPU with
CAS or not. If it's built for 32-bit sparcv9 or leon, it should use
CAS and crash on sparcv8 without CAS. If it's built for pure
sparcv8, it should try to use an emulation that is incompatible
with the kernel futex syscall.

> Presumably having CAS also removes the 'really horrid (tm)' code
> required to make all the bitmap operations atomic?

Yes, but I'm not sure this is implemented in the leon3 tree.
With CAS enabled, at least asm/atomic.h, asm/bitops.h,
asm/cmpxchg.h and asm/spinlock.h can be implemented as efficiently
as they are in the 64-bit version.

> Seems a shame to lose old sparc32 support when (I think) the sun3
> in my cupboard would still work - if only it had a working psu.
> (The 110/220V switch wasn't connected and the FET wasn't rated
> for 450V. UK mains can be 240+10% if you are near a substation.)

sun3 support has never worked upstream. There is an old series from
20 years ago that made it work but nobody ever tried to get it
merged.

       Arnd