From e80bf12a6997884227d364876e73ba900c8b0de9 Mon Sep 17 00:00:00 2001 From: Falcon Date: Sun, 12 Feb 2023 14:59:30 +0800 Subject: [PATCH] news: fix up typo of RISC-v Signed-off-by: Falcon --- news/README.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/news/README.md b/news/README.md index e1be1a9..68550db 100644 --- a/news/README.md +++ b/news/README.md @@ -10,7 +10,7 @@ #### RISC-V ζžΆζž„ζ”―ζŒ -* [v1: RISC-v: add a spin_shadow_stack declaration](http://lore.kernel.org/linux-riscv/20230210185945.915806-1-conor@kernel.org/) +* [v1: RISC-V: add a spin_shadow_stack declaration](http://lore.kernel.org/linux-riscv/20230210185945.915806-1-conor@kernel.org/) The patchwork automation reported a sparse complaint that spin_shadow_stack was not declared and should be static: @@ -36,7 +36,7 @@ a functioning driver that's higher priority, but let's just be safe and ban it from probing at all. -* [v4: RISC-v: Apply Zicboz to clear_page](http://lore.kernel.org/linux-riscv/20230209152628.129914-1-ajones@ventanamicro.com/) +* [v4: RISC-V: Apply Zicboz to clear_page](http://lore.kernel.org/linux-riscv/20230209152628.129914-1-ajones@ventanamicro.com/) When the Zicboz extension is available we can more rapidly zero naturally aligned Zicboz block sized chunks of memory. As pages are always page @@ -86,7 +86,7 @@ The KVM implementation exposes the virtual counters to the guest and internally manage the counters using kernel perf counters. -* [v1: RISC-v: support some cryptography accelerations](http://lore.kernel.org/linux-riscv/20230206225846.1381789-1-heiko@sntech.de/) +* [v1: RISC-V: support some cryptography accelerations](http://lore.kernel.org/linux-riscv/20230206225846.1381789-1-heiko@sntech.de/) So this was my playground the last days. @@ -877,14 +877,14 @@ As described in patch 2, our current kasan implementation is intricate, so I tried to simplify the implementation and mimic what arm64/x86 are doing. -* [v1: Documentation: RISC-v: Define Xlinuxs{s,m}aia](http://lore.kernel.org/linux-riscv/20230203001201.14770-1-palmer@rivosinc.com/) +* [v1: Documentation: RISC-V: Define Xlinuxs{s,m}aia](http://lore.kernel.org/linux-riscv/20230203001201.14770-1-palmer@rivosinc.com/) The AIA specification was only partially frozen, but provides no way to refer to the subset of behavior that has been frozen. It seems like there's not a whole lot of interest in the non-frozen behavior, so let's just define an extension that only consists of the frozen behavior -* [v1: RISC-v: Only provide the single-letter extensions in HWCAP](http://lore.kernel.org/linux-riscv/20230202233832.11036-1-palmer@rivosinc.com/) +* [v1: RISC-V: Only provide the single-letter extensions in HWCAP](http://lore.kernel.org/linux-riscv/20230202233832.11036-1-palmer@rivosinc.com/) The recent refactoring led to us leaking some HWCAP bits to userspace that didn't make much sense. With any luck we'll have a better scheme @@ -938,7 +938,7 @@ Supporting external interrupt controllers is in progress and hence it is tested using polling based HVC SBI console and RAM disk. -* [v3: RISC-v: Apply Zicboz to clear_page](http://lore.kernel.org/linux-riscv/20230130120128.1349464-1-ajones@ventanamicro.com/) +* [v3: RISC-V: Apply Zicboz to clear_page](http://lore.kernel.org/linux-riscv/20230130120128.1349464-1-ajones@ventanamicro.com/) When the Zicboz extension is available we can more rapidly zero naturally aligned Zicboz block sized chunks of memory. As pages are always page @@ -1864,7 +1864,7 @@ The KVM implementation exposes the virtual counters to the guest and internally manage the counters using kernel perf counters. -* [v2: RISC-v: KVM: Redirect illegal instruction traps to guest](http://lore.kernel.org/linux-riscv/20230127112934.2749592-1-apatel@ventanamicro.com/) +* [v2: RISC-V: KVM: Redirect illegal instruction traps to guest](http://lore.kernel.org/linux-riscv/20230127112934.2749592-1-apatel@ventanamicro.com/) The M-mode redirects an unhandled illegal instruction trap back to S-mode. However, KVM running in HS-mode terminates the VS-mode @@ -1994,7 +1994,7 @@ works with ACPI too since the efi stub creates a device tree anyway with the command line. -* [v2: RISC-v: Apply Zicboz to clear_page](http://lore.kernel.org/linux-riscv/20230122191328.1193885-1-ajones@ventanamicro.com/) +* [v2: RISC-V: Apply Zicboz to clear_page](http://lore.kernel.org/linux-riscv/20230122191328.1193885-1-ajones@ventanamicro.com/) When the Zicboz extension is available we can more rapidly zero naturally aligned Zicboz block sized chunks of memory. As pages are always page @@ -3306,11 +3306,11 @@ extensions. The last approach of using an inline base function to hold the alternative calls did cause some issues in a number of places -* [v1: RISC-v: move some stray __RISCV_INSN_FUNCS definitions from kprobes](http://lore.kernel.org/linux-riscv/20230113211955.3534431-1-heiko@sntech.de/) +* [v1: RISC-V: move some stray __RISCV_INSN_FUNCS definitions from kprobes](http://lore.kernel.org/linux-riscv/20230113211955.3534431-1-heiko@sntech.de/) The __RISCV_INSN_FUNCS originally declared riscv_insn_is_* functions inside the kprobes implementation. This got moved into a central header in - commit ec5f90877516 ("RISC-v: Move riscv_insn_is_* macros into a common header"). + commit ec5f90877516 ("RISC-V: Move riscv_insn_is_* macros into a common header"). Though it looks like I overlooked two of them, so fix that. FENCE itself is an instruction defined directly by its own opcode, while the created @@ -4362,7 +4362,7 @@ Correct the decoding by changing the mask from 0xf007 to 0xf07f. -* [v1: RISC-v: define RUNTIME_DISCARD_EXIT](http://lore.kernel.org/linux-riscv/20230102124936.1363533-1-conor@kernel.org/) +* [v1: RISC-V: define RUNTIME_DISCARD_EXIT](http://lore.kernel.org/linux-riscv/20230102124936.1363533-1-conor@kernel.org/) Masahiro noted: > arch/riscv/kernel/vmlinux.lds.S clearly says: -- Gitee