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

[Qingwei Hu]

> On Jun 3, 2026, at 21:17, Conor Dooley <conor@xxxxxxxxxx> wrote:
> 
> On Wed, Jun 03, 2026 at 08:32:14PM +0800, Qingwei Hu wrote:
>> 
>> 
>>> 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.
> 
> I noticed that there's another series that's adding zic64b support:
> https://lore.kernel.org/all/20260603-rva23u64-hwprobe-v2-v3-0-5529a7b28384@xxxxxxxxx/
> 
> Probably you should coordinate with Guodong, as your zic64b effort seems
> to predate theirs.

Thanks Conor.

Yes, I noticed Guodong's series as well. I will coordinate with Guodong
before sending v2, and check whether this should be folded into that
work or kept as a small separate patch.

I will also clarify the intended Zic64b/Zicbo* relationship with the
RISC-V unprivileged/ISA folks before updating the binding.

Best regards,
Qingwei Hu