Re: [PATCH v3 2/2] riscv: accept the atomic extensions this kernel was built with

[Conor Dooley]

On Tue, Nov 03, 2026 at 04:31:21PM +0200, Vladimir Kondratiev wrote:
> On 11/2/26 20:21, Conor Dooley wrote:
> > On Mon, Oct 26, 2026 at 11:20:03AM +0200, Vladimir Kondratiev wrote:
> >> riscv_early_of_processor_hartid() rejects a hart unless its
> >> riscv,isa-extensions property contains "a". That rejects a Zalrsc-only
> >> hart even when the kernel was built to use only LR/SC.
> >>
> >> Require "a" or "zaamo" when the kernel emits AMO, and "a" or "zalrsc"
> >> when it emits LR/SC. A normal build defines both toolchain macros and
> >> still requires the full A extension. The legacy "riscv,isa" fallback
> >> keeps its rv{32,64}ima check.
> >>
> >> Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@xxxxxxxxxxxx
> >>
> > 
> > IMO, this should not be a separate patch.
> 
> I can squash it with previous patch.
> My thought was: it address different aspect. While previous patch allows
> compiling code that don't use AMO, this one is about correct
> manifestation of the extensions supported by CPU. One can use only
> previous patch and declare "a" support in the riscv,isa-extensions. Not
> exactly true but works. With this patch, one can say "zalrsc" instead of
> "a". This have no effect on how kernel get compiled but let user space
> know exact CPU features.

This has nothing to do with letting userspace know about cpu features
though, this code rejects CPUs during boot that do not meet the minimum
featureset of the kernel. Your previous patch relies on this, you can't
boot a zalrsc only kernel without making this change so I would say this
is intrinsically linked and should be part of the prior patch. Just
because it works if you lie about what your hardware can do, doesn't
justify splitting it...

Attachment: signature.asc
Description: PGP signature