On Wed, Sep 02, 2026 at 07:24:16AM +0800, Jisheng Zhang wrote:
> > > other cap usage PoV: the cap can be used to replace various static
> > > branch usage in arch/riscv, for example the fast_unaligned_access_speed_key
> > > As is known, the static branch has some drawbacks.
> > > 
> > > So no matter which direction this series goes to, we need similar cap
> > > framework. The key question is whether we can extend the
> > > riscv_has_extension_*() to cover cpu/HW cap,
> > 
> > It'd be nice to see if we could reuse the functions, if we don't
> > want to invent a bunch of XLINUXFOO for them. The vendor extension stuff
> > that Charlie added reuses it, but since there's no Linux Foundation
> > JEDEC ID (AFAIK anyway) perhaps there's just no easy way to do it and
> > duplicating the functions with a different name is required.
> 
> what about if convert fast_unaligned_access_speed_key from static branch
> to alternative? It's a cpu HW capbility not extension. rename the
> riscv_has_extension_*() to riscv_has_cap_*()?


Is there any value in actually moving that one to an alternative? I
think it currently only has one user?

If there is value, I'd rather see __riscv_has_extension_*() get renamed
to __riscv_has_cap*(), so that things like unaligned access speed get a
different namespace to standard and vendor extensions. IOW you'd end up
with

static __always_inline bool riscv_has_extension_unlikely(const unsigned long ext)
{
	compiletime_assert(ext < RISCV_ISA_EXT_MAX, "ext must be < RISCV_ISA_EXT_MAX");

	return __riscv_has_cap_unlikely(STANDARD_EXT, ext);
}

static __always_inline bool riscv_has_vendor_extension_unlikely(const unsigned long vendor,
								const unsigned long ext)
{
	if (!IS_ENABLED(CONFIG_RISCV_ISA_VENDOR_EXT))
		return false;

	return __riscv_has_cap_unlikely(vendor, ext + RISCV_VENDOR_EXT_ALTERNATIVES_BASE);
}

static __always_inline bool riscv_has_cap_unlikely(const unsigned long cap)
{
	return __riscv_has_cap_unlikely(LINUX_CAP, cap);
}

Currently standard extensions use 0 as the vendor, perhaps we could then
use -1 (the value is an unsigned long) for non extension related caps?