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

From: Conor Dooley

Date: Wed Nov 04 2026 - 20:50:13 EST


On Wed, Nov 04, 2026 at 01:23:52PM +0200, Vladimir Kondratiev wrote:
> On 11/3/26 23:41, Conor Dooley wrote:
> > That got me thinking though, I feel like this breaks some of the
> > extension parsing logic in other ways.
> >
> > If you putting zalrsc and zaamo in your devicetree, we never do any
> > backwards processing to set the a extension (we don't do this for any
> > extensions by design, we only populate "child" extensions based on their
> > "parent"). If there's some userspace thing that expects to see a in
> > cpufeature or w/e it'd break. There shouldn't be since a has always been
> > supported but who knows. You need custom userspace anyway so I honestly
> > don't give that much of a shit about this going wrong.
> >
> > What does "worry" me is hwprobe. Currently you've not modified hwprobe
> > at all to correctly state that you do not support
> > RISCV_HWPROBE_BASE_BEHAVIOR_IMA. (and brings up the question of whether
> > you support RISCV_HWPROBE_BASE_BEHAVIOR_IMA_FD etc!)
> >
> > Maybe, again you don't care cos of your custom userspace, but this needs
> > to be holistic if it is being done at all.
> > Personally, I don't want to lower the minimum requirements - the people
> > designing this stuff to run linux should have checked to see what our
> > requirements were (and have always been...).
>
> I will drop this patch and keep advertising "a" because formally it is
> true - all "a" including amo instructions do work but rather slow. Also,
> not worth to complicate logic here for (so far) one very special SoC.

By that logic, do not complicate the kernel at all with this zalrsc-only
stuff and drop patch 1 too. Please do this properly or do not do it at
all. If we are introducing the ability to configure the kernel so that
it runs on systems with only zalrsc, people should be able to run the
kernel on such systems without a) failing to boot or b) incorrectly
reporting to userspace what the hardware is capable of doing.

> For this SoC, we will compile user space with upfront knowledge of all
> hardware features.


Attachment: signature.asc
Description: PGP signature