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

[Qingwei Hu]

> On May 31, 2026, at 07:09, Conor Dooley <conor@xxxxxxxxxx> wrote:
> 
> 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@xxxxxxxxxxx> 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.

Thanks, I will check this with the RISC-V unprivileged/ISA folks first,
and then handle the binding accordingly in v2.