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

[Conor Dooley <conor@kernel.org>]

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

On Wed, Jun 03, 2026 at 08:32:14PM +0800, Qingwei Hu wrote:
> 
> 
> > On May 31, 2026, at 07:09, Conor Dooley <conor@kernel.org> 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@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.
> 
> 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@gmail.com/

Probably you should coordinate with Guodong, as your zic64b effort seems
to predate theirs.

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