[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6201870b-b50d-f6e2-814b-7a1fdbf064db@kernel.org>
Date: Wed, 21 Jan 2026 11:19:44 -0700 (MST)
From: Paul Walmsley <pjw@...nel.org>
To: Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>
cc: Paul Walmsley <pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
Will Deacon <will@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
Boqun Feng <boqun.feng@...il.com>, Mark Rutland <mark.rutland@....com>,
Gary Guo <gary@...yguo.net>, Yury Norov <yury.norov@...il.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>, cfu@...ecomp.com,
torvalds@...ux-foundation.org, olof@...om.net,
aleksa.paunovic@...cgroup.com, arikalo@...il.com,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/2] Support for Risc-V CPUs implementing LR/SC but
not AMO
Hi Vladimir,
On Tue, 20 Jan 2026, Vladimir Kondratiev wrote:
> Primary goal is to support Mobileye eyeq7h automotive platform
> based on MIPS P8700 CPU [1] having only "zalrsc" ISA extension but
> not full "a".
>
> Such platforms need userspace to be compiled with correct
> "-march" flags to generate proper instructions for the atomic types
> so there's not feasible to use universal userspace for it.
> Thus there's no point to do same binary kernel suitable for both
> "full A" and "LRSC only" platform types. Do a compile time
> alternatives and require CONFIG_NONPORTABLE for this
>
> [1] https://mips.com/products/hardware/p8700/
>
> Patch 1 do most of work to provide compile-time LR/SC alternatives
> for the AMO instructions
> Patch 2 adjust tests for reported CPU extensions compatibility with
> the code
>
> Changes in v2: switch from dynamic atomic flavor resolution to
> compile-time one.
>
> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>
Thanks for updating the patches so quickly to deal with Gary's comments. I
think we should hold off on merging them until common userspace providers
(like Linux distributions) or distribution builders (like OE/Yocto or
Buildroot) merge support for this configuration, along with underlying
projects like glibc. That way, the rest of us have a way to test our
patches on this unusual configuration before sending them to the list, or
sending PRs upstream. It should be straightforward to get the Zalrsc-only
userspace support patches tested on existing RISC-V Linux hardware, since
it supports a superset of this behavior. I guess the only question is
whether other projects are interested in committing to carrying forward
the necessary changes.
It also would be good to see publicly available MIPS P8700 boards being
used on an ongoing basis by at least one active participant on this list,
who can post Tested-by:s for key series and who can post review feedback
and Reviewed-by:s for other RISC-V patch series. That way, we'd have more
confidence that there actually is an ongoing user population for this
board who cares about upstream. This is particularly important for folks
who care about these MIPS P8700 cores, which don't seem to be a
from-scratch design for RISC-V, and which don't have AMO support like all
of the other cores we support. (For what it's worth, we're trying to
foster this engagement for other core microarchitectures as well; thanks
Joel Stanley of TensTorrent, Andrew Jones and Anup Patel of
Ventana/Qualcomm, and Andreas Korb of Fraunhofer working on the Core-V
designs for showing how this is done.)
thanks,
- Paul
Powered by blists - more mailing lists