Re: [PATCH v1] riscv: cpufeature: Add Zic64b ISA extension support

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

On Sat, May 30, 2026 at 11:36:11AM +0800, Qingwei Hu wrote:
> Hi Vivian,
> 
> Thanks for the feedback.
> 
> > On May 29, 2026, at 11:14, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> > 
> > On 5/28/26 22:16, Qingwei Hu wrote:
> >> Zic64b describes a platform with 64-byte cache block sizes. It is a
> >> mandatory part of RVA23U64, but a system may provide 64-byte CMO block
> >> sizes without satisfying all profile requirements.
> >> 
> >> The ISA string parser currently ignores Zic64b because the extension is
> >> not present in the cpufeature table. Add an ISA extension ID and table
> >> entry for Zic64b so it can be reported in /proc/cpuinfo when firmware
> >> advertises it.
> > 
> > I'd like to understand: What is the motivation to doing this, given that
> > the very same information is already available as riscv,cbo*-block-size
> > and hwprobe?
> 
> The motivation here is not to replace riscv,cbo*-block-size or hwprobe.
> Those are still the right interfaces for software that needs the actual
> CBO block size.
> 
> This is more about preserving the ISA extension name reported by
> firmware. Some platforms report zic64b in the ISA string, but Linux
> currently drops it because there is no cpufeature entry, so cpuinfo no
> longer matches what firmware advertised. That makes profile/ISA-string
> comparison tools a bit awkward.
> 
> So the patch only makes zic64b visible as a named ISA extension when
> firmware reports it, while still validating it against any CBO block
> sizes that firmware provides.
> 
> > If an extension is what we want to go with, then
> > Documentation/devicetree/bindings/riscv/extensions.yaml also needs
> > updating to match.
> 
> And yes, if we keep this direction, I agree extensions.yaml should be
> updated in v2.

And make sure that having zic64b makes the cbo*-block-size properties
mandatory so that people don't confuse themselves and omit them and
wonder why stuff doesn't work.

Does zic64b mean that all of the zicbo* extensions are supported, or
does it just mean that the supported ones use 64-byte block sizes?
The answer to that will impact how you make the cbo*-block-size
properties mandatory.

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]