Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Jisheng Zhang <jszhang@kernel.org>
Cc: Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] riscv: introduce cap framework and use it to optimize pgtable_l4|l5_enabled
Date: Fri, 4 Sep 2026 21:49:38 +0100	[thread overview]
Message-ID: <20260904-semantic-quiet-24fff0973cc2@spud> (raw)
In-Reply-To: <apdeoLGpeBW0Hq4y@xhacker>


[-- Attachment #1.1: Type: text/plain, Size: 2187 bytes --]

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?


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

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

      reply	other threads:[~2026-09-04 20:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-30 17:03 [PATCH 0/3] optimize pgtable_l4|l5_enabled Jisheng Zhang
2026-08-30 17:03 ` [PATCH 1/3] riscv: remove RISCV_ALTERNATIVE Kconfig option Jisheng Zhang
2026-08-31 22:06   ` Conor Dooley
2026-08-30 17:04 ` [PATCH 2/3] riscv: convert pgtable_l4|l5_enabled to inline function Jisheng Zhang
2026-08-30 17:04 ` [PATCH 3/3] riscv: introduce cap framework and use it to optimize pgtable_l4|l5_enabled Jisheng Zhang
2026-08-31 22:04   ` Conor Dooley
2026-09-01  0:21     ` Jisheng Zhang
2026-09-01  4:55       ` Jisheng Zhang
2026-09-01  9:55         ` Conor Dooley
2026-09-01 23:24           ` Jisheng Zhang
2026-09-04 20:49             ` Conor Dooley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260904-semantic-quiet-24fff0973cc2@spud \
    --to=conor@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=jszhang@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox