* Re: [PATCH v5 1/4] PCI/DOE: Move common definitions to the header file
From: Frank Li @ 2026-06-11 20:36 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260610100256.1889111-2-a-garg7@ti.com>
On Wed, Jun 10, 2026 at 03:32:53PM +0530, Aksh Garg wrote:
> Move common macros and structures from drivers/pci/doe.c to
> drivers/pci/pci.h to allow reuse across root complex and
> endpoint DOE implementations.
>
> PCI_DOE_MAX_LENGTH macro can be used outside the PCI core as well,
> hence move the macro to include/linux/pci-doe.h.
>
> These changes prepare the groundwork for the DOE endpoint implementation
> that will reuse these common definitions.
>
> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> Changes from v4 to v5:
> - None.
>
> Changes from v3 to v4:
> - None.
>
> Changes from v2 to v3:
> - Rebased on 7.1-rc1.
>
> Changes since v1:
> - Moved the common macros that need not be visible outside the PCI core
> to drivers/pci/pci.h instead to include/linux/pci-doe.h as suggested
> by Lukas Wunner
> - Removed the redundant empty inlines guarded with CONFIG_PCI_DOE in
> include/linux/pci-doe.h.
>
> v4: https://lore.kernel.org/all/20260522052434.802034-2-a-garg7@ti.com/
> v3: https://lore.kernel.org/all/20260427051725.223704-2-a-garg7@ti.com/
> v2: https://lore.kernel.org/all/20260401073022.215805-2-a-garg7@ti.com/
> v1: https://lore.kernel.org/all/20260213123603.420941-3-a-garg7@ti.com/
>
> drivers/pci/doe.c | 11 -----------
> drivers/pci/pci.h | 9 +++++++++
> include/linux/pci-doe.h | 3 +++
> 3 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c
> index 7b41da4ec11a..e8d9e95644b3 100644
> --- a/drivers/pci/doe.c
> +++ b/drivers/pci/doe.c
> @@ -28,12 +28,6 @@
> #define PCI_DOE_TIMEOUT HZ
> #define PCI_DOE_POLL_INTERVAL (PCI_DOE_TIMEOUT / 128)
>
> -#define PCI_DOE_FLAG_CANCEL 0
> -#define PCI_DOE_FLAG_DEAD 1
> -
> -/* Max data object length is 2^18 dwords */
> -#define PCI_DOE_MAX_LENGTH (1 << 18)
> -
> /**
> * struct pci_doe_mb - State for a single DOE mailbox
> *
> @@ -63,11 +57,6 @@ struct pci_doe_mb {
> #endif
> };
>
> -struct pci_doe_feature {
> - u16 vid;
> - u8 type;
> -};
> -
> /**
> * struct pci_doe_task - represents a single query/response
> *
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 4a14f88e543a..5844deee2b5f 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -683,6 +683,15 @@ struct pci_sriov {
> bool drivers_autoprobe; /* Auto probing of VFs by driver */
> };
>
> +/* DOE Mailbox state flags */
> +#define PCI_DOE_FLAG_CANCEL 0
> +#define PCI_DOE_FLAG_DEAD 1
> +
> +struct pci_doe_feature {
> + u16 vid;
> + u8 type;
> +};
> +
> #ifdef CONFIG_PCI_DOE
> void pci_doe_init(struct pci_dev *pdev);
> void pci_doe_destroy(struct pci_dev *pdev);
> diff --git a/include/linux/pci-doe.h b/include/linux/pci-doe.h
> index bd4346a7c4e7..abb9b7ae8029 100644
> --- a/include/linux/pci-doe.h
> +++ b/include/linux/pci-doe.h
> @@ -19,6 +19,9 @@ struct pci_doe_mb;
> #define PCI_DOE_FEATURE_CMA 1
> #define PCI_DOE_FEATURE_SSESSION 2
>
> +/* Max data object length is 2^18 dwords */
> +#define PCI_DOE_MAX_LENGTH (1 << 18)
> +
> struct pci_doe_mb *pci_find_doe_mailbox(struct pci_dev *pdev, u16 vendor,
> u8 type);
>
> --
> 2.34.1
>
^ permalink raw reply
* [syzbot ci] Re: mm: split the file's i_mmap tree for NUMA
From: syzbot ci @ 2026-06-11 20:24 UTC (permalink / raw)
To: acme, adrian.hunter, akpm, alexander.shishkin, baohua,
baolin.wang, brauner, brian.ruley, corbet, dave.anglin, david,
deller, dev.jain, dinguyen, djbw, fangbaoshun, harry, huangsj,
irogers, jack, james.bottomley, james.clark, jannh, jolsa,
lance.yang, liam, linmiaohe, linux-arm-kernel, linux-doc,
linux-fsdevel, linux-kernel, linux-mm, linux-parisc,
linux-perf-users, linux-trace-kernel, linux, ljs, mark.rutland,
mhiramat, mhocko, mingo, mjguzik, muchun.song, namhyung,
nao.horiguchi, npache, nvdimm, oleg, osalvador, peterz
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260611061915.2354307-1-huangsj@hygon.cn>
syzbot ci has tested the following series
[v2] mm: split the file's i_mmap tree for NUMA
https://lore.kernel.org/all/20260611061915.2354307-1-huangsj@hygon.cn
* [PATCH v2 1/4] mm: use mapping_mapped to simplify the code
* [PATCH v2 2/4] mm: use get_i_mmap_root to access the file's i_mmap
* [PATCH v2 3/4] mm/fs: split the file's i_mmap tree
* [PATCH v2 4/4] docs/mm: update document for split i_mmap tree
and found the following issue:
INFO: trying to register non-static key in do_one_initcall
Full report is available here:
https://ci.syzbot.org/series/a9bada61-06e7-40d5-b423-5f2d69a60209
***
INFO: trying to register non-static key in do_one_initcall
tree: linux-next
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
base: 14546c7bef6c1036fc82e36c1a200b0caccd339a
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/2f92f704-660a-4108-9172-7e620e10ce46/config
acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug LTR]
acpi PNP0A08:00: _OSC: OS now controls [PME AER PCIeCapability]
PCI host bridge to bus 0000:00
pci_bus 0000:00: Unknown NUMA node; performance will be reduced
pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
pci_bus 0000:00: root bus resource [mem 0x80000000-0xafffffff window]
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
pci_bus 0000:00: root bus resource [mem 0x240000000-0xa3fffffff window]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000 conventional PCI endpoint
pci 0000:00:01.0: [1234:1111] type 00 class 0x030000 conventional PCI endpoint
pci 0000:00:01.0: BAR 0 [mem 0xfd000000-0xfdffffff pref]
pci 0000:00:01.0: BAR 2 [mem 0xfebf0000-0xfebf0fff]
pci 0000:00:01.0: ROM [mem 0xfebe0000-0xfebeffff pref]
pci 0000:00:01.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
pci 0000:00:02.0: [1af4:1005] type 00 class 0x00ff00 conventional PCI endpoint
pci 0000:00:02.0: BAR 0 [io 0xc080-0xc09f]
pci 0000:00:02.0: BAR 1 [mem 0xfebf1000-0xfebf1fff]
pci 0000:00:02.0: BAR 4 [mem 0xfe000000-0xfe003fff 64bit pref]
pci 0000:00:03.0: [8086:100e] type 00 class 0x020000 conventional PCI endpoint
pci 0000:00:03.0: BAR 0 [mem 0xfebc0000-0xfebdffff]
pci 0000:00:03.0: BAR 1 [io 0xc000-0xc03f]
pci 0000:00:03.0: ROM [mem 0xfeb80000-0xfebbffff pref]
pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100 conventional PCI endpoint
pci 0000:00:1f.0: quirk: [io 0x0600-0x067f] claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.2: [8086:2922] type 00 class 0x010601 conventional PCI endpoint
pci 0000:00:1f.2: BAR 4 [io 0xc0a0-0xc0bf]
pci 0000:00:1f.2: BAR 5 [mem 0xfebf2000-0xfebf2fff]
pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500 conventional PCI endpoint
pci 0000:00:1f.3: BAR 4 [io 0x0700-0x073f]
ACPI: PCI: Interrupt link LNKA configured for IRQ 10
ACPI: PCI: Interrupt link LNKB configured for IRQ 10
ACPI: PCI: Interrupt link LNKC configured for IRQ 11
ACPI: PCI: Interrupt link LNKD configured for IRQ 11
ACPI: PCI: Interrupt link LNKE configured for IRQ 10
ACPI: PCI: Interrupt link LNKF configured for IRQ 10
ACPI: PCI: Interrupt link LNKG configured for IRQ 11
ACPI: PCI: Interrupt link LNKH configured for IRQ 11
ACPI: PCI: Interrupt link GSIA configured for IRQ 16
ACPI: PCI: Interrupt link GSIB configured for IRQ 17
ACPI: PCI: Interrupt link GSIC configured for IRQ 18
ACPI: PCI: Interrupt link GSID configured for IRQ 19
ACPI: PCI: Interrupt link GSIE configured for IRQ 20
ACPI: PCI: Interrupt link GSIF configured for IRQ 21
ACPI: PCI: Interrupt link GSIG configured for IRQ 22
ACPI: PCI: Interrupt link GSIH configured for IRQ 23
iommu: Default domain type: Translated
iommu: DMA domain TLB invalidation policy: lazy mode
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150
assign_lock_key+0x133/0x150
register_lock_class+0xcc/0x2e0
__lock_acquire+0xad/0x2cf0
lock_acquire+0x106/0x350
down_write+0x96/0x200
dma_resv_lockdep+0x39c/0x660
do_one_initcall+0x250/0x870
do_initcall_level+0x104/0x190
do_initcalls+0x59/0xa0
kernel_init_freeable+0x2a6/0x3e0
kernel_init+0x1d/0x1d0
ret_from_fork+0x514/0xb70
ret_from_fork_asm+0x1a/0x30
</TASK>
------------[ cut here ]------------
DEBUG_RWSEMS_WARN_ON(sem->magic != sem): count = 0x1, magic = 0x0, owner = 0xffff888102a95940, curr 0xffff888102a95940, list not empty
WARNING: kernel/locking/rwsem.c:1405 at up_write+0x1e2/0x410, CPU#0: swapper/0/1
Modules linked in:
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:up_write+0x2b1/0x410
Code: c0 c0 e6 cc 8b 49 c7 c2 a0 e6 cc 8b 4c 0f 44 d0 48 8b 7c 24 10 48 c7 c6 40 e8 cc 8b 48 8b 54 24 08 48 8b 0c 24 4d 89 f9 41 52 <67> 48 0f b9 3a 48 83 c4 08 e8 21 1f 0d 03 e9 b2 fd ff ff 90 0f 0b
RSP: 0000:ffffc90000067480 EFLAGS: 00010246
RAX: ffffffff8bcce6c0 RBX: ffffc900000677d0 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffffffff8bcce840 RDI: ffffffff90338290
RBP: ffffc90000067830 R08: ffff888102a95940 R09: ffff888102a95940
R10: ffffffff8bcce6c0 R11: fffff5200000cefc R12: ffffc90000067828
R13: dffffc0000000000 R14: 1ffff9200000cf06 R15: ffff888102a95940
FS: 0000000000000000(0000) GS:ffff88818dc9e000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff88823ffff000 CR3: 000000000e74a000 CR4: 00000000000006f0
Call Trace:
<TASK>
dma_resv_lockdep+0x3a4/0x660
do_one_initcall+0x250/0x870
do_initcall_level+0x104/0x190
do_initcalls+0x59/0xa0
kernel_init_freeable+0x2a6/0x3e0
kernel_init+0x1d/0x1d0
ret_from_fork+0x514/0xb70
ret_from_fork_asm+0x1a/0x30
</TASK>
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* [PATCH v4 16/16] riscv: hwprobe: Introduce rva23u64 base behavior
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
Provide a hwprobe base-behavior bit so userspace can check RVA23U64
support in one call. Without it, a consumer needs five hwprobe
calls and four prctl calls, which is error-prone to require of every
caller. Most software treats RVA23U64 as a new base anyway, so
expose it directly.
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: No change.
v3: No change.
v2:
- Detect RVA23U64 by reading from the cached hart_isa[].isa_bases
bitmap populated by riscv_init_isa_bases() at init time, sharing
one source of truth with /proc/cpuinfo.
---
Documentation/arch/riscv/hwprobe.rst | 8 ++++++++
arch/riscv/include/uapi/asm/hwprobe.h | 3 ++-
arch/riscv/kernel/sys_hwprobe.c | 23 +++++++++++++++-------
tools/testing/selftests/riscv/hwprobe/which-cpus.c | 2 +-
4 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index 32a14331eb9de..dc70470093b1b 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -67,6 +67,14 @@ The following keys are defined:
programs (it may still be executed in userspace via a
kernel-controlled mechanism such as the vDSO).
+ * :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_RVA23U64`: Support for all mandatory
+ extensions of RVA23U64, as defined in the RISC-V Profiles specification
+ starting from commit 0273f3c921b6 ("rva23/rvb23 ratified").
+
+ The RVA23U64 base is based upon the IMA base and therefore IMA extension
+ keys (e.g. :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_0`:) may be used to probe
+ optional extensions.
+
* :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_0`: A bitmask containing extensions
that are compatible with the :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`:
base system behavior.
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 36ec8ab470423..50733d3db7633 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -21,7 +21,8 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_KEY_MARCHID 1
#define RISCV_HWPROBE_KEY_MIMPID 2
#define RISCV_HWPROBE_KEY_BASE_BEHAVIOR 3
-#define RISCV_HWPROBE_BASE_BEHAVIOR_IMA (1 << 0)
+#define RISCV_HWPROBE_BASE_BEHAVIOR_IMA (1 << 0)
+#define RISCV_HWPROBE_BASE_BEHAVIOR_RVA23U64 (1 << 1)
#define RISCV_HWPROBE_KEY_IMA_EXT_0 4
#define RISCV_HWPROBE_IMA_FD (1 << 0)
#define RISCV_HWPROBE_IMA_C (1 << 1)
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index 3e80e5551ae0d..3f66f2e99d41a 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -226,6 +226,17 @@ static bool hwprobe_ext0_has(const struct cpumask *cpus, u64 ext)
return (pair.value & ext);
}
+static bool hwprobe_has_isa_base(const struct cpumask *cpus, unsigned int base)
+{
+ int cpu;
+
+ for_each_cpu(cpu, cpus) {
+ if (!test_bit(base, hart_isa[cpu].isa_bases))
+ return false;
+ }
+ return true;
+}
+
#if defined(CONFIG_RISCV_PROBE_UNALIGNED_ACCESS)
static u64 hwprobe_misaligned(const struct cpumask *cpus)
{
@@ -308,14 +319,12 @@ static void hwprobe_one_pair(struct riscv_hwprobe *pair,
case RISCV_HWPROBE_KEY_MIMPID:
hwprobe_arch_id(pair, cpus);
break;
- /*
- * The kernel already assumes that the base single-letter ISA
- * extensions are supported on all harts, and only supports the
- * IMA base, so just cheat a bit here and tell that to
- * userspace.
- */
case RISCV_HWPROBE_KEY_BASE_BEHAVIOR:
- pair->value = RISCV_HWPROBE_BASE_BEHAVIOR_IMA;
+ pair->value = 0;
+ if (hwprobe_has_isa_base(cpus, RISCV_ISA_BASE_IMA))
+ pair->value |= RISCV_HWPROBE_BASE_BEHAVIOR_IMA;
+ if (hwprobe_has_isa_base(cpus, RISCV_ISA_BASE_RVA23U64))
+ pair->value |= RISCV_HWPROBE_BASE_BEHAVIOR_RVA23U64;
break;
case RISCV_HWPROBE_KEY_IMA_EXT_0:
diff --git a/tools/testing/selftests/riscv/hwprobe/which-cpus.c b/tools/testing/selftests/riscv/hwprobe/which-cpus.c
index 587feb198c049..f8c797b1d0fd9 100644
--- a/tools/testing/selftests/riscv/hwprobe/which-cpus.c
+++ b/tools/testing/selftests/riscv/hwprobe/which-cpus.c
@@ -105,7 +105,7 @@ int main(int argc, char **argv)
pairs[0] = (struct riscv_hwprobe){ .key = RISCV_HWPROBE_KEY_BASE_BEHAVIOR, };
rc = riscv_hwprobe(pairs, 1, 0, NULL, 0);
assert(rc == 0 && pairs[0].key == RISCV_HWPROBE_KEY_BASE_BEHAVIOR &&
- pairs[0].value == RISCV_HWPROBE_BASE_BEHAVIOR_IMA);
+ (pairs[0].value & RISCV_HWPROBE_BASE_BEHAVIOR_IMA));
pairs[0] = (struct riscv_hwprobe){ .key = RISCV_HWPROBE_KEY_IMA_EXT_0, };
rc = riscv_hwprobe(pairs, 1, 0, NULL, 0);
--
2.43.0
^ permalink raw reply related
* [PATCH v4 15/16] riscv: cpu: Output isa bases lines in cpuinfo
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
Output two new lines per processor in /proc/cpuinfo:
isa bases : <bases that all harts conform to>
hart isa bases : <bases that this specific hart conforms to>
These read directly from the cached riscv_isa_bases and
hart_isa[cpu].isa_bases bitmaps populated at boot by
riscv_init_isa_bases().
Example output on qemu booted with -cpu rva23s64,sv39=on,pmp=on
(showing only the new lines plus their neighbors for context):
processor : 0
hart : 4
isa bases : rv64ima rva23u64
isa : rv64imafdcbvh_zicbom_zicbop_...
mmu : sv39
...
mimpid : 0x0
hart isa bases : rv64ima rva23u64
hart isa : rv64imafdcbvh_zicbom_zicbop_...
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: No change.
v3: No change.
v2:
- Read from the cached riscv_isa_bases and hart_isa[cpu_id].isa_bases
bitmaps populated by riscv_init_isa_bases() at init time.
---
arch/riscv/kernel/cpu.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index 3dbc8cc557dd1..31e2857dcdcf1 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -305,6 +305,26 @@ static void print_mmu(struct seq_file *f)
seq_printf(f, "mmu\t\t: %s\n", sv_type);
}
+static const char * const riscv_isa_base_names[] = {
+#ifdef CONFIG_32BIT
+ [RISCV_ISA_BASE_IMA] = "rv32ima",
+#else
+ [RISCV_ISA_BASE_IMA] = "rv64ima",
+#endif
+ [RISCV_ISA_BASE_RVA23U64] = "rva23u64",
+};
+
+static void print_isa_bases(struct seq_file *m, const unsigned long *isa_bases)
+{
+ unsigned int i;
+
+ for (i = 0; i < RISCV_NR_ISA_BASES; i++) {
+ if (test_bit(i, isa_bases))
+ seq_printf(m, " %s", riscv_isa_base_names[i]);
+ }
+ seq_puts(m, "\n");
+}
+
static void *c_start(struct seq_file *m, loff_t *pos)
{
if (*pos == nr_cpu_ids)
@@ -336,6 +356,9 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "processor\t: %lu\n", cpu_id);
seq_printf(m, "hart\t\t: %lu\n", cpuid_to_hartid_map(cpu_id));
+ seq_puts(m, "isa bases\t:");
+ print_isa_bases(m, riscv_isa_bases);
+
/*
* For historical raisins, the isa: line is limited to the lowest common
* denominator of extensions supported across all harts. A true list of
@@ -360,6 +383,9 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "marchid\t\t: 0x%lx\n", ci->marchid);
seq_printf(m, "mimpid\t\t: 0x%lx\n", ci->mimpid);
+ seq_puts(m, "hart isa bases\t:");
+ print_isa_bases(m, hart_isa[cpu_id].isa_bases);
+
/*
* Print the ISA extensions specific to this hart, which may show
* additional extensions not present across all harts.
--
2.43.0
^ permalink raw reply related
* [PATCH v4 14/16] riscv: cpufeature: Introduce ISA bases bitmap and rva23u64 detection
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
Introduce a per-hart and host-wide bitmap of conformant ISA "bases"
(named profile-class sets such as IMA and RVA23U64), computed at init
time by riscv_init_isa_bases().
Register riscv_init_isa_bases() as a subsys_initcall so it executes
after core_initcall(tagged_addr_init), which probes senvcfg.PMM and
populates have_user_pmlen_*. Without that ordering,
riscv_have_user_pmlen(7) would still return its default false and the
RVA23U64 detection path would always bail.
Consider this as the cache that subsequent consumers (hwprobe's
RVA23U64 base behavior bit, /proc/cpuinfo's "isa bases" lines, etc.)
can read without recomputing. System-wide consistency are ensured.
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4:
- In riscv_set_isa_base(), reorder those __setbit(RISCV_ISA_EXT_X,m)
lines to make them conform to the order they appear in the RVA23 1.0
Profile.
v3:
- Add a blank line before the subsys_initcall() registration (Andrew).
- Set the local ext_mask with __set_bit() and test the mandate set with
!bitmap_subset() (Sashiko).
- Require the Zic64b ISA extension in the RVA23U64 mask,
instead of open-coded cache block-size check. (New, thoughts from Andrew)
v2:
- Implement riscv_init_isa_bases() that runs at system init time,
after tagged_addr_init() populates have_user_pmlen_*.
- Split RVA23S64 placeholder into a future patch.
---
arch/riscv/include/asm/cpufeature.h | 14 ++++++
arch/riscv/kernel/cpufeature.c | 90 +++++++++++++++++++++++++++++++++++++
2 files changed, 104 insertions(+)
diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
index 739fcc84bf7b2..facc31b2960c6 100644
--- a/arch/riscv/include/asm/cpufeature.h
+++ b/arch/riscv/include/asm/cpufeature.h
@@ -25,10 +25,24 @@ struct riscv_cpuinfo {
unsigned long mimpid;
};
+enum {
+ RISCV_ISA_BASE_IMA,
+ RISCV_ISA_BASE_RVA23U64,
+ RISCV_NR_ISA_BASES,
+};
+
+/**
+ * struct riscv_isainfo - per-hart ISA state
+ * @isa: bitmap of ISA extensions this hart implements
+ * @isa_bases: bitmap of profile bases this hart conforms to
+ */
struct riscv_isainfo {
DECLARE_BITMAP(isa, RISCV_ISA_EXT_MAX);
+ DECLARE_BITMAP(isa_bases, RISCV_NR_ISA_BASES);
};
+extern unsigned long riscv_isa_bases[BITS_TO_LONGS(RISCV_NR_ISA_BASES)];
+
DECLARE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
extern const struct seq_operations cpuinfo_op;
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 29dff41313e65..f398e522a71d2 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -41,6 +41,9 @@ unsigned long elf_hwcap __read_mostly;
/* Host ISA bitmap */
static DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX) __read_mostly;
+/* Host ISA bases bitmap */
+DECLARE_BITMAP(riscv_isa_bases, RISCV_NR_ISA_BASES) __read_mostly;
+
/* Per-cpu ISA extensions. */
struct riscv_isainfo hart_isa[NR_CPUS];
@@ -1322,3 +1325,90 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin,
}
}
#endif
+
+/*
+ * Compute the set of profile bases (IMA, RVA23U64, ...) a hart
+ * conforms to, given its resolved ISA bitmap.
+ *
+ * If @isa_bitmap is NULL, the host ISA bitmap (the AND across all harts) is
+ * used.
+ */
+static void riscv_set_isa_bases(unsigned long *bases, const unsigned long *isa_bitmap)
+{
+ const unsigned long *isa = isa_bitmap ? isa_bitmap : riscv_isa;
+ DECLARE_BITMAP(ext_mask, RISCV_ISA_EXT_MAX) = { 0 };
+
+ /* IMA */
+ __set_bit(RISCV_ISA_EXT_I, ext_mask);
+ __set_bit(RISCV_ISA_EXT_M, ext_mask);
+ __set_bit(RISCV_ISA_EXT_A, ext_mask);
+
+ if (!bitmap_subset(ext_mask, isa, RISCV_ISA_EXT_MAX))
+ return;
+
+ set_bit(RISCV_ISA_BASE_IMA, bases);
+
+ /* RVA23U64 */
+
+ /* Supm with PMLEN=7 */
+ if (!riscv_have_user_pmlen(7))
+ return;
+
+ __set_bit(RISCV_ISA_EXT_F, ext_mask);
+ __set_bit(RISCV_ISA_EXT_D, ext_mask);
+ __set_bit(RISCV_ISA_EXT_C, ext_mask);
+ __set_bit(RISCV_ISA_EXT_B, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZICSR, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZICNTR, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZIHPM, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZICCIF, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZICCRSE, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZICCAMOA, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZICCLSM, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZA64RS, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZIHINTPAUSE, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZIC64B, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZICBOM, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZICBOP, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZICBOZ, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZFHMIN, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZKT, ext_mask);
+ __set_bit(RISCV_ISA_EXT_V, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZVFHMIN, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZVBB, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZVKT, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZIHINTNTL, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZICOND, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZIMOP, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZCMOP, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZCB, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZFA, ext_mask);
+ __set_bit(RISCV_ISA_EXT_ZAWRS, ext_mask);
+ __set_bit(RISCV_ISA_EXT_SUPM, ext_mask);
+
+ if (!bitmap_subset(ext_mask, isa, RISCV_ISA_EXT_MAX))
+ return;
+
+ set_bit(RISCV_ISA_BASE_RVA23U64, bases);
+}
+
+/*
+ * Populate the host ISA bases bitmap (riscv_isa_bases) and each
+ * hart's per-cpu isa_bases.
+ */
+static int __init riscv_init_isa_bases(void)
+{
+ int cpu;
+
+ for_each_possible_cpu(cpu)
+ riscv_set_isa_bases(hart_isa[cpu].isa_bases, hart_isa[cpu].isa);
+
+ riscv_set_isa_bases(riscv_isa_bases, NULL);
+ return 0;
+}
+
+/*
+ * Registered as subsys_initcall so it runs after
+ * core_initcall(tagged_addr_init) populates have_user_pmlen_*.
+ */
+subsys_initcall(riscv_init_isa_bases);
--
2.43.0
^ permalink raw reply related
* [PATCH v4 13/16] riscv: Add a getter for user PMLEN support
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
From: Andrew Jones <andrew.jones@oss.qualcomm.com>
Querying whether a given user PMLEN is supported is needed for
RVA23U64 base detection from outside arch/riscv/kernel/process.c.
Add riscv_have_user_pmlen() to expose this.
Link: https://lore.kernel.org/linux-riscv/rfuwa7a3ebe76udmnwyrssjy7shkkgxntvhwzn6oquysj4tuyp@xzvpylcfhz53/
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
[Guodong: replace exported booleans with getter per Andrew's suggestion]
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: No change.
v3: No change.
v2: Add a getter for user PMLEN.
---
arch/riscv/include/asm/processor.h | 4 ++++
arch/riscv/kernel/process.c | 12 ++++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
index 812517b2cec13..febf51e127f70 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -214,6 +214,10 @@ long set_tagged_addr_ctrl(struct task_struct *task, unsigned long arg);
long get_tagged_addr_ctrl(struct task_struct *task);
#define SET_TAGGED_ADDR_CTRL(arg) set_tagged_addr_ctrl(current, arg)
#define GET_TAGGED_ADDR_CTRL() get_tagged_addr_ctrl(current)
+
+bool riscv_have_user_pmlen(u8 len);
+#else
+static inline bool riscv_have_user_pmlen(u8 len) { return false; }
#endif
#endif /* __ASSEMBLER__ */
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index b2df7f72241a5..5d9cb108a6232 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -302,6 +302,18 @@ enum {
static bool have_user_pmlen_7;
static bool have_user_pmlen_16;
+bool riscv_have_user_pmlen(u8 len)
+{
+ switch (len) {
+ case PMLEN_7:
+ return have_user_pmlen_7;
+ case PMLEN_16:
+ return have_user_pmlen_16;
+ default:
+ return false;
+ }
+}
+
/*
* Control the relaxed ABI allowing tagged user addresses into the kernel.
*/
--
2.43.0
^ permalink raw reply related
* [PATCH v4 12/16] riscv: dts: sophgo: sg2044: Add Zic64b ISA extension
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
The SG2044 cores have 64-byte cache blocks, described by their
cbom/cbop/cboz-block-size of 64, so they implement Zic64b. Declare it in
each core's riscv,isa-extensions.
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Acked-by: Inochi Amaoto <inochiama@gmail.com>
---
v4: Add Inochi Amaoto's Acked-by.
v3: New patch.
---
arch/riscv/boot/dts/sophgo/sg2044-cpus.dtsi | 128 ++++++++++++++--------------
1 file changed, 64 insertions(+), 64 deletions(-)
diff --git a/arch/riscv/boot/dts/sophgo/sg2044-cpus.dtsi b/arch/riscv/boot/dts/sophgo/sg2044-cpus.dtsi
index 3135409c21492..2ac4a41bbc3a7 100644
--- a/arch/riscv/boot/dts/sophgo/sg2044-cpus.dtsi
+++ b/arch/riscv/boot/dts/sophgo/sg2044-cpus.dtsi
@@ -31,7 +31,7 @@ cpu0: cpu@0 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -67,7 +67,7 @@ cpu1: cpu@1 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -103,7 +103,7 @@ cpu2: cpu@2 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -139,7 +139,7 @@ cpu3: cpu@3 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -175,7 +175,7 @@ cpu4: cpu@4 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -211,7 +211,7 @@ cpu5: cpu@5 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -247,7 +247,7 @@ cpu6: cpu@6 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -283,7 +283,7 @@ cpu7: cpu@7 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -319,7 +319,7 @@ cpu8: cpu@8 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -355,7 +355,7 @@ cpu9: cpu@9 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -391,7 +391,7 @@ cpu10: cpu@10 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -427,7 +427,7 @@ cpu11: cpu@11 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -463,7 +463,7 @@ cpu12: cpu@12 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -499,7 +499,7 @@ cpu13: cpu@13 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -535,7 +535,7 @@ cpu14: cpu@14 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -571,7 +571,7 @@ cpu15: cpu@15 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -607,7 +607,7 @@ cpu16: cpu@16 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -643,7 +643,7 @@ cpu17: cpu@17 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -679,7 +679,7 @@ cpu18: cpu@18 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -715,7 +715,7 @@ cpu19: cpu@19 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -751,7 +751,7 @@ cpu20: cpu@20 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -787,7 +787,7 @@ cpu21: cpu@21 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -823,7 +823,7 @@ cpu22: cpu@22 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -859,7 +859,7 @@ cpu23: cpu@23 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -895,7 +895,7 @@ cpu24: cpu@24 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -931,7 +931,7 @@ cpu25: cpu@25 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -967,7 +967,7 @@ cpu26: cpu@26 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1003,7 +1003,7 @@ cpu27: cpu@27 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1039,7 +1039,7 @@ cpu28: cpu@28 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1075,7 +1075,7 @@ cpu29: cpu@29 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1111,7 +1111,7 @@ cpu30: cpu@30 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1147,7 +1147,7 @@ cpu31: cpu@31 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1183,7 +1183,7 @@ cpu32: cpu@32 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1219,7 +1219,7 @@ cpu33: cpu@33 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1255,7 +1255,7 @@ cpu34: cpu@34 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1291,7 +1291,7 @@ cpu35: cpu@35 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1327,7 +1327,7 @@ cpu36: cpu@36 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1363,7 +1363,7 @@ cpu37: cpu@37 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1399,7 +1399,7 @@ cpu38: cpu@38 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1435,7 +1435,7 @@ cpu39: cpu@39 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1471,7 +1471,7 @@ cpu40: cpu@40 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1507,7 +1507,7 @@ cpu41: cpu@41 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1543,7 +1543,7 @@ cpu42: cpu@42 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1579,7 +1579,7 @@ cpu43: cpu@43 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1615,7 +1615,7 @@ cpu44: cpu@44 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1651,7 +1651,7 @@ cpu45: cpu@45 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1687,7 +1687,7 @@ cpu46: cpu@46 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1723,7 +1723,7 @@ cpu47: cpu@47 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1759,7 +1759,7 @@ cpu48: cpu@48 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1795,7 +1795,7 @@ cpu49: cpu@49 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1831,7 +1831,7 @@ cpu50: cpu@50 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1867,7 +1867,7 @@ cpu51: cpu@51 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1903,7 +1903,7 @@ cpu52: cpu@52 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1939,7 +1939,7 @@ cpu53: cpu@53 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -1975,7 +1975,7 @@ cpu54: cpu@54 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -2011,7 +2011,7 @@ cpu55: cpu@55 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -2047,7 +2047,7 @@ cpu56: cpu@56 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -2083,7 +2083,7 @@ cpu57: cpu@57 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -2119,7 +2119,7 @@ cpu58: cpu@58 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -2155,7 +2155,7 @@ cpu59: cpu@59 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -2191,7 +2191,7 @@ cpu60: cpu@60 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -2227,7 +2227,7 @@ cpu61: cpu@61 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -2263,7 +2263,7 @@ cpu62: cpu@62 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
@@ -2299,7 +2299,7 @@ cpu63: cpu@63 {
"svinval", "svnapot", "svpbmt",
"zawrs", "zba", "zbb", "zbc",
"zbs", "zca", "zcb", "zcd",
- "zfa", "zfbfmin", "zfh", "zfhmin",
+ "zfa", "zfbfmin", "zfh", "zfhmin", "zic64b",
"zicbom", "zicbop", "zicboz", "ziccrse",
"zicntr", "zicond","zicsr", "zifencei",
"zihintntl", "zihintpause", "zihpm",
--
2.43.0
^ permalink raw reply related
* [PATCH v4 11/16] riscv: dts: spacemit: k1: Add Zic64b ISA extension
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
The K1 X60 cores have 64-byte cache blocks, described by their
cbom/cbop/cboz-block-size of 64, so they implement Zic64b. Declare it in
each core's riscv,isa-extensions and in the deprecated riscv,isa string.
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: No change.
v3: New patch.
---
arch/riscv/boot/dts/spacemit/k1.dtsi | 80 ++++++++++++++++++------------------
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index f0bad6855c970..e6fc684ad3898 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -54,12 +54,12 @@ cpu_0: cpu@0 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <0>;
- riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+ riscv,isa = "rv64imafdcbv_zic64b_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
- riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
- "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
- "zifencei", "zihintpause", "zihpm", "zfh", "zba",
- "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zic64b",
+ "zicbom", "zicbop", "zicboz", "zicntr", "zicond",
+ "zicsr", "zifencei", "zihintpause", "zihpm", "zfh",
+ "zba", "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
"sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
riscv,cbom-block-size = <64>;
riscv,cbop-block-size = <64>;
@@ -84,12 +84,12 @@ cpu_1: cpu@1 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <1>;
- riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+ riscv,isa = "rv64imafdcbv_zic64b_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
- riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
- "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
- "zifencei", "zihintpause", "zihpm", "zfh", "zba",
- "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zic64b",
+ "zicbom", "zicbop", "zicboz", "zicntr", "zicond",
+ "zicsr", "zifencei", "zihintpause", "zihpm", "zfh",
+ "zba", "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
"sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
riscv,cbom-block-size = <64>;
riscv,cbop-block-size = <64>;
@@ -114,12 +114,12 @@ cpu_2: cpu@2 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <2>;
- riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+ riscv,isa = "rv64imafdcbv_zic64b_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
- riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
- "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
- "zifencei", "zihintpause", "zihpm", "zfh", "zba",
- "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zic64b",
+ "zicbom", "zicbop", "zicboz", "zicntr", "zicond",
+ "zicsr", "zifencei", "zihintpause", "zihpm", "zfh",
+ "zba", "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
"sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
riscv,cbom-block-size = <64>;
riscv,cbop-block-size = <64>;
@@ -144,12 +144,12 @@ cpu_3: cpu@3 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <3>;
- riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+ riscv,isa = "rv64imafdcbv_zic64b_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
- riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
- "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
- "zifencei", "zihintpause", "zihpm", "zfh", "zba",
- "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zic64b",
+ "zicbom", "zicbop", "zicboz", "zicntr", "zicond",
+ "zicsr", "zifencei", "zihintpause", "zihpm", "zfh",
+ "zba", "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
"sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
riscv,cbom-block-size = <64>;
riscv,cbop-block-size = <64>;
@@ -174,12 +174,12 @@ cpu_4: cpu@4 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <4>;
- riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+ riscv,isa = "rv64imafdcbv_zic64b_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
- riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
- "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
- "zifencei", "zihintpause", "zihpm", "zfh", "zba",
- "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zic64b",
+ "zicbom", "zicbop", "zicboz", "zicntr", "zicond",
+ "zicsr", "zifencei", "zihintpause", "zihpm", "zfh",
+ "zba", "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
"sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
riscv,cbom-block-size = <64>;
riscv,cbop-block-size = <64>;
@@ -204,12 +204,12 @@ cpu_5: cpu@5 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <5>;
- riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+ riscv,isa = "rv64imafdcbv_zic64b_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
- riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
- "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
- "zifencei", "zihintpause", "zihpm", "zfh", "zba",
- "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zic64b",
+ "zicbom", "zicbop", "zicboz", "zicntr", "zicond",
+ "zicsr", "zifencei", "zihintpause", "zihpm", "zfh",
+ "zba", "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
"sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
riscv,cbom-block-size = <64>;
riscv,cbop-block-size = <64>;
@@ -234,12 +234,12 @@ cpu_6: cpu@6 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <6>;
- riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+ riscv,isa = "rv64imafdcbv_zic64b_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
- riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
- "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
- "zifencei", "zihintpause", "zihpm", "zfh", "zba",
- "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zic64b",
+ "zicbom", "zicbop", "zicboz", "zicntr", "zicond",
+ "zicsr", "zifencei", "zihintpause", "zihpm", "zfh",
+ "zba", "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
"sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
riscv,cbom-block-size = <64>;
riscv,cbop-block-size = <64>;
@@ -264,12 +264,12 @@ cpu_7: cpu@7 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <7>;
- riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+ riscv,isa = "rv64imafdcbv_zic64b_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
- riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
- "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
- "zifencei", "zihintpause", "zihpm", "zfh", "zba",
- "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zic64b",
+ "zicbom", "zicbop", "zicboz", "zicntr", "zicond",
+ "zicsr", "zifencei", "zihintpause", "zihpm", "zfh",
+ "zba", "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
"sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
riscv,cbom-block-size = <64>;
riscv,cbop-block-size = <64>;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 10/16] riscv: dts: spacemit: k3: Add Zic64b ISA extension
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
The K3 X100 cores have 64-byte cache blocks, already described by their
cbom/cbop/cboz-block-size of 64, so they implement Zic64b, a mandatory
RVA23 extension. Declare it in each core's riscv,isa-extensions.
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: No change.
v3: New patch.
---
arch/riscv/boot/dts/spacemit/k3.dtsi | 48 ++++++++++++++++++------------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
index 4ac457399b583..b5aa983f0bfa1 100644
--- a/arch/riscv/boot/dts/spacemit/k3.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
@@ -35,9 +35,9 @@ cpu_0: cpu@0 {
"svinval", "svnapot", "svpbmt", "za64rs",
"zawrs", "zba", "zbb", "zbc", "zbs", "zca",
"zcb", "zcd", "zcmop", "zfa", "zfbfmin",
- "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
- "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
- "zicond", "zicsr", "zifencei", "zihintntl",
+ "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
+ "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
+ "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
"zihintpause", "zihpm", "zimop", "zkt", "zvbb",
"zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
"zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
@@ -76,9 +76,9 @@ cpu_1: cpu@1 {
"svinval", "svnapot", "svpbmt", "za64rs",
"zawrs", "zba", "zbb", "zbc", "zbs", "zca",
"zcb", "zcd", "zcmop", "zfa", "zfbfmin",
- "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
- "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
- "zicond", "zicsr", "zifencei", "zihintntl",
+ "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
+ "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
+ "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
"zihintpause", "zihpm", "zimop", "zkt", "zvbb",
"zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
"zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
@@ -117,9 +117,9 @@ cpu_2: cpu@2 {
"svinval", "svnapot", "svpbmt", "za64rs",
"zawrs", "zba", "zbb", "zbc", "zbs", "zca",
"zcb", "zcd", "zcmop", "zfa", "zfbfmin",
- "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
- "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
- "zicond", "zicsr", "zifencei", "zihintntl",
+ "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
+ "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
+ "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
"zihintpause", "zihpm", "zimop", "zkt", "zvbb",
"zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
"zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
@@ -158,9 +158,9 @@ cpu_3: cpu@3 {
"svinval", "svnapot", "svpbmt", "za64rs",
"zawrs", "zba", "zbb", "zbc", "zbs", "zca",
"zcb", "zcd", "zcmop", "zfa", "zfbfmin",
- "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
- "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
- "zicond", "zicsr", "zifencei", "zihintntl",
+ "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
+ "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
+ "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
"zihintpause", "zihpm", "zimop", "zkt", "zvbb",
"zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
"zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
@@ -199,9 +199,9 @@ cpu_4: cpu@4 {
"svinval", "svnapot", "svpbmt", "za64rs",
"zawrs", "zba", "zbb", "zbc", "zbs", "zca",
"zcb", "zcd", "zcmop", "zfa", "zfbfmin",
- "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
- "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
- "zicond", "zicsr", "zifencei", "zihintntl",
+ "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
+ "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
+ "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
"zihintpause", "zihpm", "zimop", "zkt", "zvbb",
"zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
"zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
@@ -240,9 +240,9 @@ cpu_5: cpu@5 {
"svinval", "svnapot", "svpbmt", "za64rs",
"zawrs", "zba", "zbb", "zbc", "zbs", "zca",
"zcb", "zcd", "zcmop", "zfa", "zfbfmin",
- "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
- "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
- "zicond", "zicsr", "zifencei", "zihintntl",
+ "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
+ "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
+ "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
"zihintpause", "zihpm", "zimop", "zkt", "zvbb",
"zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
"zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
@@ -281,9 +281,9 @@ cpu_6: cpu@6 {
"svinval", "svnapot", "svpbmt", "za64rs",
"zawrs", "zba", "zbb", "zbc", "zbs", "zca",
"zcb", "zcd", "zcmop", "zfa", "zfbfmin",
- "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
- "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
- "zicond", "zicsr", "zifencei", "zihintntl",
+ "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
+ "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
+ "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
"zihintpause", "zihpm", "zimop", "zkt", "zvbb",
"zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
"zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
@@ -322,9 +322,9 @@ cpu_7: cpu@7 {
"svinval", "svnapot", "svpbmt", "za64rs",
"zawrs", "zba", "zbb", "zbc", "zbs", "zca",
"zcb", "zcd", "zcmop", "zfa", "zfbfmin",
- "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
- "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
- "zicond", "zicsr", "zifencei", "zihintntl",
+ "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
+ "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
+ "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
"zihintpause", "zihpm", "zimop", "zkt", "zvbb",
"zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
"zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
--
2.43.0
^ permalink raw reply related
* [PATCH v4 09/16] riscv: Add Zic64b to cpufeature and hwprobe
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Qingwei Hu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
From: Qingwei Hu <qingwei.hu@bytedance.com>
Zic64b mandates 64-byte naturally aligned cache blocks and is a
mandatory extension of the RVA22 and RVA23 profiles. Allocate a
RISCV_ISA_EXT_ZIC64B id, parse "zic64b" from the ISA string with a
validate callback that requires each cbom/cbop/cboz cache block size to
be 64 bytes when it is present, and export it through hwprobe.
Link: https://lists.riscv.org/g/tech-unprivileged/topic/question_about_zic64b_and/119631059
Signed-off-by: Qingwei Hu <qingwei.hu@bytedance.com>
Co-developed-by: Guodong Xu <docular.xu@gmail.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4:
- Credit Qingwei Hu's earlier Zic64b cpufeature patch: set him as
author, with Co-developed-by (Guodong Xu).
- Validate only the cbom/cbop/cboz block sizes that are present; Zic64b
does not imply the CMO extensions (Conor, Qingwei, Greg).
- Add a Link: to Greg's confirmation on the tech-unprivileged list.
- Add the missing blank line before the ZIC64B hwprobe.rst entry
(Andrew).
- Did not carry Andrew Jones's v3 Reviewed-by: the validation was
rewritten (present block sizes only) and the patch is now authored by
Qingwei, so it warrants a fresh review.
v3: New patch.
---
Documentation/arch/riscv/hwprobe.rst | 4 ++++
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/include/uapi/asm/hwprobe.h | 1 +
arch/riscv/kernel/cpufeature.c | 19 +++++++++++++++++++
arch/riscv/kernel/sys_hwprobe.c | 1 +
5 files changed, 26 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index fc68dea397aae..32a14331eb9de 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -425,3 +425,7 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_B`: The B extension is supported, as defined
in version 1.0 of the Bit-Manipulation ISA extensions, and implies the
presence of the Zba, Zbb, and Zbs sub-extensions.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZIC64B`: The Zic64b extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 58523b3a1998a..36572c1ff438a 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -117,6 +117,7 @@
#define RISCV_ISA_EXT_ZICCAMOA 107
#define RISCV_ISA_EXT_ZICCIF 108
#define RISCV_ISA_EXT_ZA64RS 109
+#define RISCV_ISA_EXT_ZIC64B 110
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 430dc49a82863..36ec8ab470423 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -122,6 +122,7 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_EXT_ZICCRSE (1ULL << 4)
#define RISCV_HWPROBE_EXT_ZA64RS (1ULL << 5)
#define RISCV_HWPROBE_EXT_B (1ULL << 6)
+#define RISCV_HWPROBE_EXT_ZIC64B (1ULL << 7)
/* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index e0197160af6dd..29dff41313e65 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -154,6 +154,24 @@ static int riscv_ext_zicbop_validate(const struct riscv_isa_ext_data *data,
return 0;
}
+static int riscv_ext_zic64b_validate(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ /*
+ * Zic64b mandates 64-byte naturally aligned cache blocks; cross-check the
+ * cbom/cbop/cboz block-size (when declared) device-tree properties to
+ * avoid inconsistency.
+ */
+ if ((riscv_cbom_block_size && riscv_cbom_block_size != 64) ||
+ (riscv_cbop_block_size && riscv_cbop_block_size != 64) ||
+ (riscv_cboz_block_size && riscv_cboz_block_size != 64)) {
+ pr_err("Zic64b detected in ISA string, disabling as a CBO block size is not 64 bytes\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int riscv_ext_f_validate(const struct riscv_isa_ext_data *data,
const unsigned long *isa_bitmap)
{
@@ -524,6 +542,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_SUPERSET(b, RISCV_ISA_EXT_B, riscv_b_exts),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(v, RISCV_ISA_EXT_V, riscv_v_exts, riscv_ext_vector_float_validate),
__RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_H),
+ __RISCV_ISA_EXT_DATA_VALIDATE(zic64b, RISCV_ISA_EXT_ZIC64B, riscv_ext_zic64b_validate),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index dcc102bf8f183..3e80e5551ae0d 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -211,6 +211,7 @@ static void hwprobe_isa_ext1(struct riscv_hwprobe *pair,
EXT_KEY(isainfo->isa, ZICCRSE, pair->value, missing);
EXT_KEY(isainfo->isa, ZA64RS, pair->value, missing);
EXT_KEY(isainfo->isa, B, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZIC64B, pair->value, missing);
}
/* Now turn off reporting features if any CPU is missing it. */
--
2.43.0
^ permalink raw reply related
* [PATCH v4 08/16] dt-bindings: riscv: Add Zic64b extension description
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
Zic64b mandates that cache blocks are 64 bytes in size and naturally
aligned in the address space. It is a mandatory extension of both the
RVA22 (U64/S64) and RVA23 (U64/S64) profiles, ratified with RISC-V
Profiles Version 1.0.
Document it so it can be described in the riscv,isa-extensions property,
alongside the related Zicbom/Zicbop/Zicboz cache-block extensions. Since
Zic64b fixes the cache block size at 64 bytes, also add a schema check
requiring any present cbom/cbop/cboz block size to be 64.
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: Insert zic64b at its sorted position (before zicbom).
Update the commit message.
v3: New patch.
---
.../devicetree/bindings/riscv/extensions.yaml | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 5ffc40d599c02..1c24999beb59e 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -494,6 +494,12 @@ properties:
in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
riscv-isa-manual.
+ - const: zic64b
+ description:
+ The standard Zic64b extension for 64-byte naturally aligned cache
+ blocks, as ratified in RISC-V Profiles Version 1.0, with commit
+ b1d806605f87 ("Updated to ratified state.")
+
- const: zicbom
description:
The standard Zicbom extension for base cache management operations as
@@ -1142,6 +1148,20 @@ allOf:
not:
contains:
const: zilsd
+ # Zic64b mandates 64-byte naturally aligned cache blocks
+ - if:
+ properties:
+ riscv,isa-extensions:
+ contains:
+ const: zic64b
+ then:
+ properties:
+ riscv,cbom-block-size:
+ const: 64
+ riscv,cbop-block-size:
+ const: 64
+ riscv,cboz-block-size:
+ const: 64
additionalProperties: true
...
--
2.43.0
^ permalink raw reply related
* [PATCH v4 07/16] riscv: Add B to hwcap and hwprobe
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
From: Andrew Jones <andrew.jones@oss.qualcomm.com>
Add B to hwcap and ensure when B is present that Zba, Zbb, and Zbs
are all set. Also expose B via hwprobe (RISCV_HWPROBE_EXT_B in
RISCV_HWPROBE_KEY_IMA_EXT_1) so that userspace can probe B directly,
mirroring the F/D/C/V pattern where each is reported via both hwcap
and hwprobe.
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
[Add B to hwprobe]
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: No change.
v3:
- Indent the added hwprobe.rst entry to match the normalized style.
- Rebased onto v7.1-rc6: index isa2hwcap[] via RISCV_ISA_EXT_B to match the
macro-ization in commit 41337097f2823.
v2:
- Rebased to v7.1-rc2
- Add B to hwprobe (RISCV_HWPROBE_EXT_B at IMA_EXT_1 bit 6) and
document it in hwprobe.rst, so userspace can probe B directly.
---
Documentation/arch/riscv/hwprobe.rst | 4 ++++
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/include/uapi/asm/hwcap.h | 1 +
arch/riscv/include/uapi/asm/hwprobe.h | 1 +
arch/riscv/kernel/cpufeature.c | 8 ++++++++
arch/riscv/kernel/sys_hwprobe.c | 1 +
6 files changed, 16 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index 893e1a1215d23..fc68dea397aae 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -421,3 +421,7 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_ZA64RS`: The Za64rs extension is supported,
as defined in the RISC-V Profiles specification starting from commit
b1d80660 ("Updated to ratified state.")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_B`: The B extension is supported, as defined
+ in version 1.0 of the Bit-Manipulation ISA extensions, and implies the
+ presence of the Zba, Zbb, and Zbs sub-extensions.
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 0acb7a01ecc0f..58523b3a1998a 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -11,6 +11,7 @@
#include <uapi/asm/hwcap.h>
#define RISCV_ISA_EXT_A ('a' - 'a')
+#define RISCV_ISA_EXT_B ('b' - 'a')
#define RISCV_ISA_EXT_C ('c' - 'a')
#define RISCV_ISA_EXT_D ('d' - 'a')
#define RISCV_ISA_EXT_F ('f' - 'a')
diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h
index c52bb7bbbabe9..96b7cf854e090 100644
--- a/arch/riscv/include/uapi/asm/hwcap.h
+++ b/arch/riscv/include/uapi/asm/hwcap.h
@@ -21,6 +21,7 @@
#define COMPAT_HWCAP_ISA_F (1 << ('F' - 'A'))
#define COMPAT_HWCAP_ISA_D (1 << ('D' - 'A'))
#define COMPAT_HWCAP_ISA_C (1 << ('C' - 'A'))
+#define COMPAT_HWCAP_ISA_B (1 << ('B' - 'A'))
#define COMPAT_HWCAP_ISA_V (1 << ('V' - 'A'))
#endif /* _UAPI_ASM_RISCV_HWCAP_H */
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 58d1e86e47ae7..430dc49a82863 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -121,6 +121,7 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_EXT_ZICCIF (1ULL << 3)
#define RISCV_HWPROBE_EXT_ZICCRSE (1ULL << 4)
#define RISCV_HWPROBE_EXT_ZA64RS (1ULL << 5)
+#define RISCV_HWPROBE_EXT_B (1ULL << 6)
/* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index b9538e69fa1b3..e0197160af6dd 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -468,6 +468,12 @@ static const unsigned int riscv_c_exts[] = {
RISCV_ISA_EXT_ZCD,
};
+static const unsigned int riscv_b_exts[] = {
+ RISCV_ISA_EXT_ZBA,
+ RISCV_ISA_EXT_ZBB,
+ RISCV_ISA_EXT_ZBS,
+};
+
/*
* The canonical order of ISA extension names in the ISA string is defined in
* chapter 27 of the unprivileged specification.
@@ -515,6 +521,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA_VALIDATE(d, RISCV_ISA_EXT_D, riscv_ext_d_validate),
__RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_Q),
__RISCV_ISA_EXT_SUPERSET(c, RISCV_ISA_EXT_C, riscv_c_exts),
+ __RISCV_ISA_EXT_SUPERSET(b, RISCV_ISA_EXT_B, riscv_b_exts),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(v, RISCV_ISA_EXT_V, riscv_v_exts, riscv_ext_vector_float_validate),
__RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_H),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
@@ -1133,6 +1140,7 @@ void __init riscv_fill_hwcap(void)
isa2hwcap[RISCV_ISA_EXT_F] = COMPAT_HWCAP_ISA_F;
isa2hwcap[RISCV_ISA_EXT_D] = COMPAT_HWCAP_ISA_D;
isa2hwcap[RISCV_ISA_EXT_C] = COMPAT_HWCAP_ISA_C;
+ isa2hwcap[RISCV_ISA_EXT_B] = COMPAT_HWCAP_ISA_B;
isa2hwcap[RISCV_ISA_EXT_V] = COMPAT_HWCAP_ISA_V;
if (!acpi_disabled) {
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index b15ac9adf7920..dcc102bf8f183 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -210,6 +210,7 @@ static void hwprobe_isa_ext1(struct riscv_hwprobe *pair,
EXT_KEY(isainfo->isa, ZICCIF, pair->value, missing);
EXT_KEY(isainfo->isa, ZICCRSE, pair->value, missing);
EXT_KEY(isainfo->isa, ZA64RS, pair->value, missing);
+ EXT_KEY(isainfo->isa, B, pair->value, missing);
}
/* Now turn off reporting features if any CPU is missing it. */
--
2.43.0
^ permalink raw reply related
* [PATCH v4 06/16] riscv: Add Ziccamoa, Ziccif, Ziccrse, and Za64rs to cpufeature and hwprobe
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
From: Andrew Jones <andrew.jones@oss.qualcomm.com>
Add Ziccamoa, Ziccif, and Za64rs to riscv_isa_ext[] so they can be
parsed from devicetree/ACPI ISA strings. Ziccrse is already present
in cpufeature; this patch only adds its hwprobe exposure.
Expose all four extensions via hwprobe through new bits in
RISCV_HWPROBE_KEY_IMA_EXT_1 (RISCV_HWPROBE_EXT_ZICCAMOA, _ZICCIF,
_ZICCRSE, _ZA64RS), so userspace can probe each of these
RVA23U64-mandatory extensions individually.
Rationale for the validation dependencies added for Ziccamoa and Za64rs:
1) Ziccamoa depends on Zaamo. The RVA23 profile prose was updated
post-ratification to spell out the Zaamo reference: commit
2b218613752d in riscv/riscv-profiles ("Improve description of
Ziccamoa (#224)") reworded the rva23-profile.adoc (and other profiles
that include Ziccamoa) text from "must support all atomics in A" to
"must support all atomics in the Zaamo extension" [1].
2) Za64rs depends on Zalrsc. The unprivileged ISA manual src/zars.adoc,
integrated in commit ebe06adc22cd ("Integrate profiles as Volume III
(#2771)"), defines Za64rs as: "The Za64rs extension requires that the
reservation sets used by the instructions in the Zalrsc extension be
contiguous, naturally aligned, and at most 64 bytes in size" [2].
Link: https://github.com/riscv/riscv-profiles/commit/2b218613752d63287286b5ae801b820cbd8cc10c [1]
Link: https://github.com/riscv/riscv-isa-manual/blob/main/src/unpriv/zars.adoc [2]
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: No change.
v3: Indent the added hwprobe.rst entries to match the normalized style; no other change.
v2:
- Rebased to v7.1-rc2.
- Reworded subject and expanded commit message.
- Validation added for Ziccamoa depending on Zaamo and Za64rs depending
on Zalrsc.
---
Documentation/arch/riscv/hwprobe.rst | 16 ++++++++++++++++
arch/riscv/include/asm/hwcap.h | 3 +++
arch/riscv/include/uapi/asm/hwprobe.h | 4 ++++
arch/riscv/kernel/cpufeature.c | 21 +++++++++++++++++++++
arch/riscv/kernel/sys_hwprobe.c | 4 ++++
5 files changed, 48 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index 49d9fb68632d0..893e1a1215d23 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -405,3 +405,19 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_ZICCLSM`: The Zicclsm extension is supported,
as defined in the RISC-V Profiles specification starting from commit
b1d80660 ("Updated to ratified state.")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICCAMOA`: The Ziccamoa extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICCIF`: The Ziccif extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICCRSE`: The Ziccrse extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZA64RS`: The Za64rs extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index e8f4a7dd96a93..0acb7a01ecc0f 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -113,6 +113,9 @@
#define RISCV_ISA_EXT_ZICFILP 104
#define RISCV_ISA_EXT_ZICFISS 105
#define RISCV_ISA_EXT_ZICCLSM 106
+#define RISCV_ISA_EXT_ZICCAMOA 107
+#define RISCV_ISA_EXT_ZICCIF 108
+#define RISCV_ISA_EXT_ZA64RS 109
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 6819df159c51e..58d1e86e47ae7 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -117,6 +117,10 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_KEY_IMA_EXT_1 16
#define RISCV_HWPROBE_EXT_ZICFISS (1ULL << 0)
#define RISCV_HWPROBE_EXT_ZICCLSM (1ULL << 1)
+#define RISCV_HWPROBE_EXT_ZICCAMOA (1ULL << 2)
+#define RISCV_HWPROBE_EXT_ZICCIF (1ULL << 3)
+#define RISCV_HWPROBE_EXT_ZICCRSE (1ULL << 4)
+#define RISCV_HWPROBE_EXT_ZA64RS (1ULL << 5)
/* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 1fb595581adcf..b9538e69fa1b3 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -90,6 +90,24 @@ static int riscv_ext_f_depends(const struct riscv_isa_ext_data *data,
return -EPROBE_DEFER;
}
+static int riscv_ext_zaamo_depends(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZAAMO))
+ return 0;
+
+ return -EPROBE_DEFER;
+}
+
+static int riscv_ext_zalrsc_depends(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZALRSC))
+ return 0;
+
+ return -EPROBE_DEFER;
+}
+
static int riscv_ext_zicbom_validate(const struct riscv_isa_ext_data *data,
const unsigned long *isa_bitmap)
{
@@ -502,6 +520,8 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),
+ __RISCV_ISA_EXT_DATA_VALIDATE(ziccamoa, RISCV_ISA_EXT_ZICCAMOA, riscv_ext_zaamo_depends),
+ __RISCV_ISA_EXT_DATA(ziccif, RISCV_ISA_EXT_ZICCIF),
__RISCV_ISA_EXT_DATA(zicclsm, RISCV_ISA_EXT_ZICCLSM),
__RISCV_ISA_EXT_DATA(ziccrse, RISCV_ISA_EXT_ZICCRSE),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicfilp, RISCV_ISA_EXT_ZICFILP, riscv_xlinuxenvcfg_exts,
@@ -516,6 +536,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
__RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
__RISCV_ISA_EXT_DATA(zimop, RISCV_ISA_EXT_ZIMOP),
+ __RISCV_ISA_EXT_DATA_VALIDATE(za64rs, RISCV_ISA_EXT_ZA64RS, riscv_ext_zalrsc_depends),
__RISCV_ISA_EXT_DATA(zaamo, RISCV_ISA_EXT_ZAAMO),
__RISCV_ISA_EXT_DATA(zabha, RISCV_ISA_EXT_ZABHA),
__RISCV_ISA_EXT_DATA(zacas, RISCV_ISA_EXT_ZACAS),
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index 9cf62266f1890..b15ac9adf7920 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -206,6 +206,10 @@ static void hwprobe_isa_ext1(struct riscv_hwprobe *pair,
*/
EXT_KEY(isainfo->isa, ZICFISS, pair->value, missing);
EXT_KEY(isainfo->isa, ZICCLSM, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZICCAMOA, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZICCIF, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZICCRSE, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZA64RS, pair->value, missing);
}
/* Now turn off reporting features if any CPU is missing it. */
--
2.43.0
^ permalink raw reply related
* [PATCH v4 05/16] riscv: Add Zicclsm to cpufeature and hwprobe
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Jesse Taube,
Conor Dooley, Charlie Jenkins, Andrew Jones, Andy Chiu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
From: Jesse Taube <jesse@rivosinc.com>
Zicclsm requires misaligned support for all regular load and store
instructions, both scalar and vector, but not AMOs or other
specialized forms of memory access, to main memory regions with both
the cacheability and coherence PMAs, as defined in the profiles spec.
Even though mandated, misaligned loads and stores might execute
extremely slowly. Standard software distributions should assume their
existence only for correctness, not for performance.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andy Chiu <andy.chiu@sifive.com>
Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
Tested-by: Charlie Jenkins <charlie@rivosinc.com>
Signed-off-by: Jesse Taube <jesse@rivosinc.com>
[Rebased, rewrote doc text, minor commit message revisions]
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: No change.
v3:
- Move the hwprobe.rst entry to the IMA_EXT_1 section so its
documentation matches the IMA_EXT_1 bit it was allocated in v2
(Sashiko, agreed by Andrew).
v2:
- Rebased onto v7.1-rc2; moved ZICCLSM to IMA_EXT_1 and
allocated a new bit for it
---
Documentation/arch/riscv/hwprobe.rst | 4 ++++
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/include/uapi/asm/hwprobe.h | 1 +
arch/riscv/kernel/cpufeature.c | 1 +
arch/riscv/kernel/sys_hwprobe.c | 1 +
5 files changed, 8 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index d9928641deb99..49d9fb68632d0 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -401,3 +401,7 @@ The following keys are defined:
as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI)
extensions specification, ratified in commit 302a2d45c243
("Update build-pdf.yml") of riscv-cfi.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICCLSM`: The Zicclsm extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 44bf8c7d8acc5..e8f4a7dd96a93 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -112,6 +112,7 @@
#define RISCV_ISA_EXT_ZCLSD 103
#define RISCV_ISA_EXT_ZICFILP 104
#define RISCV_ISA_EXT_ZICFISS 105
+#define RISCV_ISA_EXT_ZICCLSM 106
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 9139edba0aecb..6819df159c51e 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -116,6 +116,7 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE 15
#define RISCV_HWPROBE_KEY_IMA_EXT_1 16
#define RISCV_HWPROBE_EXT_ZICFISS (1ULL << 0)
+#define RISCV_HWPROBE_EXT_ZICCLSM (1ULL << 1)
/* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 686dde3ce3b98..1fb595581adcf 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -502,6 +502,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),
+ __RISCV_ISA_EXT_DATA(zicclsm, RISCV_ISA_EXT_ZICCLSM),
__RISCV_ISA_EXT_DATA(ziccrse, RISCV_ISA_EXT_ZICCRSE),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicfilp, RISCV_ISA_EXT_ZICFILP, riscv_xlinuxenvcfg_exts,
riscv_cfilp_validate),
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index f8f68ba781b45..9cf62266f1890 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -205,6 +205,7 @@ static void hwprobe_isa_ext1(struct riscv_hwprobe *pair,
* in the hart_isa bitmap, are made.
*/
EXT_KEY(isainfo->isa, ZICFISS, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZICCLSM, pair->value, missing);
}
/* Now turn off reporting features if any CPU is missing it. */
--
2.43.0
^ permalink raw reply related
* [PATCH v4 04/16] riscv: Standardize extension capitalization
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Charlie Jenkins,
Charlie Jenkins, Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
From: Charlie Jenkins <charlie@rivosinc.com>
The base extensions are often lowercase and were written as lowercase in
hwcap, but other references to these extensions in the kernel are
uppercase. Standardize the case to make it easier to handle macro
expansion.
Signed-off-by: Charlie Jenkins <thecharlesjenkins@gmail.com>
[Apply KVM_ISA_EXT_ARR(), fixup all KVM use.]
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Acked-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Anup Patel <anup@brainfault.org>
---
v4: No change.
v3:
- Collected Anup's Acked-by and Reviewed-by.
- Rebased onto v7.1-rc6: two more occurances between -rc2 and -rc6:
1). isa2hwcap[] indices added by commit 41337097f2823
2). the T-Head "v" workaround's clear_bit() added by commit d272b8d2dd132
v2:
- Rebased onto v7.1-rc2.
- KVM_ISA_EXT_ARR() consolidation moved to its new upstream location
(kvm/isa.c); host-side checks now use kvm_riscv_isa_check_host().
---
arch/riscv/include/asm/hwcap.h | 18 ++++++++--------
arch/riscv/include/asm/switch_to.h | 4 ++--
arch/riscv/kernel/cpufeature.c | 44 +++++++++++++++++++-------------------
arch/riscv/kernel/sys_hwprobe.c | 4 ++--
arch/riscv/kvm/isa.c | 16 +++++++-------
arch/riscv/kvm/main.c | 2 +-
arch/riscv/kvm/vcpu_fp.c | 20 ++++++++---------
arch/riscv/kvm/vcpu_onereg.c | 6 +++---
arch/riscv/kvm/vcpu_vector.c | 10 ++++-----
9 files changed, 62 insertions(+), 62 deletions(-)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 7ef8e5f55c8dc..44bf8c7d8acc5 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -10,15 +10,15 @@
#include <uapi/asm/hwcap.h>
-#define RISCV_ISA_EXT_a ('a' - 'a')
-#define RISCV_ISA_EXT_c ('c' - 'a')
-#define RISCV_ISA_EXT_d ('d' - 'a')
-#define RISCV_ISA_EXT_f ('f' - 'a')
-#define RISCV_ISA_EXT_h ('h' - 'a')
-#define RISCV_ISA_EXT_i ('i' - 'a')
-#define RISCV_ISA_EXT_m ('m' - 'a')
-#define RISCV_ISA_EXT_q ('q' - 'a')
-#define RISCV_ISA_EXT_v ('v' - 'a')
+#define RISCV_ISA_EXT_A ('a' - 'a')
+#define RISCV_ISA_EXT_C ('c' - 'a')
+#define RISCV_ISA_EXT_D ('d' - 'a')
+#define RISCV_ISA_EXT_F ('f' - 'a')
+#define RISCV_ISA_EXT_H ('h' - 'a')
+#define RISCV_ISA_EXT_I ('i' - 'a')
+#define RISCV_ISA_EXT_M ('m' - 'a')
+#define RISCV_ISA_EXT_Q ('q' - 'a')
+#define RISCV_ISA_EXT_V ('v' - 'a')
/*
* These macros represent the logical IDs of each multi-letter RISC-V ISA
diff --git a/arch/riscv/include/asm/switch_to.h b/arch/riscv/include/asm/switch_to.h
index 0e71eb82f920c..ff35a4d04f85a 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -60,8 +60,8 @@ static inline void __switch_to_fpu(struct task_struct *prev,
static __always_inline bool has_fpu(void)
{
- return riscv_has_extension_likely(RISCV_ISA_EXT_f) ||
- riscv_has_extension_likely(RISCV_ISA_EXT_d);
+ return riscv_has_extension_likely(RISCV_ISA_EXT_F) ||
+ riscv_has_extension_likely(RISCV_ISA_EXT_D);
}
#else
static __always_inline bool has_fpu(void) { return false; }
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index f46aa5602d74d..686dde3ce3b98 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -84,7 +84,7 @@ EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
static int riscv_ext_f_depends(const struct riscv_isa_ext_data *data,
const unsigned long *isa_bitmap)
{
- if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_f))
+ if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_F))
return 0;
return -EPROBE_DEFER;
@@ -146,7 +146,7 @@ static int riscv_ext_f_validate(const struct riscv_isa_ext_data *data,
* Due to extension ordering, d is checked before f, so no deferral
* is required.
*/
- if (!__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_d)) {
+ if (!__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_D)) {
pr_warn_once("This kernel does not support systems with F but not D\n");
return -EINVAL;
}
@@ -189,7 +189,7 @@ static int riscv_ext_vector_float_validate(const struct riscv_isa_ext_data *data
* Since this function validates vector only, and v/Zve* are probed
* after f/d, there's no need for a deferral here.
*/
- if (!__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_d))
+ if (!__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_D))
return -EINVAL;
return 0;
@@ -224,7 +224,7 @@ static int riscv_ext_zcd_validate(const struct riscv_isa_ext_data *data,
const unsigned long *isa_bitmap)
{
if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZCA) &&
- __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_d))
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_D))
return 0;
return -EPROBE_DEFER;
@@ -237,7 +237,7 @@ static int riscv_ext_zcf_validate(const struct riscv_isa_ext_data *data,
return -EINVAL;
if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZCA) &&
- __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_f))
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_F))
return 0;
return -EPROBE_DEFER;
@@ -490,15 +490,15 @@ static const unsigned int riscv_c_exts[] = {
* New entries to this struct should follow the ordering rules described above.
*/
const struct riscv_isa_ext_data riscv_isa_ext[] = {
- __RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
- __RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
- __RISCV_ISA_EXT_SUPERSET(a, RISCV_ISA_EXT_a, riscv_a_exts),
- __RISCV_ISA_EXT_DATA_VALIDATE(f, RISCV_ISA_EXT_f, riscv_ext_f_validate),
- __RISCV_ISA_EXT_DATA_VALIDATE(d, RISCV_ISA_EXT_d, riscv_ext_d_validate),
- __RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
- __RISCV_ISA_EXT_SUPERSET(c, RISCV_ISA_EXT_c, riscv_c_exts),
- __RISCV_ISA_EXT_SUPERSET_VALIDATE(v, RISCV_ISA_EXT_v, riscv_v_exts, riscv_ext_vector_float_validate),
- __RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
+ __RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_I),
+ __RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_M),
+ __RISCV_ISA_EXT_SUPERSET(a, RISCV_ISA_EXT_A, riscv_a_exts),
+ __RISCV_ISA_EXT_DATA_VALIDATE(f, RISCV_ISA_EXT_F, riscv_ext_f_validate),
+ __RISCV_ISA_EXT_DATA_VALIDATE(d, RISCV_ISA_EXT_D, riscv_ext_d_validate),
+ __RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_Q),
+ __RISCV_ISA_EXT_SUPERSET(c, RISCV_ISA_EXT_C, riscv_c_exts),
+ __RISCV_ISA_EXT_SUPERSET_VALIDATE(v, RISCV_ISA_EXT_V, riscv_v_exts, riscv_ext_vector_float_validate),
+ __RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_H),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),
@@ -897,7 +897,7 @@ static void __init riscv_fill_hwcap_from_isa_string(unsigned long *isa2hwcap)
* marchid.
*/
if (acpi_disabled && boot_vendorid == THEAD_VENDOR_ID && boot_archid == 0x0)
- clear_bit(RISCV_ISA_EXT_v, source_isa);
+ clear_bit(RISCV_ISA_EXT_V, source_isa);
riscv_resolve_isa(source_isa, isainfo->isa, &this_hwcap, isa2hwcap);
@@ -1105,13 +1105,13 @@ void __init riscv_fill_hwcap(void)
unsigned long isa2hwcap[RISCV_ISA_EXT_BASE] = {0};
int i, j;
- isa2hwcap[RISCV_ISA_EXT_i] = COMPAT_HWCAP_ISA_I;
- isa2hwcap[RISCV_ISA_EXT_m] = COMPAT_HWCAP_ISA_M;
- isa2hwcap[RISCV_ISA_EXT_a] = COMPAT_HWCAP_ISA_A;
- isa2hwcap[RISCV_ISA_EXT_f] = COMPAT_HWCAP_ISA_F;
- isa2hwcap[RISCV_ISA_EXT_d] = COMPAT_HWCAP_ISA_D;
- isa2hwcap[RISCV_ISA_EXT_c] = COMPAT_HWCAP_ISA_C;
- isa2hwcap[RISCV_ISA_EXT_v] = COMPAT_HWCAP_ISA_V;
+ isa2hwcap[RISCV_ISA_EXT_I] = COMPAT_HWCAP_ISA_I;
+ isa2hwcap[RISCV_ISA_EXT_M] = COMPAT_HWCAP_ISA_M;
+ isa2hwcap[RISCV_ISA_EXT_A] = COMPAT_HWCAP_ISA_A;
+ isa2hwcap[RISCV_ISA_EXT_F] = COMPAT_HWCAP_ISA_F;
+ isa2hwcap[RISCV_ISA_EXT_D] = COMPAT_HWCAP_ISA_D;
+ isa2hwcap[RISCV_ISA_EXT_C] = COMPAT_HWCAP_ISA_C;
+ isa2hwcap[RISCV_ISA_EXT_V] = COMPAT_HWCAP_ISA_V;
if (!acpi_disabled) {
riscv_fill_hwcap_from_isa_string(isa2hwcap);
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index 1659d31fd288f..f8f68ba781b45 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -88,10 +88,10 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
if (has_fpu())
pair->value |= RISCV_HWPROBE_IMA_FD;
- if (riscv_isa_extension_available(NULL, c))
+ if (riscv_isa_extension_available(NULL, C))
pair->value |= RISCV_HWPROBE_IMA_C;
- if (has_vector() && riscv_isa_extension_available(NULL, v))
+ if (has_vector() && riscv_isa_extension_available(NULL, V))
pair->value |= RISCV_HWPROBE_IMA_V;
/*
diff --git a/arch/riscv/kvm/isa.c b/arch/riscv/kvm/isa.c
index 1132d909cc25c..94077117d1136 100644
--- a/arch/riscv/kvm/isa.c
+++ b/arch/riscv/kvm/isa.c
@@ -17,14 +17,14 @@
/* Mapping between KVM ISA Extension ID & guest ISA extension ID */
static const unsigned long kvm_isa_ext_arr[] = {
/* Single letter extensions (alphabetically sorted) */
- [KVM_RISCV_ISA_EXT_A] = RISCV_ISA_EXT_a,
- [KVM_RISCV_ISA_EXT_C] = RISCV_ISA_EXT_c,
- [KVM_RISCV_ISA_EXT_D] = RISCV_ISA_EXT_d,
- [KVM_RISCV_ISA_EXT_F] = RISCV_ISA_EXT_f,
- [KVM_RISCV_ISA_EXT_H] = RISCV_ISA_EXT_h,
- [KVM_RISCV_ISA_EXT_I] = RISCV_ISA_EXT_i,
- [KVM_RISCV_ISA_EXT_M] = RISCV_ISA_EXT_m,
- [KVM_RISCV_ISA_EXT_V] = RISCV_ISA_EXT_v,
+ KVM_ISA_EXT_ARR(A),
+ KVM_ISA_EXT_ARR(C),
+ KVM_ISA_EXT_ARR(D),
+ KVM_ISA_EXT_ARR(F),
+ KVM_ISA_EXT_ARR(H),
+ KVM_ISA_EXT_ARR(I),
+ KVM_ISA_EXT_ARR(M),
+ KVM_ISA_EXT_ARR(V),
/* Multi letter extensions (alphabetically sorted) */
KVM_ISA_EXT_ARR(SMNPM),
KVM_ISA_EXT_ARR(SMSTATEEN),
diff --git a/arch/riscv/kvm/main.c b/arch/riscv/kvm/main.c
index cb8a65273c1f0..70640701310c8 100644
--- a/arch/riscv/kvm/main.c
+++ b/arch/riscv/kvm/main.c
@@ -85,7 +85,7 @@ static int __init riscv_kvm_init(void)
char slist[64];
const char *str;
- if (!riscv_isa_extension_available(NULL, h)) {
+ if (!riscv_isa_extension_available(NULL, H)) {
kvm_info("hypervisor extension not available\n");
return -ENODEV;
}
diff --git a/arch/riscv/kvm/vcpu_fp.c b/arch/riscv/kvm/vcpu_fp.c
index 6ad6df26a2fd4..bb11e6757d349 100644
--- a/arch/riscv/kvm/vcpu_fp.c
+++ b/arch/riscv/kvm/vcpu_fp.c
@@ -21,8 +21,8 @@ void kvm_riscv_vcpu_fp_reset(struct kvm_vcpu *vcpu)
struct kvm_cpu_context *cntx = &vcpu->arch.guest_context;
cntx->sstatus &= ~SR_FS;
- if (riscv_isa_extension_available(vcpu->arch.isa, f) ||
- riscv_isa_extension_available(vcpu->arch.isa, d))
+ if (riscv_isa_extension_available(vcpu->arch.isa, F) ||
+ riscv_isa_extension_available(vcpu->arch.isa, D))
cntx->sstatus |= SR_FS_INITIAL;
else
cntx->sstatus |= SR_FS_OFF;
@@ -38,9 +38,9 @@ void kvm_riscv_vcpu_guest_fp_save(struct kvm_cpu_context *cntx,
const unsigned long *isa)
{
if ((cntx->sstatus & SR_FS) == SR_FS_DIRTY) {
- if (riscv_isa_extension_available(isa, d))
+ if (riscv_isa_extension_available(isa, D))
__kvm_riscv_fp_d_save(cntx);
- else if (riscv_isa_extension_available(isa, f))
+ else if (riscv_isa_extension_available(isa, F))
__kvm_riscv_fp_f_save(cntx);
kvm_riscv_vcpu_fp_clean(cntx);
}
@@ -50,9 +50,9 @@ void kvm_riscv_vcpu_guest_fp_restore(struct kvm_cpu_context *cntx,
const unsigned long *isa)
{
if ((cntx->sstatus & SR_FS) != SR_FS_OFF) {
- if (riscv_isa_extension_available(isa, d))
+ if (riscv_isa_extension_available(isa, D))
__kvm_riscv_fp_d_restore(cntx);
- else if (riscv_isa_extension_available(isa, f))
+ else if (riscv_isa_extension_available(isa, F))
__kvm_riscv_fp_f_restore(cntx);
kvm_riscv_vcpu_fp_clean(cntx);
}
@@ -89,7 +89,7 @@ int kvm_riscv_vcpu_get_reg_fp(struct kvm_vcpu *vcpu,
void *reg_val;
if ((rtype == KVM_REG_RISCV_FP_F) &&
- riscv_isa_extension_available(vcpu->arch.isa, f)) {
+ riscv_isa_extension_available(vcpu->arch.isa, F)) {
if (KVM_REG_SIZE(reg->id) != sizeof(u32))
return -EINVAL;
if (reg_num == KVM_REG_RISCV_FP_F_REG(fcsr))
@@ -102,7 +102,7 @@ int kvm_riscv_vcpu_get_reg_fp(struct kvm_vcpu *vcpu,
} else
return -ENOENT;
} else if ((rtype == KVM_REG_RISCV_FP_D) &&
- riscv_isa_extension_available(vcpu->arch.isa, d)) {
+ riscv_isa_extension_available(vcpu->arch.isa, D)) {
if (reg_num == KVM_REG_RISCV_FP_D_REG(fcsr)) {
if (KVM_REG_SIZE(reg->id) != sizeof(u32))
return -EINVAL;
@@ -138,7 +138,7 @@ int kvm_riscv_vcpu_set_reg_fp(struct kvm_vcpu *vcpu,
void *reg_val;
if ((rtype == KVM_REG_RISCV_FP_F) &&
- riscv_isa_extension_available(vcpu->arch.isa, f)) {
+ riscv_isa_extension_available(vcpu->arch.isa, F)) {
if (KVM_REG_SIZE(reg->id) != sizeof(u32))
return -EINVAL;
if (reg_num == KVM_REG_RISCV_FP_F_REG(fcsr))
@@ -151,7 +151,7 @@ int kvm_riscv_vcpu_set_reg_fp(struct kvm_vcpu *vcpu,
} else
return -ENOENT;
} else if ((rtype == KVM_REG_RISCV_FP_D) &&
- riscv_isa_extension_available(vcpu->arch.isa, d)) {
+ riscv_isa_extension_available(vcpu->arch.isa, D)) {
if (reg_num == KVM_REG_RISCV_FP_D_REG(fcsr)) {
if (KVM_REG_SIZE(reg->id) != sizeof(u32))
return -EINVAL;
diff --git a/arch/riscv/kvm/vcpu_onereg.c b/arch/riscv/kvm/vcpu_onereg.c
index bb920e8923c93..5cc7ddd4aa276 100644
--- a/arch/riscv/kvm/vcpu_onereg.c
+++ b/arch/riscv/kvm/vcpu_onereg.c
@@ -770,7 +770,7 @@ static inline unsigned long num_fp_f_regs(const struct kvm_vcpu *vcpu)
{
const struct kvm_cpu_context *cntx = &vcpu->arch.guest_context;
- if (riscv_isa_extension_available(vcpu->arch.isa, f))
+ if (riscv_isa_extension_available(vcpu->arch.isa, F))
return sizeof(cntx->fp.f) / sizeof(u32);
else
return 0;
@@ -799,7 +799,7 @@ static inline unsigned long num_fp_d_regs(const struct kvm_vcpu *vcpu)
{
const struct kvm_cpu_context *cntx = &vcpu->arch.guest_context;
- if (riscv_isa_extension_available(vcpu->arch.isa, d))
+ if (riscv_isa_extension_available(vcpu->arch.isa, D))
return sizeof(cntx->fp.d.f) / sizeof(u64) + 1;
else
return 0;
@@ -878,7 +878,7 @@ static inline unsigned long num_sbi_regs(struct kvm_vcpu *vcpu)
static inline unsigned long num_vector_regs(const struct kvm_vcpu *vcpu)
{
- if (!riscv_isa_extension_available(vcpu->arch.isa, v))
+ if (!riscv_isa_extension_available(vcpu->arch.isa, V))
return 0;
/* vstart, vl, vtype, vcsr, vlenb and 32 vector regs */
diff --git a/arch/riscv/kvm/vcpu_vector.c b/arch/riscv/kvm/vcpu_vector.c
index 62d2fb77bb9b9..f26108a4e601e 100644
--- a/arch/riscv/kvm/vcpu_vector.c
+++ b/arch/riscv/kvm/vcpu_vector.c
@@ -26,7 +26,7 @@ void kvm_riscv_vcpu_vector_reset(struct kvm_vcpu *vcpu)
cntx->vector.vlenb = riscv_v_vsize / 32;
- if (riscv_isa_extension_available(isa, v)) {
+ if (riscv_isa_extension_available(isa, V)) {
cntx->sstatus |= SR_VS_INITIAL;
WARN_ON(!cntx->vector.datap);
memset(cntx->vector.datap, 0, riscv_v_vsize);
@@ -45,7 +45,7 @@ void kvm_riscv_vcpu_guest_vector_save(struct kvm_cpu_context *cntx,
unsigned long *isa)
{
if ((cntx->sstatus & SR_VS) == SR_VS_DIRTY) {
- if (riscv_isa_extension_available(isa, v))
+ if (riscv_isa_extension_available(isa, V))
__kvm_riscv_vector_save(cntx);
kvm_riscv_vcpu_vector_clean(cntx);
}
@@ -55,7 +55,7 @@ void kvm_riscv_vcpu_guest_vector_restore(struct kvm_cpu_context *cntx,
unsigned long *isa)
{
if ((cntx->sstatus & SR_VS) != SR_VS_OFF) {
- if (riscv_isa_extension_available(isa, v))
+ if (riscv_isa_extension_available(isa, V))
__kvm_riscv_vector_restore(cntx);
kvm_riscv_vcpu_vector_clean(cntx);
}
@@ -154,7 +154,7 @@ int kvm_riscv_vcpu_get_reg_vector(struct kvm_vcpu *vcpu,
void *reg_addr;
int rc;
- if (!riscv_isa_extension_available(isa, v))
+ if (!riscv_isa_extension_available(isa, V))
return -ENOENT;
rc = kvm_riscv_vcpu_vreg_addr(vcpu, reg_num, reg_size, ®_addr);
@@ -180,7 +180,7 @@ int kvm_riscv_vcpu_set_reg_vector(struct kvm_vcpu *vcpu,
void *reg_addr;
int rc;
- if (!riscv_isa_extension_available(isa, v))
+ if (!riscv_isa_extension_available(isa, V))
return -ENOENT;
if (reg_num == KVM_REG_RISCV_VECTOR_CSR_REG(vlenb)) {
--
2.43.0
^ permalink raw reply related
* [PATCH v4 03/16] riscv: hwprobe.rst: Document EXT_ZICFISS and EXT_ZICFILP
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
RISCV_HWPROBE_EXT_ZICFISS and RISCV_HWPROBE_EXT_ZICFILP are defined in
the hwprobe uAPI but are not documented in
Documentation/arch/riscv/hwprobe.rst. Add documentation for them.
Link: https://github.com/riscv/riscv-cfi/commit/302a2d45c2435940d9a63571c66bc038adc74133
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
---
v4:
- Update the commit message.
- Cite riscv-cfi commit 302a2d45c243 (tag v1.0) instead of ff03d8485a04,
per Andrew.
- Add a Link: tag for this citation.
v3:
- Also document RISCV_HWPROBE_EXT_ZICFILP (bit 63 of IMA_EXT_0), the
sibling enumeration to ZICFISS (Andrew).
v2: New patch.
---
Documentation/arch/riscv/hwprobe.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index a09a8f16bd16f..d9928641deb99 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -289,6 +289,11 @@ The following keys are defined:
defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
load/store pair for RV32 with the main manual") of the riscv-isa-manual.
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICFILP`: The Zicfilp extension is supported,
+ as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI)
+ extensions specification, ratified in commit 302a2d45c243
+ ("Update build-pdf.yml") of riscv-cfi.
+
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: Deprecated. Returns similar values to
:c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
mistakenly classified as a bitmask rather than a value.
@@ -391,3 +396,8 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_1`: A bitmask containing additional
extensions that are compatible with the
:c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: base system behavior.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICFISS`: The Zicfiss extension is supported,
+ as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI)
+ extensions specification, ratified in commit 302a2d45c243
+ ("Update build-pdf.yml") of riscv-cfi.
--
2.43.0
^ permalink raw reply related
* [PATCH v4 02/16] riscv: hwprobe.rst: Make indentation consistent
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
From: Andrew Jones <andrew.jones@oss.qualcomm.com>
A handful of vendor-extension entries indent continuation lines with a
tab character, while the rest of hwprobe.rst uses spaces. In addition,
many list items align their continuation lines under the 'm' of
':c:macro:' (column 7) rather than under the item text (column 4), so
the file mixes several indentation styles.
Replace the tabs with spaces and align every list item's continuation
lines under the item text, giving the whole file one consistent style.
Whitespace-only change, no functional change.
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
[Guodong: extend from tabs->spaces to normalizing all continuation-line
indentation across the file]
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: No change.
v3:
- Move to the front of the series.
- Extend from replacing tabs to normalizing all continuation-line
indentation, so later patches add documentation on top of a
consistent base (Andrew).
---
Documentation/arch/riscv/hwprobe.rst | 194 +++++++++++++++++------------------
1 file changed, 97 insertions(+), 97 deletions(-)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index c420a8349bc68..a09a8f16bd16f 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -82,121 +82,121 @@ The following keys are defined:
version 1.0 of the RISC-V Vector extension manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZBA`: The Zba address generation extension is
- supported, as defined in version 1.0 of the Bit-Manipulation ISA
- extensions.
+ supported, as defined in version 1.0 of the Bit-Manipulation ISA
+ extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZBB`: The Zbb extension is supported, as defined
- in version 1.0 of the Bit-Manipulation ISA extensions.
+ in version 1.0 of the Bit-Manipulation ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
- in version 1.0 of the Bit-Manipulation ISA extensions.
+ in version 1.0 of the Bit-Manipulation ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
- ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+ ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
* :c:macro:`RISCV_HWPROBE_EXT_ZBC` The Zbc extension is supported, as defined
- in version 1.0 of the Bit-Manipulation ISA extensions.
+ in version 1.0 of the Bit-Manipulation ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZBKB` The Zbkb extension is supported, as
- defined in version 1.0 of the Scalar Crypto ISA extensions.
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZBKC` The Zbkc extension is supported, as
- defined in version 1.0 of the Scalar Crypto ISA extensions.
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZBKX` The Zbkx extension is supported, as
- defined in version 1.0 of the Scalar Crypto ISA extensions.
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKND` The Zknd extension is supported, as
- defined in version 1.0 of the Scalar Crypto ISA extensions.
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKNE` The Zkne extension is supported, as
- defined in version 1.0 of the Scalar Crypto ISA extensions.
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKNH` The Zknh extension is supported, as
- defined in version 1.0 of the Scalar Crypto ISA extensions.
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKSED` The Zksed extension is supported, as
- defined in version 1.0 of the Scalar Crypto ISA extensions.
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKSH` The Zksh extension is supported, as
- defined in version 1.0 of the Scalar Crypto ISA extensions.
+ defined in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZKT` The Zkt extension is supported, as defined
- in version 1.0 of the Scalar Crypto ISA extensions.
+ in version 1.0 of the Scalar Crypto ISA extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZVBB`: The Zvbb extension is supported as
- defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVBC`: The Zvbc extension is supported as
- defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKB`: The Zvkb extension is supported as
- defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKG`: The Zvkg extension is supported as
- defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKNED`: The Zvkned extension is supported as
- defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKNHA`: The Zvknha extension is supported as
- defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKNHB`: The Zvknhb extension is supported as
- defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKSED`: The Zvksed extension is supported as
- defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKSH`: The Zvksh extension is supported as
- defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZVKT`: The Zvkt extension is supported as
- defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
+ defined in version 1.0 of the RISC-V Cryptography Extensions Volume II.
* :c:macro:`RISCV_HWPROBE_EXT_ZFH`: The Zfh extension version 1.0 is supported
- as defined in the RISC-V ISA manual.
+ as defined in the RISC-V ISA manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZFHMIN`: The Zfhmin extension version 1.0 is
- supported as defined in the RISC-V ISA manual.
+ supported as defined in the RISC-V ISA manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZIHINTNTL`: The Zihintntl extension version 1.0
- is supported as defined in the RISC-V ISA manual.
+ is supported as defined in the RISC-V ISA manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZVFH`: The Zvfh extension is supported as
- defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
- ("Remove draft warnings from Zvfh[min]").
+ defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
+ ("Remove draft warnings from Zvfh[min]").
* :c:macro:`RISCV_HWPROBE_EXT_ZVFHMIN`: The Zvfhmin extension is supported as
- defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
- ("Remove draft warnings from Zvfh[min]").
+ defined in the RISC-V Vector manual starting from commit e2ccd0548d6c
+ ("Remove draft warnings from Zvfh[min]").
* :c:macro:`RISCV_HWPROBE_EXT_ZFA`: The Zfa extension is supported as
- defined in the RISC-V ISA manual starting from commit 056b6ff467c7
- ("Zfa is ratified").
+ defined in the RISC-V ISA manual starting from commit 056b6ff467c7
+ ("Zfa is ratified").
* :c:macro:`RISCV_HWPROBE_EXT_ZTSO`: The Ztso extension is supported as
- defined in the RISC-V ISA manual starting from commit 5618fb5a216b
- ("Ztso is now ratified.")
+ defined in the RISC-V ISA manual starting from commit 5618fb5a216b
+ ("Ztso is now ratified.")
* :c:macro:`RISCV_HWPROBE_EXT_ZACAS`: The Zacas extension is supported as
- defined in the Atomic Compare-and-Swap (CAS) instructions manual starting
- from commit 5059e0ca641c ("update to ratified").
+ defined in the Atomic Compare-and-Swap (CAS) instructions manual starting
+ from commit 5059e0ca641c ("update to ratified").
* :c:macro:`RISCV_HWPROBE_EXT_ZICNTR`: The Zicntr extension version 2.0
- is supported as defined in the RISC-V ISA manual.
+ is supported as defined in the RISC-V ISA manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZICOND`: The Zicond extension is supported as
- defined in the RISC-V Integer Conditional (Zicond) operations extension
- manual starting from commit 95cf1f9 ("Add changes requested by Ved
- during signoff")
+ defined in the RISC-V Integer Conditional (Zicond) operations extension
+ manual starting from commit 95cf1f9 ("Add changes requested by Ved
+ during signoff")
* :c:macro:`RISCV_HWPROBE_EXT_ZIHINTPAUSE`: The Zihintpause extension is
- supported as defined in the RISC-V ISA manual starting from commit
- d8ab5c78c207 ("Zihintpause is ratified").
+ supported as defined in the RISC-V ISA manual starting from commit
+ d8ab5c78c207 ("Zihintpause is ratified").
* :c:macro:`RISCV_HWPROBE_EXT_ZIHPM`: The Zihpm extension version 2.0
- is supported as defined in the RISC-V ISA manual.
+ is supported as defined in the RISC-V ISA manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZVE32X`: The Vector sub-extension Zve32x is
supported, as defined by version 1.0 of the RISC-V Vector extension manual.
@@ -214,84 +214,84 @@ The following keys are defined:
supported, as defined by version 1.0 of the RISC-V Vector extension manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZIMOP`: The Zimop May-Be-Operations extension is
- supported as defined in the RISC-V ISA manual starting from commit
- 58220614a5f ("Zimop is ratified/1.0").
+ supported as defined in the RISC-V ISA manual starting from commit
+ 58220614a5f ("Zimop is ratified/1.0").
* :c:macro:`RISCV_HWPROBE_EXT_ZCA`: The Zca extension part of Zc* standard
- extensions for code size reduction, as ratified in commit 8be3419c1c0
- ("Zcf doesn't exist on RV64 as it contains no instructions") of
- riscv-code-size-reduction.
+ extensions for code size reduction, as ratified in commit 8be3419c1c0
+ ("Zcf doesn't exist on RV64 as it contains no instructions") of
+ riscv-code-size-reduction.
* :c:macro:`RISCV_HWPROBE_EXT_ZCB`: The Zcb extension part of Zc* standard
- extensions for code size reduction, as ratified in commit 8be3419c1c0
- ("Zcf doesn't exist on RV64 as it contains no instructions") of
- riscv-code-size-reduction.
+ extensions for code size reduction, as ratified in commit 8be3419c1c0
+ ("Zcf doesn't exist on RV64 as it contains no instructions") of
+ riscv-code-size-reduction.
* :c:macro:`RISCV_HWPROBE_EXT_ZCD`: The Zcd extension part of Zc* standard
- extensions for code size reduction, as ratified in commit 8be3419c1c0
- ("Zcf doesn't exist on RV64 as it contains no instructions") of
- riscv-code-size-reduction.
+ extensions for code size reduction, as ratified in commit 8be3419c1c0
+ ("Zcf doesn't exist on RV64 as it contains no instructions") of
+ riscv-code-size-reduction.
* :c:macro:`RISCV_HWPROBE_EXT_ZCF`: The Zcf extension part of Zc* standard
- extensions for code size reduction, as ratified in commit 8be3419c1c0
- ("Zcf doesn't exist on RV64 as it contains no instructions") of
- riscv-code-size-reduction.
+ extensions for code size reduction, as ratified in commit 8be3419c1c0
+ ("Zcf doesn't exist on RV64 as it contains no instructions") of
+ riscv-code-size-reduction.
* :c:macro:`RISCV_HWPROBE_EXT_ZCMOP`: The Zcmop May-Be-Operations extension is
- supported as defined in the RISC-V ISA manual starting from commit
- c732a4f39a4 ("Zcmop is ratified/1.0").
+ supported as defined in the RISC-V ISA manual starting from commit
+ c732a4f39a4 ("Zcmop is ratified/1.0").
* :c:macro:`RISCV_HWPROBE_EXT_ZAWRS`: The Zawrs extension is supported as
- ratified in commit 98918c844281 ("Merge pull request #1217 from
- riscv/zawrs") of riscv-isa-manual.
+ ratified in commit 98918c844281 ("Merge pull request #1217 from
+ riscv/zawrs") of riscv-isa-manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZAAMO`: The Zaamo extension is supported as
- defined in the in the RISC-V ISA manual starting from commit e87412e621f1
- ("integrate Zaamo and Zalrsc text (#1304)").
+ defined in the in the RISC-V ISA manual starting from commit e87412e621f1
+ ("integrate Zaamo and Zalrsc text (#1304)").
* :c:macro:`RISCV_HWPROBE_EXT_ZALASR`: The Zalasr extension is supported as
- frozen at commit 194f0094 ("Version 0.9 for freeze") of riscv-zalasr.
+ frozen at commit 194f0094 ("Version 0.9 for freeze") of riscv-zalasr.
* :c:macro:`RISCV_HWPROBE_EXT_ZALRSC`: The Zalrsc extension is supported as
- defined in the in the RISC-V ISA manual starting from commit e87412e621f1
- ("integrate Zaamo and Zalrsc text (#1304)").
+ defined in the in the RISC-V ISA manual starting from commit e87412e621f1
+ ("integrate Zaamo and Zalrsc text (#1304)").
* :c:macro:`RISCV_HWPROBE_EXT_SUPM`: The Supm extension is supported as
- defined in version 1.0 of the RISC-V Pointer Masking extensions.
+ defined in version 1.0 of the RISC-V Pointer Masking extensions.
* :c:macro:`RISCV_HWPROBE_EXT_ZFBFMIN`: The Zfbfmin extension is supported as
- defined in the RISC-V ISA manual starting from commit 4dc23d6229de
- ("Added Chapter title to BF16").
+ defined in the RISC-V ISA manual starting from commit 4dc23d6229de
+ ("Added Chapter title to BF16").
* :c:macro:`RISCV_HWPROBE_EXT_ZVFBFMIN`: The Zvfbfmin extension is supported as
- defined in the RISC-V ISA manual starting from commit 4dc23d6229de
- ("Added Chapter title to BF16").
+ defined in the RISC-V ISA manual starting from commit 4dc23d6229de
+ ("Added Chapter title to BF16").
* :c:macro:`RISCV_HWPROBE_EXT_ZVFBFWMA`: The Zvfbfwma extension is supported as
- defined in the RISC-V ISA manual starting from commit 4dc23d6229de
- ("Added Chapter title to BF16").
+ defined in the RISC-V ISA manual starting from commit 4dc23d6229de
+ ("Added Chapter title to BF16").
* :c:macro:`RISCV_HWPROBE_EXT_ZICBOM`: The Zicbom extension is supported, as
- ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+ ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
* :c:macro:`RISCV_HWPROBE_EXT_ZABHA`: The Zabha extension is supported as
- ratified in commit 49f49c842ff9 ("Update to Rafified state") of
- riscv-zabha.
+ ratified in commit 49f49c842ff9 ("Update to Rafified state") of
+ riscv-zabha.
* :c:macro:`RISCV_HWPROBE_EXT_ZICBOP`: The Zicbop extension is supported, as
- ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+ ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
* :c:macro:`RISCV_HWPROBE_EXT_ZILSD`: The Zilsd extension is supported as
- defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
- load/store pair for RV32 with the main manual") of the riscv-isa-manual.
+ defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
+ load/store pair for RV32 with the main manual") of the riscv-isa-manual.
* :c:macro:`RISCV_HWPROBE_EXT_ZCLSD`: The Zclsd extension is supported as
- defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
- load/store pair for RV32 with the main manual") of the riscv-isa-manual.
+ defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
+ load/store pair for RV32 with the main manual") of the riscv-isa-manual.
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: Deprecated. Returns similar values to
- :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
- mistakenly classified as a bitmask rather than a value.
+ :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
+ mistakenly classified as a bitmask rather than a value.
* :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`: An enum value describing
the performance of misaligned scalar native word accesses on the selected set
@@ -326,7 +326,7 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_KEY_TIME_CSR_FREQ`: Frequency (in Hz) of `time CSR`.
* :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`: An enum value describing the
- performance of misaligned vector accesses on the selected set of processors.
+ performance of misaligned vector accesses on the selected set of processors.
* :c:macro:`RISCV_HWPROBE_MISALIGNED_VECTOR_UNKNOWN`: The performance of misaligned
vector accesses is unknown.
@@ -348,7 +348,7 @@ The following keys are defined:
* MIPS
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XMIPSEXECTL`: The xmipsexectl vendor
- extension is supported in the MIPS ISA extensions spec.
+ extension is supported in the MIPS ISA extensions spec.
* :c:macro:`RISCV_HWPROBE_KEY_VENDOR_EXT_THEAD_0`: A bitmask containing the
thead vendor extensions that are compatible with the
@@ -357,8 +357,8 @@ The following keys are defined:
* T-HEAD
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XTHEADVECTOR`: The xtheadvector vendor
- extension is supported in the T-Head ISA extensions spec starting from
- commit a18c801634 ("Add T-Head VECTOR vendor extension. ").
+ extension is supported in the T-Head ISA extensions spec starting from
+ commit a18c801634 ("Add T-Head VECTOR vendor extension. ").
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOM_BLOCK_SIZE`: An unsigned int which
represents the size of the Zicbom block in bytes.
@@ -370,20 +370,20 @@ The following keys are defined:
* SIFIVE
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCDOD`: The Xsfqmaccdod vendor
- extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
- Extensions Specification.
+ extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
+ Extensions Specification.
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCQOQ`: The Xsfqmaccqoq vendor
- extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
- Instruction Extensions Specification.
+ extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
+ Instruction Extensions Specification.
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFNRCLIPXFQF`: The Xsfvfnrclipxfqf
- vendor extension is supported in version 1.0 of SiFive FP32-to-int8 Ranged
- Clip Instructions Extensions Specification.
+ vendor extension is supported in version 1.0 of SiFive FP32-to-int8 Ranged
+ Clip Instructions Extensions Specification.
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFWMACCQQQ`: The Xsfvfwmaccqqq
- vendor extension is supported in version 1.0 of Matrix Multiply Accumulate
- Instruction Extensions Specification.
+ vendor extension is supported in version 1.0 of Matrix Multiply Accumulate
+ Instruction Extensions Specification.
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE`: An unsigned int which
represents the size of the Zicbop block in bytes.
--
2.43.0
^ permalink raw reply related
* [PATCH v4 01/16] dt-bindings: riscv: sort multi-letter Z extensions alphanumerically
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-0-3f01a2449488@gmail.com>
The multi-letter extension enum is documented as being sorted
alphanumerically (see the "multi-letter extensions, sorted
alphanumerically" comment), but several Z entries have drifted out of
order.
Reorder the affected entries so the multi-letter Z list is sorted
alphanumerically again.
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
v4: New patch.
---
.../devicetree/bindings/riscv/extensions.yaml | 184 ++++++++++-----------
1 file changed, 92 insertions(+), 92 deletions(-)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 2b0a8a93bb214..5ffc40d599c02 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -457,6 +457,13 @@ properties:
merged in the riscv-isa-manual by commit dbc79cf28a2 ("Initial seed
of zc.adoc to src tree.").
+ - const: zclsd
+ description:
+ The Zclsd extension implements the compressed (16-bit) version of the
+ Load/Store Pair for RV32. As with Zilsd, this extension was ratified
+ in commit f88abf1 ("Integrating load/store pair for RV32 with the
+ main manual") of riscv-isa-manual.
+
- const: zcmop
description:
The standard Zcmop extension version 1.0, as ratified in commit
@@ -487,6 +494,22 @@ properties:
in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
riscv-isa-manual.
+ - const: zicbom
+ description:
+ The standard Zicbom extension for base cache management operations as
+ ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+
+ - const: zicbop
+ description:
+ The standard Zicbop extension for cache-block prefetch instructions
+ as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of
+ riscv-CMOs.
+
+ - const: zicboz
+ description:
+ The standard Zicboz extension for cache-block zeroing as ratified
+ in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
+
- const: ziccamoa
description:
The standard Ziccamoa extension for main memory (cacheability and
@@ -514,6 +537,66 @@ properties:
guarantee on LR/SC sequences, as ratified in commit b1d806605f87
("Updated to ratified state.") of the riscv profiles specification.
+ - const: zicfilp
+ description: |
+ The standard Zicfilp extension for enforcing forward edge
+ control-flow integrity as ratified in commit 3f8e450 ("merge
+ pull request #227 from ved-rivos/0709") of riscv-cfi
+ github repo.
+
+ - const: zicfiss
+ description: |
+ The standard Zicfiss extension for enforcing backward edge
+ control-flow integrity as ratified in commit 3f8e450 ("merge
+ pull request #227 from ved-rivos/0709") of riscv-cfi
+ github repo.
+
+ - const: zicntr
+ description:
+ The standard Zicntr extension for base counters and timers, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: zicond
+ description:
+ The standard Zicond extension for conditional arithmetic and
+ conditional-select/move operations as ratified in commit 95cf1f9
+ ("Add changes requested by Ved during signoff") of riscv-zicond.
+
+ - const: zicsr
+ description: |
+ The standard Zicsr extension for control and status register
+ instructions, as ratified in the 20191213 version of the
+ unprivileged ISA specification.
+
+ This does not include Chapter 10, "Counters", which documents
+ special case read-only CSRs, that were moved into the Zicntr and
+ Zihpm extensions after the ratification of the 20191213 version of
+ the unprivileged specification.
+
+ - const: zifencei
+ description:
+ The standard Zifencei extension for instruction-fetch fence, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
+ - const: zihintntl
+ description:
+ The standard Zihintntl extension for non-temporal locality hints, as
+ ratified in commit 0dc91f5 ("Zihintntl is ratified") of the
+ riscv-isa-manual.
+
+ - const: zihintpause
+ description:
+ The standard Zihintpause extension for pause hints, as ratified in
+ commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual.
+
+ - const: zihpm
+ description:
+ The standard Zihpm extension for hardware performance counters, as
+ ratified in the 20191213 version of the unprivileged ISA
+ specification.
+
- const: zilsd
description:
The standard Zilsd extension which provides support for aligned
@@ -521,12 +604,10 @@ properties:
encodings, as ratified in commit f88abf1 ("Integrating
load/store pair for RV32 with the main manual") of riscv-isa-manual.
- - const: zclsd
+ - const: zimop
description:
- The Zclsd extension implements the compressed (16-bit) version of the
- Load/Store Pair for RV32. As with Zilsd, this extension was ratified
- in commit f88abf1 ("Integrating load/store pair for RV32 with the
- main manual") of riscv-isa-manual.
+ The standard Zimop extension version 1.0, as ratified in commit
+ 58220614a5f ("Zimop is ratified/1.0") of the riscv-isa-manual.
- const: zk
description:
@@ -590,87 +671,6 @@ properties:
in version 1.0 of RISC-V Cryptography Extensions Volume I
specification.
- - const: zicbom
- description:
- The standard Zicbom extension for base cache management operations as
- ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
-
- - const: zicbop
- description:
- The standard Zicbop extension for cache-block prefetch instructions
- as ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of
- riscv-CMOs.
-
- - const: zicboz
- description:
- The standard Zicboz extension for cache-block zeroing as ratified
- in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
-
- - const: zicfilp
- description: |
- The standard Zicfilp extension for enforcing forward edge
- control-flow integrity as ratified in commit 3f8e450 ("merge
- pull request #227 from ved-rivos/0709") of riscv-cfi
- github repo.
-
- - const: zicfiss
- description: |
- The standard Zicfiss extension for enforcing backward edge
- control-flow integrity as ratified in commit 3f8e450 ("merge
- pull request #227 from ved-rivos/0709") of riscv-cfi
- github repo.
-
- - const: zicntr
- description:
- The standard Zicntr extension for base counters and timers, as
- ratified in the 20191213 version of the unprivileged ISA
- specification.
-
- - const: zicond
- description:
- The standard Zicond extension for conditional arithmetic and
- conditional-select/move operations as ratified in commit 95cf1f9
- ("Add changes requested by Ved during signoff") of riscv-zicond.
-
- - const: zicsr
- description: |
- The standard Zicsr extension for control and status register
- instructions, as ratified in the 20191213 version of the
- unprivileged ISA specification.
-
- This does not include Chapter 10, "Counters", which documents
- special case read-only CSRs, that were moved into the Zicntr and
- Zihpm extensions after the ratification of the 20191213 version of
- the unprivileged specification.
-
- - const: zifencei
- description:
- The standard Zifencei extension for instruction-fetch fence, as
- ratified in the 20191213 version of the unprivileged ISA
- specification.
-
- - const: zihintpause
- description:
- The standard Zihintpause extension for pause hints, as ratified in
- commit d8ab5c7 ("Zihintpause is ratified") of the riscv-isa-manual.
-
- - const: zihintntl
- description:
- The standard Zihintntl extension for non-temporal locality hints, as
- ratified in commit 0dc91f5 ("Zihintntl is ratified") of the
- riscv-isa-manual.
-
- - const: zihpm
- description:
- The standard Zihpm extension for hardware performance counters, as
- ratified in the 20191213 version of the unprivileged ISA
- specification.
-
- - const: zimop
- description:
- The standard Zimop extension version 1.0, as ratified in commit
- 58220614a5f ("Zimop is ratified/1.0") of the riscv-isa-manual.
-
- const: ztso
description:
The standard Ztso extension for total store ordering, as ratified
@@ -809,18 +809,18 @@ properties:
instructions, as ratified in commit 56ed795 ("Update
riscv-crypto-spec-vector.adoc") of riscv-crypto.
- - const: zvksh
- description: |
- The standard Zvksh extension for ShangMi suite: SM3 secure hash
- instructions, as ratified in commit 56ed795 ("Update
- riscv-crypto-spec-vector.adoc") of riscv-crypto.
-
- const: zvksg
description:
The standard Zvksg extension for ShangMi algorithm suite with GCM
instructions, as ratified in commit 56ed795 ("Update
riscv-crypto-spec-vector.adoc") of riscv-crypto.
+ - const: zvksh
+ description: |
+ The standard Zvksh extension for ShangMi suite: SM3 secure hash
+ instructions, as ratified in commit 56ed795 ("Update
+ riscv-crypto-spec-vector.adoc") of riscv-crypto.
+
- const: zvkt
description:
The standard Zvkt extension for vector data-independent execution
--
2.43.0
^ permalink raw reply related
* [PATCH v4 00/16] riscv: hwprobe: Expose RVA23U64 base behavior
From: Guodong Xu @ 2026-06-11 20:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto
Cc: linux-doc, linux-riscv, linux-kernel, kvm, kvm-riscv,
Paul Walmsley, Conor Dooley, devicetree, spacemit, sophgo,
linux-kselftest, Palmer Dabbelt, Guodong Xu, Andrew Jones,
Charlie Jenkins, Charlie Jenkins, Jesse Taube, Conor Dooley,
Qingwei Hu, Andy Chiu
This series builds on Andrew Jones's earlier RFC [1]. It lets userspace
check for RVA23U64 conformance in one call, instead of walking hwprobe +
prctl across every mandatory extension.
The series adds a small framework that resolves profile-class bases (IMA
and RVA23U64) from the kernel's ISA extension bitmap at init time, and
surfaces the result through both /proc/cpuinfo and hwprobe. Later patches
can add RVA23S64, and backward RVA22 / RVA20 detection, to
riscv_set_isa_bases() without changes to the surrounding code.
Series outline (v4):
Housekeeping, clean-ups:
1. dt-bindings: sort the multi-letter Z extensions alphanumerically.
2. hwprobe.rst: normalize indentation.
3. hwprobe.rst: document EXT_ZICFISS / EXT_ZICFILP.
4. Standardize the single-letter extension macros to uppercase
(RISCV_ISA_EXT_a -> RISCV_ISA_EXT_A, etc.).
Per-extension cpufeature parsing + hwprobe export:
5. Zicclsm.
6. Ziccamoa, Ziccif, Ziccrse, Za64rs.
7. B (the Zba/Zbb/Zbs set).
Zic64b (new first-class extension):
8. dt-binding, with a schema check.
9. cpufeature parsing + hwprobe export.
10-12. dts: declare zic64b in the SpacemiT K3, SpacemiT K1, and Sophgo
SG2044 device trees.
RVA23U64 base detection and exposure:
13. riscv_have_user_pmlen(): accessor for user pointer-masking PMLEN
support.
14. cpufeature: per-hart and host-wide isa_bases bitmaps; IMA and
RVA23U64 detection lives here.
15. /proc/cpuinfo: print "isa bases:" and "hart isa bases:", e.g.
rva23u64.
16. hwprobe: expose RVA23U64.
Tested on both K3 Pico ITX and QEMU with -cpu rva23s64,sv39=on:
- /proc/cpuinfo reports "isa bases : rv64ima rva23u64" on both the
aggregated and per-hart lines.
- hwprobe RISCV_HWPROBE_KEY_BASE_BEHAVIOR returns
BASE_BEHAVIOR_IMA | BASE_BEHAVIOR_RVA23U64.
Based on v7.1-rc6 plus [2]; happy to rebase onto another tree if needed.
A branch is available for all patches in the series: [3].
Note: [2] is only required to save the merge effort for adding 'Zic64b'
and 'Ziccrse' into the same k3.dtsi file.
Link: Andrew's RFC v1:
https://lore.kernel.org/linux-riscv/20260206002349.96740-1-andrew.jones@oss.qualcomm.com/ [1]
Link: Prerequisite for applying on K3 w/Ziccrse:
https://lore.kernel.org/all/20260602070257-KYC5031219@kernel.org/ [2]
Link: Branch: https://github.com/docularxu/linux/commits/b4/rva23u64-hwprobe-v4/ [3]
Changes in v4:
- New patch: sort the multi-letter Z extensions alphanumerically in the
dt-binding (Conor), and place zic64b at its sorted position.
- Zic64b cpufeature: validate only the CBO block sizes that are present;
overlaps Qingwei Hu's earlier patch, so it is now authored by Qingwei.
- Document EXT_ZICFISS / EXT_ZICFILP: cite the riscv-cfi v1.0 tag commit.
- Picked up Inochi Amaoto's Acked-by (SG2044 dts) and Andrew Jones's
Reviewed-by (documentation patch).
- Link to v3: https://patch.msgid.link/20260603-rva23u64-hwprobe-v2-v3-0-5529a7b28384@gmail.com
Changes in v3:
- Add Zic64b as a first-class ISA extension: dt-binding, cpufeature
parsing with a validate check, hwprobe export, and device-tree
declarations for K3/K1/SG2044.
- Patch 1 is now a clean up of hwprobe.rst indentation.
- Document RISCV_HWPROBE_EXT_ZICFILP alongside ZICFISS.
- Move the Zicclsm hwprobe.rst entry to the IMA_EXT_1 section to match
its bit allocation.
- Collect Anup Patel's Acked-by/Reviewed-by on Patch 3, the capitalization.
- In cpufeature.c, set the local ext_mask with __set_bit().
- Update Guodong Xu's email to docular.xu@gmail.com.
- Link to v2: https://patch.msgid.link/20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com
Changes in v2 (since Andrew's RFC v1):
- Rebased onto v7.1-rc2.
- Reworked rva23u64 detection into per-hart and host isa_bases bitmaps,
shared by /proc/cpuinfo and hwprobe.
- Scoped to IMA and RVA23U64 (RVA23S64, RVA20/RVA22 cpuinfo output deferred).
- Link to v1: https://lore.kernel.org/linux-riscv/20260206002349.96740-1-andrew.jones@oss.qualcomm.com
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
---
Andrew Jones (4):
riscv: hwprobe.rst: Make indentation consistent
riscv: Add Ziccamoa, Ziccif, Ziccrse, and Za64rs to cpufeature and hwprobe
riscv: Add B to hwcap and hwprobe
riscv: Add a getter for user PMLEN support
Charlie Jenkins (1):
riscv: Standardize extension capitalization
Guodong Xu (9):
dt-bindings: riscv: sort multi-letter Z extensions alphanumerically
riscv: hwprobe.rst: Document EXT_ZICFISS and EXT_ZICFILP
dt-bindings: riscv: Add Zic64b extension description
riscv: dts: spacemit: k3: Add Zic64b ISA extension
riscv: dts: spacemit: k1: Add Zic64b ISA extension
riscv: dts: sophgo: sg2044: Add Zic64b ISA extension
riscv: cpufeature: Introduce ISA bases bitmap and rva23u64 detection
riscv: cpu: Output isa bases lines in cpuinfo
riscv: hwprobe: Introduce rva23u64 base behavior
Jesse Taube (1):
riscv: Add Zicclsm to cpufeature and hwprobe
Qingwei Hu (1):
riscv: Add Zic64b to cpufeature and hwprobe
Documentation/arch/riscv/hwprobe.rst | 240 ++++++++++++---------
.../devicetree/bindings/riscv/extensions.yaml | 204 ++++++++++--------
arch/riscv/boot/dts/sophgo/sg2044-cpus.dtsi | 128 +++++------
arch/riscv/boot/dts/spacemit/k1.dtsi | 80 +++----
arch/riscv/boot/dts/spacemit/k3.dtsi | 48 ++---
arch/riscv/include/asm/cpufeature.h | 14 ++
arch/riscv/include/asm/hwcap.h | 24 ++-
arch/riscv/include/asm/processor.h | 4 +
arch/riscv/include/asm/switch_to.h | 4 +-
arch/riscv/include/uapi/asm/hwcap.h | 1 +
arch/riscv/include/uapi/asm/hwprobe.h | 10 +-
arch/riscv/kernel/cpu.c | 26 +++
arch/riscv/kernel/cpufeature.c | 183 ++++++++++++++--
arch/riscv/kernel/process.c | 12 ++
arch/riscv/kernel/sys_hwprobe.c | 34 ++-
arch/riscv/kvm/isa.c | 16 +-
arch/riscv/kvm/main.c | 2 +-
arch/riscv/kvm/vcpu_fp.c | 20 +-
arch/riscv/kvm/vcpu_onereg.c | 6 +-
arch/riscv/kvm/vcpu_vector.c | 10 +-
tools/testing/selftests/riscv/hwprobe/which-cpus.c | 2 +-
21 files changed, 680 insertions(+), 388 deletions(-)
---
base-commit: 99c201dabc35bbd21252c4c682488209dcb4295e
change-id: 20260508-rva23u64-hwprobe-v2-1d20739cbb8e
Best regards,
--
Guodong Xu <docular.xu@gmail.com>
^ permalink raw reply
* Re: [RFC V2 0/3] lib/vsprintf: Add support for pgtable entries
From: Matthew Wilcox @ 2026-06-11 19:37 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Anshuman Khandual, linux-mm, Rasmus Villemoes, Sergey Senozhatsky,
Petr Mladek, Steven Rostedt, Jonathan Corbet, Andrew Morton,
David Hildenbrand, linux-kernel, linux-doc
In-Reply-To: <aisNjxHW369cbKiq@ashevche-desk.local>
On Thu, Jun 11, 2026 at 10:33:35PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 11, 2026 at 08:15:57PM +0100, Matthew Wilcox wrote:
> > On Wed, Jun 10, 2026 at 05:35:42AM +0100, Anshuman Khandual wrote:
> > > Printing page table entries has been a common requirement both in generic
> > > and platform memory management for various purposes. Hence let's create a
> > > dedicated printk format for such entries which will also help standardize
> > > pgtable printing across different platforms.
> >
> > You didn't address my objection here:
> >
> > https://lore.kernel.org/linux-mm/aFQP8LzVMctf6XH5@casper.infradead.org/
> >
> > ie there is now no typechecking possible. So you've made it more
> > dangerous. I reiterate my NACK to the concept, not to the implementation.
>
> But this is more of a global question, how do we check the validity of
> the parameters of pointer extensions in the kernel? Does anybody go to
> commit into GCC plugin or so for this job?
I agree that it's a global question that it would be great for somebody
to answer. But it's specifically a problem for this patchset because:
- It's really easy to get confused about which page table level you're
working on. And hugetlbfs deliberately increases that confusion.
- Different levels of the page tables actually do have different sizes
on some architectures, so if you think you're looking at a pointer to a
64-bit quantity when it's really a pointer to a 32-bit quantity, things
Will Go Wrong (or vice-versa. And some architctures are big-endian)
- But on x86-64, Everything Is Fine because all levels of the page table
are basically identical, so you'll never notice there's a problem.
^ permalink raw reply
* Re: [RFC V2 0/3] lib/vsprintf: Add support for pgtable entries
From: Andy Shevchenko @ 2026-06-11 19:33 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Anshuman Khandual, linux-mm, Rasmus Villemoes, Sergey Senozhatsky,
Petr Mladek, Steven Rostedt, Jonathan Corbet, Andrew Morton,
David Hildenbrand, linux-kernel, linux-doc
In-Reply-To: <aisJbeVVxxNuYxQ6@casper.infradead.org>
On Thu, Jun 11, 2026 at 08:15:57PM +0100, Matthew Wilcox wrote:
> On Wed, Jun 10, 2026 at 05:35:42AM +0100, Anshuman Khandual wrote:
> > Printing page table entries has been a common requirement both in generic
> > and platform memory management for various purposes. Hence let's create a
> > dedicated printk format for such entries which will also help standardize
> > pgtable printing across different platforms.
>
> You didn't address my objection here:
>
> https://lore.kernel.org/linux-mm/aFQP8LzVMctf6XH5@casper.infradead.org/
>
> ie there is now no typechecking possible. So you've made it more
> dangerous. I reiterate my NACK to the concept, not to the implementation.
But this is more of a global question, how do we check the validity of
the parameters of pointer extensions in the kernel? Does anybody go to
commit into GCC plugin or so for this job?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] Documentation: arch: fix brackets
From: Randy Dunlap @ 2026-06-11 19:31 UTC (permalink / raw)
To: Manuel Ebner, Vineet Gupta, Jonathan Corbet, Shuah Khan,
Krzysztof Kozlowski, Peter Griffin, Alim Akhtar, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy,
open list:SYNOPSYS ARC ARCHITECTURE, open list:DOCUMENTATION,
open list,
moderated list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES,
open list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)
In-Reply-To: <20260611183525.153058-2-manuelebner@mailbox.org>
Hi,
A couple of comments but overall this is a nice cleanup.
On 6/11/26 11:35 AM, Manuel Ebner wrote:
> Add missing and remove needless parentheses, brackets and curly braces.
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> Documentation/arch/arc/arc.rst | 2 +-
> .../arm/samsung/clksrc-change-registers.awk | 2 +-
> Documentation/arch/arm/vlocks.rst | 4 ++--
> .../arch/arm64/memory-tagging-extension.rst | 2 +-
> Documentation/arch/powerpc/vas-api.rst | 2 +-
> Documentation/arch/sparc/oradax/dax-hv-api.txt | 18 +++++++++---------
> Documentation/arch/sparc/oradax/oracle-dax.rst | 3 ++-
> 7 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/arch/arc/arc.rst b/Documentation/arch/arc/arc.rst
> index 6c4d978f3f4e..553851f43be7 100644
> --- a/Documentation/arch/arc/arc.rst
> +++ b/Documentation/arch/arc/arc.rst
> @@ -36,7 +36,7 @@ Important note on ARC processors configurability
>
> ARC processors are highly configurable and several configurable options
> are supported in Linux. Some options are transparent to software
> -(i.e cache geometries, some can be detected at runtime and configured
> +(i.e cache geometries), some can be detected at runtime and configured
(i.e., cache geometries),
or even
(e.g., cache geometries),
> and used accordingly, while some need to be explicitly selected or configured
> in the kernel's configuration utility (AKA "make menuconfig").
>
> diff --git a/Documentation/arch/sparc/oradax/oracle-dax.rst b/Documentation/arch/sparc/oradax/oracle-dax.rst
> index d1e14d572918..67867ea7be40 100644
> --- a/Documentation/arch/sparc/oradax/oracle-dax.rst
> +++ b/Documentation/arch/sparc/oradax/oracle-dax.rst
> @@ -438,7 +438,8 @@ that in user land::
> The output bitmap is ready for consumption immediately after the
> completion status indicates success.
>
> -Excer[t from UltraSPARC Virtual Machine Specification
> +Excer?t from UltraSPARC Virtual Machine Specification
Excerpt
> +i guess this is wrong, but i don't know what's correct
> =====================================================
>
> .. include:: dax-hv-api.txt
and then you can add
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
thanks.
--
~Randy
^ permalink raw reply
* Re: [RFC V2 0/3] lib/vsprintf: Add support for pgtable entries
From: Matthew Wilcox @ 2026-06-11 19:15 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-mm, Andy Shevchenko, Rasmus Villemoes, Sergey Senozhatsky,
Petr Mladek, Steven Rostedt, Jonathan Corbet, Andrew Morton,
David Hildenbrand, linux-kernel, linux-doc
In-Reply-To: <20260610043545.3725735-1-anshuman.khandual@arm.com>
On Wed, Jun 10, 2026 at 05:35:42AM +0100, Anshuman Khandual wrote:
> Printing page table entries has been a common requirement both in generic
> and platform memory management for various purposes. Hence let's create a
> dedicated printk format for such entries which will also help standardize
> pgtable printing across different platforms.
You didn't address my objection here:
https://lore.kernel.org/linux-mm/aFQP8LzVMctf6XH5@casper.infradead.org/
ie there is now no typechecking possible. So you've made it more
dangerous. I reiterate my NACK to the concept, not to the implementation.
^ permalink raw reply
* Re: [PATCH v5 4/4] Documentation: PCI: Add documentation for DOE endpoint support
From: Bjorn Helgaas @ 2026-06-11 19:12 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260610100256.1889111-5-a-garg7@ti.com>
On Wed, Jun 10, 2026 at 03:32:56PM +0530, Aksh Garg wrote:
> Document the architecture and implementation details for the Data Object
> Exchange (DOE) framework for PCIe Endpoint devices.
>
> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> ---
>
> Changes from v4 to v5:
> - Updated the DOE Abort handling setion.
>
> Changes from v3 to v4:
> - Updated the maximum size of the DOE object from 256KB to 1MB,
> as per PCIe spec.
> - Updated the DOE setup and cleanup sections.
>
> Changes from v2 to v3:
> - Rebased on 7.1-rc1.
>
> Changes since v1:
> - Squashed the patches [1] and [2], and moved the documentation file
> to Documentation/PCI/endpoint/pci-endpoint-doe.rst to match the existing
> naming scheme, as suggested by Niklas Cassel
> - Updated the documentation as per the design and implementaion changes
> made to previous patches in this series:
> * Updated for static protocol array instead of dynamic registration
> * Documented asynchronous callback model
> * Updated request/response flow with new callback signature
> * Updated memory ownership: DOE core frees request, driver frees response
> * Updated initialization and cleanup sections for new APIs
>
> v4: https://lore.kernel.org/all/20260522052434.802034-5-a-garg7@ti.com/
> v3: https://lore.kernel.org/all/20260427051725.223704-5-a-garg7@ti.com/
> v2: https://lore.kernel.org/all/20260401073022.215805-5-a-garg7@ti.com/
> v1: [1] https://lore.kernel.org/all/20260213123603.420941-2-a-garg7@ti.com/
> [2] https://lore.kernel.org/all/20260213123603.420941-5-a-garg7@ti.com/
>
> Documentation/PCI/endpoint/index.rst | 1 +
> .../PCI/endpoint/pci-endpoint-doe.rst | 333 ++++++++++++++++++
> 2 files changed, 334 insertions(+)
> create mode 100644 Documentation/PCI/endpoint/pci-endpoint-doe.rst
>
> diff --git a/Documentation/PCI/endpoint/index.rst b/Documentation/PCI/endpoint/index.rst
> index dd1f62e731c9..7c03d5abd2ef 100644
> --- a/Documentation/PCI/endpoint/index.rst
> +++ b/Documentation/PCI/endpoint/index.rst
> @@ -9,6 +9,7 @@ PCI Endpoint Framework
>
> pci-endpoint
> pci-endpoint-cfs
> + pci-endpoint-doe
> pci-test-function
> pci-test-howto
> pci-ntb-function
> diff --git a/Documentation/PCI/endpoint/pci-endpoint-doe.rst b/Documentation/PCI/endpoint/pci-endpoint-doe.rst
> new file mode 100644
> index 000000000000..679844e36493
> --- /dev/null
> +++ b/Documentation/PCI/endpoint/pci-endpoint-doe.rst
> @@ -0,0 +1,333 @@
> +.. SPDX-License-Identifier: GPL-2.0-only OR MIT
> +
> +.. include:: <isonum.txt>
> +
> +=============================================
> +Data Object Exchange (DOE) for PCIe Endpoint
> +=============================================
> +
> +:Copyright: |copy| 2026 Texas Instruments Incorporated
> +:Author: Aksh Garg <a-garg7@ti.com>
> +:Co-Author: Siddharth Vadapalli <s-vadapalli@ti.com>
> +
> +Overview
> +========
> +
> +DOE (Data Object Exchange) is a standard PCIe extended capability feature
> +introduced in the Data Object Exchange (DOE) ECN for PCIe r5.0. It is an optional
Cite spec r7.0 as you do below, not ECN.
Wrap all to fit in 75-78 columns.
> +mechanism for system firmware/software running on root complex (host) to perform
> +:ref:`data object <data-object-term>` exchanges with an endpoint function. Each
> +data object is uniquely identified by the Vendor ID of the vendor publishing the
s/vendor ID/Vendor ID/ throughout, for consistency here and to match spec.
> +data object definition and a Data Object Type value assigned by that vendor.
> +
> +Think of DOE as a sophisticated mailbox system built into PCIe. The root complex
> +can send structured requests to the endpoint device through DOE mailboxes, and
> +the endpoint device responds with appropriate data. DOE mailboxes are implemented
> +as PCIe Extended Capabilities in endpoint devices, allowing multiple mailboxes
> +per function, each potentially supporting different data object protocols.
> +
> +The DOE support for root complex devices has already been implemented in
> +``drivers/pci/doe.c``.
> +
> +How DOE Works
> +=============
> +
> +The DOE mailbox operates through a simple request-response model:
> +
> +1. **Host sends request**: The root complex writes a data object (vendor ID, type,
> + and payload) to the DOE write mailbox register (one DWORD at a time) of the
s/type/Type/
s/payload/Payload/ to match usage below and to indicate that these are
termed defined by the PCIe spec.
> + endpoint function's config space and sets the GO bit in the DOE Control register
s/GO/DOE Go/ throughout to match spec.
> + to indicate that a request is ready for processing.
> +2. **Endpoint processes**: The endpoint function reads the request from DOE write
> + mailbox register, sets the BUSY bit in the DOE Status register, identifies the
> + protocol of the data object, and executes the appropriate handler.
> +3. **Endpoint responds**: The endpoint function writes the response data object to the
> + DOE read mailbox register (one DWORD at a time), and sets the READY bit in the DOE
> + Status register to indicate that the response is ready. If an error occurs during
> + request processing (such as unsupported protocol or handler failure), the endpoint
> + sets the ERROR bit in the DOE Status register instead of the READY bit.
> +4. **Host reads response**: The root complex retrieves the response data from the DOE read
> + mailbox register once the READY bit is set in the DOE Status register, and then writes
> + any value to this register to indicate a successful read. If the ERROR bit was set,
> + the root complex discards the response and performs error handling as needed.
> +
> +Each mailbox operates independently and can handle one transaction at a time. The
> +DOE specification supports data objects of size up to 1MB (2\ :sup:`18` dwords).
> +
> +For complete DOE capability details, refer to `PCI Express Base Specification Revision 7.0,
> +Section 6.30 - Data Object Exchange (DOE)`.
> +
> +Key Terminologies
> +=================
> +
> +.. _data-object-term:
> +
> +**Data Object**
> + A structured, vendor-defined, or standard-defined message exchanged between
> + root complex and endpoint function via DOE capability registers in configuration
> + space of the function.
> +
> +**Mailbox**
> + A DOE capability on the endpoint device, where each physical function can have
> + multiple mailboxes.
> +
> +**Protocol**
> + A specific type of DOE communication data object identified by a Vendor ID and Type.
> +
> +**Handler**
> + A function that processes DOE requests of a specific protocol and generates responses.
> +
> +Architecture of DOE Implementation for Endpoint
> +===============================================
> +
> +.. code-block:: text
> +
> + +------------------+
> + | |
> + | Root Complex |
> + | |
> + +--------^---------+
> + |
> + | Config space access
> + | over PCIe link
> + |
> + +----------v-----------+
> + | |
> + | PCIe Controller |
> + | as Endpoint |
> + | |
> + | +-----------------+ |
> + | | DOE Mailbox | |
> + | +-------^---------+ |
> + +----------|-----------+
> + +-----------|---------------------------------------------------------------+
> + | | +--------------------+ |
> + | +---------v--------+ Allocate | +--------------+ | |
> + | | |-------------------------------->| Request | | |
> + | | EP Controller | +--->| Buffer | | |
> + | | Driver | Free | | +--------------+ | |
> + | | |--------------------------+ | | | |
> + | +--------^---------+ | | | | |
> + | | | | | | |
> + | | | | | | |
> + | | pci_ep_doe_process_request() | | | | |
> + | | | | | | |
> + | +--------v---------+ Free | | | | |
> + | | |----------------------------+ | DDR | |
> + | | DOE EP Core |<----+ | | | |
> + | | (pci-ep-doe.c) | | Discovery | | | |
> + | | |-----+ Protocol Handler | | | |
> + | +--------^---------+ | | | |
> + | | | | | |
> + | | protocol_handler() | | | |
> + | | | | | |
> + | +--------v---------+ | | | |
> + | | | | | +--------------+ | |
> + | | Protocol Handler | +----->| Response | | |
> + | | Module |-------------------------------->| Buffer | | |
> + | | (CMA/SPDM/Other) | Allocate | +--------------+ | |
> + | | | | | |
> + | +------------------+ | | |
> + | +--------------------+ |
> + +---------------------------------------------------------------------------+
> +
> +Initialization and Cleanup
> +--------------------------
> +
> +**Framework Initialization and DOE Setup**
> +
> +The EPC core automatically initializes and sets up DOE mailboxes through the
> +``pci_epc_init_capabilities()`` internal function, which is invoked during
> +``pci_epc_init_notify()`` when the controller driver calls this API.
> +Controller drivers do not need to explicitly handle DOE initialization,
> +rather the EPC core manages this transparently.
> +
> +DOE initialization only occurs when the EPC driver reports DOE capability
> +through the ``doe_capable`` flag in its ``pci_epc_features``.
> +
> +This internal function performs the following steps:
> +
> +1. Calls ``pci_ep_doe_init(epc)`` to initialize the xarray data structure
> + (a resizable array data structure defined in linux) named ``doe_mbs`` that
> + stores metadata of DOE mailboxes for the controller in ``struct pci_epc``.
> +2. Calls ``pci_epc_doe_setup(epc)`` to discover all DOE capabilities in the
> + endpoint function's configuration space for each function. For each
> + discovered DOE capability, calls ``pci_ep_doe_add_mailbox(epc, func_no,
> + cap_offset)`` to register the mailbox.
> +
> +Each DOE mailbox structure created by ``pci_ep_doe_add_mailbox()`` gets an
> +ordered workqueue allocated for processing DOE requests sequentially for that
> +mailbox, enabling concurrent request handling across different mailboxes. Each
> +mailbox is uniquely identified by the combination of physical function number
> +and capability offset for that controller.
> +
> +**Cleanup**
> +
> +The EPC core automatically cleans up DOE mailboxes through the
> +``pci_epc_deinit_capabilities()`` internal function, which is invoked during
> +``pci_epc_deinit_notify()`` when the controller driver calls this API.
> +Controller drivers do not need to explicitly handle DOE cleanup, rather
> +the EPC core manages this transparently.
> +
> +DOE cleanup only occurs when the EPC device reported DOE capability
> +through the ``doe_capable`` flag in its ``pci_epc_features``.
> +
> +This internal function calls ``pci_ep_doe_destroy(epc)``, which destroys all
> +registered mailboxes, cancels any pending tasks, flushes and destroys the
> +workqueues, and frees all memory allocated to the mailboxes.
> +
> +Protocol Handler Support
> +------------------------
> +
> +Protocol implementations (such as CMA, SPDM, or vendor-specific protocols) are
> +supported through a static array of protocol handlers.
> +
> +When a new DOE protocol library is introduced, its handler function is added to
> +the static ``pci_doe_protocols`` array in ``drivers/pci/endpoint/pci-ep-doe.c``.
> +The discovery protocol (VID = 0x0001 (PCI-SIG vendor ID), Type = 0x00 (discovery
> +protocol)) is included in this static array and handled internally by the
> +DOE EP core.
> +
> +Request Handling
> +----------------
> +
> +The complete flow of a DOE request from the root complex to the response:
> +
> +**Step 1: Root Complex → EP Controller Driver**
> +
> +The root complex writes a DOE request (Vendor ID, Type, and Payload) to the
> +DOE write mailbox register in the endpoint function's configuration space and sets
s/write mailbox register/Write Data Mailbox Register/ to match spec.
Specifically, "in the endpoint function's DOE Capability".
> +the GO bit in the DOE Control register, indicating that the request is ready for
> +processing.
> +
> +**Step 2: EP Controller Driver → DOE EP Core**
> +
> +The controller driver reads the request header to determine the data object
> +length. Based on this length field, it allocates a request buffer in memory
> +(DDR) of the appropriate size. The driver then reads the complete request
> +payload from the DOE write mailbox register and converts the data from
> +little-endian format (the format followed in the PCIe transactions over the
> +link) to CPU-native format using ``le32_to_cpu()``. The driver defines a
> +completion callback function with signature ``void (*complete)(struct pci_epc *epc,
> +u8 func_no, u16 cap_offset, int status, u16 vendor, u8 type, void *response_pl,
> +size_t response_pl_sz)`` to be invoked when the request processing completes.
> +The driver then calls ``pci_ep_doe_process_request(epc, func_no, cap_offset,
> +vendor, type, request, request_sz, complete)`` to hand off the request to the
> +DOE EP core. This function returns immediately after queuing the work
> +(without blocking), and the driver sets the BUSY bit in the DOE Status register.
> +
> +**Step 3: DOE EP Core Processing**
> +
> +The DOE EP core creates a task structure and submits it to the mailbox's ordered
> +workqueue. This ensures that requests for each mailbox are processed
> +sequentially, one at a time, as required by the DOE specification. It looks up
> +the protocol handler based on the Vendor ID and Type from the request header,
> +and executes the handler function.
> +
> +**Step 4: Protocol Handler Execution**
> +
> +The workqueue executes the task by calling the registered protocol handler:
> +``handler(request, request_sz, &response, &response_sz)``. The handler processes
> +the request, allocates a response buffer in memory (DDR), builds the response
> +data, and returns the response pointer and size. For the discovery protocol,
> +the DOE EP core handles this directly without invoking an external handler.
> +
> +**Step 5: DOE EP Core → EP Controller Driver**
> +
> +After the protocol handler completes, the DOE EP core frees the request buffer,
> +and invokes the completion callback provided by the controller driver asynchronously.
> +The callback receives the struct pci_epc, function number, capability offset (to
> +identify the mailbox), status code indicating the result of request processing,
> +vendor ID and type of the data object, the response buffer, and its size.
> +
> +**Step 6: EP Controller Driver → Root Complex**
> +
> +The controller driver converts the response from CPU-native format to
> +little-endian format using ``cpu_to_le32()``, writes the response to DOE read
> +mailbox register, and sets the READY bit in the DOE Status register. The root
> +complex then reads the response from the read mailbox register. Finally, the controller
> +driver frees the response buffer (which the handler allocated).
s/READY/Data Object Read/ to match spec
s/read mailbox/DOE Read Data Mailbox/ throughout to match spec
> +Asynchronous Request Processing
> +-------------------------------
> +
> +The DOE-EP framework implements asynchronous request processing because an
> +endpoint function can have multiple instances of DOE mailboxes, and requests may
> +be interleaved across these mailboxes. Request processing of one mailbox should
> +not result in blocking request processing of other mailboxes. Hence, requests
> +on each mailbox need to be handled in parallel for optimization.
> +
> +For the EP controller driver to handle requests on multiple mailboxes in
> +parallel, ``pci_ep_doe_process_request()`` must be asynchronous. The function
> +returns immediately after submitting the request to the mailbox's workqueue,
> +without waiting for the request to complete. A completion callback provided by
> +the controller driver is invoked asynchronously when request processing
> +finishes. This asynchronous design enables concurrent processing of requests
> +across different mailboxes.
> +
> +Abort Handling
> +--------------
> +
> +The DOE specification allows the root complex to abort ongoing DOE operations
> +by setting the ABORT bit in the DOE Control register.
Use spec name for ABORT
> +**Trigger**
> +
> +When the root complex sets the ABORT bit, the EP controller driver detects this
> +condition (typically in an interrupt handler or register polling routine). The
> +action taken depends on the timing of the abort:
> +
> +- **ABORT before request transfer**: If the ABORT bit is set before the root complex
> + transfers the request to the mailbox registers, the controller driver should not
> + call ``pci_ep_doe_abort()`` API.
> +
> +- **ABORT during request transfer**: If the ABORT bit is set while the root complex
> + is still transferring the request to the mailbox registers, the controller driver
> + should discard the request, and should not call ``pci_ep_doe_abort()`` and
> + ``pci_ep_doe_process_request()`` APIs in the respective IRQ handlers.
> +
> +- **ABORT after request submission**: If the ABORT bit is set after the request
> + has been fully received and submitted to the DOE EP core via
> + ``pci_ep_doe_process_request()``, the controller driver must call
> + ``pci_ep_doe_abort(epc, func_no, cap_offset)`` for the affected mailbox to
> + perform abort sequence in the DOE EP core.
> +
> +**Abort Sequence**
> +
> +The abort function sets the CANCEL flag on the mailbox to prevent queued requests
> +from starting. Instead of waiting for the workqueue to flush, it returns immediately.
> +
> +The CANCEL flag gets cleared after invoking the completion callback, allowing the
> +mailbox to accept new requests.
I guess "CANCEL" is a software thing. Using the spec names for the
hardware bits will help distinguish CANCEL, ABORT, ERROR, BUSY, etc.
> +Queued requests that have not started execution will be aborted with an error
> +status. The currently executing request will complete normally, and the controller
> +will reject the response if it arrives after the abort sequence has been triggered.
> +
> +.. note::
> + Independent of when the ABORT bit is triggered, the controller driver must
> + clear the ERROR, BUSY, and READY bits in the DOE Status register after
> + completing the abort operation to reset the mailbox to an idle state.
> +
> +Error Handling
> +--------------
> +
> +Errors can occur during DOE request processing for various reasons, such as
> +unsupported protocols, handler failures, or memory allocation failures.
> +
> +**Error Detection**
> +
> +When an error occurs during DOE request processing, the DOE EP core propagates this error
> +back to the controller driver either through the ``pci_ep_doe_process_request()`` return value,
> +or the status code passed to the completion callback.
> +
> +**Error Response**
> +
> +When the controller driver receives an error code, it sets the ERROR bit in the DOE Status
> +register instead of writing a response to the read mailbox register, and frees the buffers.
> +
> +API Reference
> +=============
> +
> +.. kernel-doc:: drivers/pci/endpoint/pci-ep-doe.c
> + :export:
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v5 3/4] PCI: endpoint: Add support for DOE initialization and setup in EPC core
From: Bjorn Helgaas @ 2026-06-11 19:12 UTC (permalink / raw)
To: Aksh Garg
Cc: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair, linux-arm-kernel, linux-kernel,
s-vadapalli, danishanwar, srk
In-Reply-To: <20260610100256.1889111-4-a-garg7@ti.com>
On Wed, Jun 10, 2026 at 03:32:55PM +0530, Aksh Garg wrote:
> Add pci_epc_init_capabilities() in EPC core driver to initialize and
> setup the capabilities supported by the EPC driver. This calls
> pci_epc_doe_setup() to setup the DOE framework for an endpoint controller,
> which discovers the DOE capabilities (extended capability ID 0x2E), and
> registers each discovered DOE mailbox for all the functions in the
> endpoint controller.
>
> Add pci_epc_deinit_capabilities() in EPC core driver for cleanup of the
> resources used by the capabilities of the EPC driver. This calls
> pci_ep_doe_destroy() to destroy all DOE mailboxes and free associated
> resources.
>
> Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> Signed-off-by: Aksh Garg <a-garg7@ti.com>
> ---
>
> Changes from v4 to v5:
> - Addressed the review comments by Sashiko
>
> Changes from v3 to v4:
> - Call DOE setup and destroy APIs directly within the EPC core, instead of
> relying on the EPC drivers to call them individually. EPC drivers do not
> need to explicitly handle DOE setup, rather the EPC core manages this
> transparently. (Suggested by Manivannan Sadhasivam).
> - Removed pci_epc_doe_destroy() API, which was just calling pci_ep_doe_destroy().
> Instead, called pci_ep_doe_destroy() directly during cleanup.
> - Called pci_ep_doe_init() before the "!epc->ops->find_ext_capability" check,
> because if doe-capable=1 and find_ext_capability() op is undefined, this
> would not initialize the epc->doe_mbs xarray. However during cleanup, the
> check "!epc->ops->find_ext_capability" would be unnecessary, and it will
> try to destroy the epc->doe_mbs xarray even when it was not initialized.
>
> Changes from v2 to v3:
> - Rebased on 7.1-rc1.
>
> Changes since v1:
> - New patch added to v2 (not present in v1)
>
> v4: https://lore.kernel.org/all/20260522052434.802034-4-a-garg7@ti.com/
> v3: https://lore.kernel.org/all/20260427051725.223704-4-a-garg7@ti.com/
> v2: https://lore.kernel.org/all/20260401073022.215805-4-a-garg7@ti.com/
>
> This patch is introduced based on the feedback provided by Manivannan
> Sadhasivam at [1].
>
> [1]: https://lore.kernel.org/all/p57x6jleaim5w7t2k3v7tioujnaxuovfpj5euop5ogefvw23se@y5fw3che5p5d/
>
>
> drivers/pci/endpoint/pci-epc-core.c | 104 ++++++++++++++++++++++++++++
> include/linux/pci-epc.h | 6 ++
> 2 files changed, 110 insertions(+)
>
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 6c3c58185fc5..e48f40eeed29 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -14,6 +14,8 @@
> #include <linux/pci-epf.h>
> #include <linux/pci-ep-cfs.h>
>
> +#include "../pci.h"
> +
> static const struct class pci_epc_class = {
> .name = "pci_epc",
> };
> @@ -842,6 +844,81 @@ void pci_epc_linkdown(struct pci_epc *epc)
> }
> EXPORT_SYMBOL_GPL(pci_epc_linkdown);
>
> +/**
> + * pci_epc_doe_setup() - Discover and setup DOE mailboxes for all functions
> + * @epc: the EPC device on which DOE mailboxes has to be setup
> + *
> + * Discover DOE (Data Object Exchange) capabilities for all physical functions
> + * in the endpoint controller and register DOE mailboxes.
> + *
> + * Returns: 0 on success, -errno on failure
> + */
> +static int pci_epc_doe_setup(struct pci_epc *epc)
> +{
> + u8 func_no, vfunc_no = 0;
> + u16 cap_offset;
> + int ret;
> +
> + if (!epc->ops || !epc->ops->find_ext_capability)
> + return -EINVAL;
I don't see anything that sets pci_epc_ops.find_ext_capability in this
series, so this looks currently unused and untestable, so likely not
mergeable as-is. What's the plan for users of this?
> + /* Discover DOE capabilities for all functions */
> + for (func_no = 0; func_no < epc->max_functions; func_no++) {
> + mutex_lock(&epc->lock);
> + cap_offset = epc->ops->find_ext_capability(epc, func_no,
> + vfunc_no, 0,
> + PCI_EXT_CAP_ID_DOE);
> + mutex_unlock(&epc->lock);
> +
> + while (cap_offset) {
> + /* Register this DOE mailbox */
> + ret = pci_ep_doe_add_mailbox(epc, func_no, cap_offset);
> + if (ret) {
> + dev_warn(&epc->dev,
> + "[pf%d:offset %x] failed to add DOE mailbox\n",
> + func_no, cap_offset);
> + }
> +
> + mutex_lock(&epc->lock);
> + cap_offset = epc->ops->find_ext_capability(epc, func_no,
> + vfunc_no, cap_offset,
> + PCI_EXT_CAP_ID_DOE);
> + mutex_unlock(&epc->lock);
> + }
> + }
> +
> + dev_dbg(&epc->dev, "DOE mailboxes setup complete\n");
> + return 0;
> +}
> +
> +/**
> + * pci_epc_init_capabilities() - Initialize EPC capabilities
> + * @epc: the EPC device whose capabilities need to be initialized
> + *
> + * Invoke to initialize capabilities supported by the EPC device.
s/Invoke to initialize/Initialize/
> + */
> +static void pci_epc_init_capabilities(struct pci_epc *epc)
> +{
> + const struct pci_epc_features *epc_features;
> + int ret;
> +
> + epc_features = pci_epc_get_features(epc, 0, 0);
> + if (!epc_features)
> + return;
> +
> + if (IS_ENABLED(CONFIG_PCI_ENDPOINT_DOE) && epc_features->doe_capable) {
> + ret = pci_ep_doe_init(epc);
> + if (ret) {
> + dev_warn(&epc->dev, "DOE initialization failed: %d\n", ret);
> + return;
> + }
> +
> + ret = pci_epc_doe_setup(epc);
> + if (ret)
> + dev_warn(&epc->dev, "DOE setup failed: %d\n", ret);
> + }
> +}
> +
> /**
> * pci_epc_init_notify() - Notify the EPF device that EPC device initialization
> * is completed.
> @@ -857,6 +934,9 @@ void pci_epc_init_notify(struct pci_epc *epc)
> if (IS_ERR_OR_NULL(epc))
> return;
>
> + if (!epc->init_complete)
> + pci_epc_init_capabilities(epc);
> +
> mutex_lock(&epc->list_lock);
> list_for_each_entry(epf, &epc->pci_epf, list) {
> mutex_lock(&epf->lock);
> @@ -890,6 +970,27 @@ void pci_epc_notify_pending_init(struct pci_epc *epc, struct pci_epf *epf)
> }
> EXPORT_SYMBOL_GPL(pci_epc_notify_pending_init);
>
> +/**
> + * pci_epc_deinit_capabilities() - Cleanup EPC capabilities
> + * @epc: the EPC device whose capabilities need to be cleaned up
> + *
> + * Invoke to cleanup capabilities supported by the EPC device,
> + * and free the associated resources.
s/Invoke to cleanup/Clean up/
> + */
> +static void pci_epc_deinit_capabilities(struct pci_epc *epc)
> +{
> + const struct pci_epc_features *epc_features;
> +
> + epc_features = pci_epc_get_features(epc, 0, 0);
> + if (!epc_features)
> + return;
> +
> + if (IS_ENABLED(CONFIG_PCI_ENDPOINT_DOE) && epc_features->doe_capable) {
> + pci_ep_doe_destroy(epc);
> + dev_dbg(&epc->dev, "DOE mailboxes destroyed\n");
> + }
> +}
> +
> /**
> * pci_epc_deinit_notify() - Notify the EPF device about EPC deinitialization
> * @epc: the EPC device whose deinitialization is completed
> @@ -903,6 +1004,9 @@ void pci_epc_deinit_notify(struct pci_epc *epc)
> if (IS_ERR_OR_NULL(epc))
> return;
>
> + if (epc->init_complete)
> + pci_epc_deinit_capabilities(epc);
> +
> mutex_lock(&epc->list_lock);
> list_for_each_entry(epf, &epc->pci_epf, list) {
> mutex_lock(&epf->lock);
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index dd26294c8175..11474e337db3 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -84,6 +84,8 @@ struct pci_epc_map {
> * @start: ops to start the PCI link
> * @stop: ops to stop the PCI link
> * @get_features: ops to get the features supported by the EPC
> + * @find_ext_capability: ops to find extended capability offset for a function
> + * in endpoint controller
> * @owner: the module owner containing the ops
> */
> struct pci_epc_ops {
> @@ -115,6 +117,8 @@ struct pci_epc_ops {
> void (*stop)(struct pci_epc *epc);
> const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
> u8 func_no, u8 vfunc_no);
> + u16 (*find_ext_capability)(struct pci_epc *epc, u8 func_no,
> + u8 vfunc_no, u16 start, u8 cap);
> struct module *owner;
> };
>
> @@ -270,6 +274,7 @@ struct pci_epc_bar_desc {
> * @msi_capable: indicate if the endpoint function has MSI capability
> * @msix_capable: indicate if the endpoint function has MSI-X capability
> * @intx_capable: indicate if the endpoint can raise INTx interrupts
> + * @doe_capable: indicate if the endpoint function has DOE capability
> * @bar: array specifying the hardware description for each BAR
> * @align: alignment size required for BAR buffer allocation
> */
> @@ -280,6 +285,7 @@ struct pci_epc_features {
> unsigned int msi_capable : 1;
> unsigned int msix_capable : 1;
> unsigned int intx_capable : 1;
> + unsigned int doe_capable : 1;
> struct pci_epc_bar_desc bar[PCI_STD_NUM_BARS];
> size_t align;
> };
> --
> 2.34.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox