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

[Vladimir Kondratiev <Vladimir.Kondratiev@mobileye.com>]

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.
For this SoC, we will compile user space with upfront knowledge of all
hardware features.

Thanks, Vladimir