- 19 Apr, 2023 8 commits
-
-
Palmer Dabbelt authored
Alexandre Ghiti <alexghiti@rivosinc.com> says: This patchset intends to improve tlb utilization by using hugepages for the linear mapping. As reported by Anup in v6, when STRICT_KERNEL_RWX is enabled, we must take care of isolating the kernel text and rodata so that they are not mapped with a PUD mapping which would then assign wrong permissions to the whole region: it is achieved the same way as arm64 by using the memblock nomap API which isolates those regions and re-merge them afterwards thus avoiding any issue with the system resources tree creation. arch/riscv/include/asm/page.h | 19 ++++++- arch/riscv/mm/init.c | 102 ++++++++++++++++++++++++++-------- arch/riscv/mm/physaddr.c | 16 ++++++ drivers/of/fdt.c | 11 ++-- 4 files changed, 118 insertions(+), 30 deletions(-) * b4-shazam-merge: riscv: Use PUD/P4D/PGD pages for the linear mapping riscv: Move the linear mapping creation in its own function riscv: Get rid of riscv_pfn_base variable Link: https://lore.kernel.org/r/20230324155421.271544-1-alexghiti@rivosinc.comSigned-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
Alexandre Ghiti authored
During the early page table creation, we used to set the mapping for PAGE_OFFSET to the kernel load address: but the kernel load address is always offseted by PMD_SIZE which makes it impossible to use PUD/P4D/PGD pages as this physical address is not aligned on PUD/P4D/PGD size (whereas PAGE_OFFSET is). But actually we don't have to establish this mapping (ie set va_pa_offset) that early in the boot process because: - first, setup_vm installs a temporary kernel mapping and among other things, discovers the system memory, - then, setup_vm_final creates the final kernel mapping and takes advantage of the discovered system memory to create the linear mapping. During the first phase, we don't know the start of the system memory and then until the second phase is finished, we can't use the linear mapping at all and phys_to_virt/virt_to_phys translations must not be used because it would result in a different translation from the 'real' one once the final mapping is installed. So here we simply delay the initialization of va_pa_offset to after the system memory discovery. But to make sure noone uses the linear mapping before, we add some guard in the DEBUG_VIRTUAL config. Finally we can use PUD/P4D/PGD hugepages when possible, which will result in a better TLB utilization. Note that: - this does not apply to rv32 as the kernel mapping lies in the linear mapping. - we rely on the firmware to protect itself using PMP. Signed-off-by:
Alexandre Ghiti <alexghiti@rivosinc.com> Acked-by: Rob Herring <robh@kernel.org> # DT bits Reviewed-by:
Andrew Jones <ajones@ventanamicro.com> Reviewed-by:
Anup Patel <anup@brainfault.org> Tested-by:
-
Alexandre Ghiti authored
No change intended, it just splits the linear mapping creation from setup_vm_final: this prepares for upcoming additions to the linear mapping creation. Signed-off-by:
-
Alexandre Ghiti authored
Use directly phys_ram_base instead, riscv_pfn_base is just the pfn of the address contained in phys_ram_base. Even if there is no functional change intended in this patch, actually setting phys_ram_base that early changes the behaviour of kernel_mapping_pa_to_va during the early boot: phys_ram_base used to be zero before this patch and now it is set to the physical start address of the kernel. But it does not break the conversion of a kernel physical address into a virtual address since kernel_mapping_pa_to_va should only be used on kernel physical addresses, i.e. addresses greater than the physical start address of the kernel. Signed-off-by:
-
Conor Dooley authored
Other extensions only capitalise the first letter in the text visible in Kconfig menus, and provide a short comment about the extension's meaning. Do the same for Svnapot & Svpbmt. The precedent for capitalisation in the Kconfig text was set by Zicbom & sorta followed for Zicboz. The RVI styling used for multi-letter extensions only capitalises the first letter, so do the same here. If nothing else, my OCD likes it when the extensions follow a consistent pattern. While editing one of the lines, reformat the "spelling" of 64-bit. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
-
Song Shuai authored
RISC-V now builds the sched domain based on the simple possible map. Enable SCHED_MC to make the building based on cpu_coregroup_mask() which also takes care of the NUMA and cores with LLC. Signed-off-by:
Song Shuai <suagrfillet@gmail.com> Acked-by:
-
Song Shuai authored
RISC-V now manages CPU topology using arch_topology which provides CPU capacity and frequency related interfaces to access the cpu/freq invariant in possible heterogeneous or DVFS-enabled platforms. Here adds topology.h file to export the arch_topology interfaces for replacing the scheduler's constant-based cpu/freq invariant accounting. Signed-off-by:
Ley Foon Tan <lftan@kernel.org> Reviewed-by:
-
Palmer Dabbelt authored
Evan Green <evan@rivosinc.com> says: There's been a bunch of off-list discussions about this, including at Plumbers. The original plan was to do something involving providing an ISA string to userspace, but ISA strings just aren't sufficient for a stable ABI any more: in order to parse an ISA string users need the version of the specifications that the string is written to, the version of each extension (sometimes at a finer granularity than the RISC-V releases/versions encode), and the expected use case for the ISA string (ie, is it a U-mode or M-mode string). That's a lot of complexity to try and keep ABI compatible and it's probably going to continue to grow, as even if there's no more complexity in the specifications we'll have to deal with the various ISA string parsing oddities that end up all over userspace. Instead this patch set takes a very different approach and provides a set of key/value pairs that encode various bits about the system. The big advantage here is that we can clearly define what these mean so we can ensure ABI stability, but it also allows us to encode information that's unlikely to ever appear in an ISA string (see the misaligned access performance, for example). The resulting interface looks a lot like what arm64 and x86 do, and will hopefully fit well into something like ACPI in the future. The actual user interface is a syscall, with a vDSO function in front of it. The vDSO function can answer some queries without a syscall at all, and falls back to the syscall for cases it doesn't have answers to. Currently we prepopulate it with an array of answers for all keys and a CPU set of "all CPUs". This can be adjusted as necessary to provide fast answers to the most common queries. An example series in glibc exposing this syscall and using it in an ifunc selector for memcpy can be found at [1]. I was asked about the performance delta between this and something like sysfs. I created a small test program and ran it on a Nezha D1 Allwinner board. Doing each operation 100000 times and dividing, these operations take the following amount of time: - open()+read()+close() of /sys/kernel/cpu_byteorder: 3.8us - access("/sys/kernel/cpu_byteorder", R_OK): 1.3us - riscv_hwprobe() vDSO and syscall: .0094us - riscv_hwprobe() vDSO with no syscall: 0.0091us These numbers get farther apart if we query multiple keys, as sysfs will scale linearly with the number of keys, where the dedicated syscall stays the same. To frame these numbers, I also did a tight fork/exec/wait loop, which I measured as 4.8ms. So doing 4 open/read/close operations is a delta of about 0.3%, versus a single vDSO call is a delta of essentially zero. [1] https://patchwork.ozlabs.org/project/glibc/list/?series=343050 * b4-shazam-merge: RISC-V: Add hwprobe vDSO function and data selftests: Test the new RISC-V hwprobe interface RISC-V: hwprobe: Support probing of misaligned access performance RISC-V: hwprobe: Add support for RISCV_HWPROBE_BASE_BEHAVIOR_IMA RISC-V: Add a syscall for HW probing RISC-V: Move struct riscv_cpuinfo to new header Link: https://lore.kernel.org/r/20230407231103.2622178-1-evan@rivosinc.comSigned-off-by:
-
- 18 Apr, 2023 6 commits
-
-
Evan Green authored
Add a vDSO function __vdso_riscv_hwprobe, which can sit in front of the riscv_hwprobe syscall and answer common queries. We stash a copy of static answers for the "all CPUs" case in the vDSO data page. This data is private to the vDSO, so we can decide later to change what's stored there or under what conditions we defer to the syscall. Currently all data can be discovered at boot, so the vDSO function answers all queries when the cpumask is set to the "all CPUs" hint. There's also a boolean in the data that lets the vDSO function know that all CPUs are the same. In that case, the vDSO will also answer queries for arbitrary CPU masks in addition to the "all CPUs" hint. Signed-off-by:
Evan Green <evan@rivosinc.com> Link: https://lore.kernel.org/r/20230407231103.2622178-7-evan@rivosinc.comSigned-off-by:
-
Evan Green authored
This adds a test for the recently added RISC-V interface for probing hardware capabilities. It happens to be the first selftest we have for RISC-V, so I've added some infrastructure for those as well. Co-developed-by:
-
Evan Green authored
This allows userspace to select various routines to use based on the performance of misaligned access on the target hardware. Rather than adding DT bindings, this change taps into the alternatives mechanism used to probe CPU errata. Add a new function pointer alongside the vendor-specific errata_patch_func() that probes for desirable errata (otherwise known as "features"). Unlike the errata_patch_func(), this function is called on each CPU as it comes up, so it can save feature information per-CPU. The T-head C906 has fast unaligned access, both as defined by GCC [1], and in performing a basic benchmark, which determined that byte copies are >50% slower than a misaligned word copy of the same data size (source for this test at [2]): bytecopy size f000 count 50000 offset 0 took 31664899 us wordcopy size f000 count 50000 offset 0 took 5180919 us wordcopy size f000 count 50000 offset 1 took 13416949 us [1] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/riscv/riscv.cc#L353 [2] https://pastebin.com/EPXvDHSWCo-developed-by:
Heiko Stuebner <heiko.stuebner@vrull.eu> Tested-by:
Paul Walmsley <paul.walmsley@sifive.com> Link: https://lore.kernel.org/r/20230407231103.2622178-5-evan@rivosinc.comSigned-off-by:
-
Evan Green authored
We have an implicit set of base behaviors that userspace depends on, which are mostly defined in various ISA specifications. Co-developed-by:
-
Evan Green authored
We don't have enough space for these all in ELF_HWCAP{,2} and there's no system call that quite does this, so let's just provide an arch-specific one to probe for hardware capabilities. This currently just provides m{arch,imp,vendor}id, but with the key-value pairs we can pass more in the future. Co-developed-by: -
Evan Green authored
In preparation for tracking and exposing microarchitectural details to userspace (like whether or not unaligned accesses are fast), move the riscv_cpuinfo struct out to its own new cpufeatures.h header. It will need to be used by more than just cpu.c. Signed-off-by:
-
- 11 Apr, 2023 2 commits
-
-
Song Shuai authored
This reverts commit baf7cbd9. There are some duplicate cache attributes populations executed in both ci_leaf_init() and later cache_setup_properties(). Revert the commit baf7cbd9 ("riscv: Set more data to cacheinfo") to setup only the level and type attributes at this early place. Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Acked-by:
-
Björn Töpel authored
The RISC-V calling convention passes the first argument, and the return value in the a0 register. For this reason, the a0 register needs some extra care; When handling syscalls, the a0 register is saved into regs->orig_a0, so a0 can be properly restored for, e.g. interrupted syscalls. This functionality was broken with the introduction of the generic entry patches. Here, a0 was saved into orig_a0 after calling syscall_enter_from_user_mode(), which can change regs->a0 for some paths, incorrectly restoring a0. This is resolved, by saving a0 prior doing the syscall_enter_from_user_mode() call. Fixes: f0bddf50 ("riscv: entry: Convert to generic entry") Reviewed-by:
Björn Töpel <bjorn@rivosinc.com> Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Tested-by:
Andy Chiu <andy.chiu@sifive.com> Link: https://lore.kernel.org/r/20230403065207.1070974-1-bjorn@kernel.orgSigned-off-by:
-
- 29 Mar, 2023 4 commits
-
-
Conor Dooley authored
for-next contains two additional extensions that select RISCV_ALTERNATIVE. RISCV_ALTERNATIVE no longer needs to be selected by individual config options as it is now selected for !XIP_KERNEL builds by the top level RISCV option. These extensions rely on the alternative framework, so convert the "select"s to "depends on"s instead. Signed-off-by:
-
Palmer Dabbelt authored
Conor Dooley <conor.dooley@microchip.com> says: Here's my attempt at fixing both the use of an FPU on XIP kernels and the issue that Jason ran into where CONFIG_FPU, which needs the alternatives frame work for has_fpu() checks, could be enabled without the alternatives actually being present. For the former, a "slow" fallback that does not use alternatives is added to riscv_has_extension_[un]likely() that can be used with XIP. Obviously, we want to make use of Jisheng's alternatives based approach where possible, so any users of riscv_has_extension_[un]likely() will want to make sure that they select RISCV_ALTERNATIVE. If they don't however, they'll hit the fallback path which (should, sparing a silly mistake from me!) behave in the same way, thus succeeding silently. Sounds like a To prevent "depends on !XIP_KERNEL; select RISCV_ALTERNATIVE" spreading like the plague through the various places that want to check for the presence of extensions, and sidestep the potential silent "success" mentioned above, all users RISCV_ALTERNATIVE are converted from selects to dependencies, with the option being selected for all !XIP_KERNEL builds. I know that the VDSO was a key place that Jisheng wanted to use the new helper rather than static branches, and I think the fallback path should not cause issues there. See the thread at [1] for the prior discussion. 1 - https://lore.kernel.org/linux-riscv/20230128172856.3814-1-jszhang@kernel.org/T/#m21390d570997145d31dd8bb95002fd61f99c6573 [Palmer: these were also merged into fixes, but there's a cleanup that depends on the merge so I'm taking it into for-next as well.] * b4-shazam-merge: RISC-V: always select RISCV_ALTERNATIVE for non-xip kernels RISC-V: add non-alternative fallback for riscv_has_extension_[un]likely() Link: https://lore.kernel.org/r/20230324100538.3514663-1-conor.dooley@microchip.comSigned-off-by:
-
Conor Dooley authored
When moving switch_to's has_fpu() over to using riscv_has_extension_likely() rather than static branches, the FPU code gained a dependency on the alternatives framework. That dependency has now been removed, as riscv_has_extension_ikely() now contains a fallback path, using __riscv_isa_extension_available(), but if CONFIG_RISCV_ALTERNATIVE isn't selected when CONFIG_FPU is, has_fpu() checks will not benefit from the "fast path" that the alternatives framework provides. We want to ensure that alternatives are available whenever riscv_has_extension_[un]likely() is used, rather than silently falling back to the slow path, but rather than rely on selecting RISCV_ALTERNATIVE in the myriad of locations that may use riscv_has_extension_[un]likely(), select it (almost) always instead by adding it to the main RISCV config entry. xip kernels cannot make use of the alternatives framework, so it is not enabled for those configurations, although this is the status quo. All current sites that select RISCV_ALTERNATIVE are converted to dependencies on the option instead. The explicit dependencies on !XIP_KERNEL can be dropped, as RISCV_ALTERNATIVE is not user selectable. Fixes: 702e6455 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()") Link: https://lore.kernel.org/all/ZBruFRwt3rUVngPu@zx2c4.com/Reported-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Conor Dooley authored
The has_fpu() check, which in turn calls riscv_has_extension_likely(), relies on alternatives to figure out whether the system has an FPU. As a result, it will malfunction on XIP kernels, as they do not support the alternatives mechanism. When alternatives support is not present, fall back to using __riscv_isa_extension_available() in riscv_has_extension_[un]likely() instead stead, which handily takes the same argument, so that kernels that do not support alternatives can accurately report the presence of FPU support. Fixes: 702e6455 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()") Link: https://lore.kernel.org/all/ad445951-3d13-4644-94d9-e0989cda39c3@spud/Signed-off-by:
-
- 27 Mar, 2023 3 commits
-
-
Palmer Dabbelt authored
Jesse Taube <mr.bossman075@gmail.com> says: This patch-set aims to add NOMMU support to RV32. Many people want to build simple emulators or HDL models of RISC-V this patch makes it possible to run linux on them. Yimin Gu is the original author of this set. Submitted here: https://lists.buildroot.org/pipermail/buildroot/2022-November/656134.html Though Jesse T rewrote the Dconf. * b4-shazam-merge: riscv: configs: Add nommu PHONY defconfig for RV32 riscv: Kconfig: Allow RV32 to build with no MMU Link: https://lore.kernel.org/r/20230301002657.352637-1-Mr.Bossman075@gmail.comSigned-off-by:
-
Jesse Taube authored
32bit risc-v can be configured to run without MMU. Introduce rv32_nommu_virt_defconfig .PHONY target, that is based on nommu_virt_defconfig. This is similar to how rv32_defconfig is based on "defconfig". Suggested-by:
Conor Dooley <conor@kernel.org> Signed-off-by:
Jesse Taube <Mr.Bossman075@gmail.com> Cc: Yimin Gu <ustcymgu@gmail.com> Reviewed-by:
-
Yimin Gu authored
Some RISC-V 32bit cores do not have an MMU, and the kernel should be able to build for them. This patch enables the RV32 to be built with no MMU support. Signed-off-by:
Yimin Gu <ustcymgu@gmail.com> CC: Jesse Taube <Mr.Bossman075@gmail.com> Tested-by:
Waldemar Brodkorb <wbx@openadk.org> Signed-off-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by:
-
- 24 Mar, 2023 1 commit
-
-
Palmer Dabbelt authored
guoren@kernel.org <guoren@kernel.org> says: From: Guo Ren <guoren@linux.alibaba.com> The patches convert riscv to use the generic entry infrastructure from kernel/entry/*. Some optimization for entry.S with new .macro and merge ret_from_kernel_thread into ret_from_fork. * b4-shazam-merge: riscv: entry: Consolidate general regs saving/restoring riscv: entry: Consolidate ret_from_kernel_thread into ret_from_fork riscv: entry: Remove extra level wrappers of trace_hardirqs_{on,off} riscv: entry: Convert to generic entry riscv: entry: Add noinstr to prevent instrumentation inserted riscv: ptrace: Remove duplicate operation Link: https://lore.kernel.org/r/20230222033021.983168-1-guoren@kernel.orgSigned-off-by:
-
- 23 Mar, 2023 6 commits
-
-
Jisheng Zhang authored
Consolidate the saving/restoring GPs (except zero, ra, sp, gp, tp and t0) into save_from_x6_to_x31/restore_from_x6_to_x31 macros. No functional change intended. Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Reviewed-by:
Guo Ren <guoren@kernel.org> Reviewed-by:
-
Jisheng Zhang authored
The ret_from_kernel_thread() behaves similarly with ret_from_fork(), the only difference is whether call the fn(arg) or not, this can be achieved by testing fn is NULL or not, I.E s0 is 0 or not. Many architectures have done the same thing, it makes entry.S more clean. Signed-off-by:
-
Jisheng Zhang authored
Since riscv is converted to generic entry, there's no need for the extra wrappers of trace_hardirqs_{on,off}. Signed-off-by: -
Guo Ren authored
This patch converts riscv to use the generic entry infrastructure from kernel/entry/*. The generic entry makes maintainers' work easier and codes more elegant. Here are the changes: - More clear entry.S with handle_exception and ret_from_exception - Get rid of complex custom signal implementation - Move syscall procedure from assembly to C, which is much more readable. - Connect ret_from_fork & ret_from_kernel_thread to generic entry. - Wrap with irqentry_enter/exit and syscall_enter/exit_from_user_mode - Use the standard preemption code instead of custom Suggested-by:
Huacai Chen <chenhuacai@kernel.org> Reviewed-by:
Yipeng Zou <zouyipeng@huawei.com> Tested-by:
Guo Ren <guoren@linux.alibaba.com> Signed-off-by:
-
Guo Ren authored
Without noinstr the compiler is free to insert instrumentation (think all the k*SAN, KCov, GCov, ftrace etc..) which can call code we're not yet ready to run this early in the entry path, for instance it could rely on RCU which isn't on yet, or expect lockdep state. (by peterz) Link: https://lore.kernel.org/linux-riscv/YxcQ6NoPf3AH0EXe@hirez.programming.kicks-ass.net/Reviewed-by:
Peter Zijlstra <peterz@infradead.org> Tested-by:
-
Guo Ren authored
The TIF_SYSCALL_TRACE is controlled by a common code, see kernel/ptrace.c and include/linux/thread_info.h. clear_task_syscall_work(child, SYSCALL_TRACE); Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reviewed-by:
-
- 15 Mar, 2023 10 commits
-
-
Palmer Dabbelt authored
Andrew Jones <ajones@ventanamicro.com> says: When the Zicboz extension is available we can more rapidly zero naturally aligned Zicboz block sized chunks of memory. As pages are always page aligned and are larger than any Zicboz block size will be, then clear_page() appears to be a good candidate for the extension. While cycle count and energy consumption should also be considered, we can be pretty certain that implementing clear_page() with the Zicboz extension is a win by comparing the new dynamic instruction count with its current count[1]. Doing so we see that the new count is just over a quarter of the old count (see patch6's commit message for more details). For those of you who reviewed v1[2], you may be looking for the memset() patches. As pointed out in v1, and a couple follow-up emails, it's not clear that patching memset() is a win yet. When I get a chance to test on real hardware with a comprehensive benchmark collection then I can post the memset() patches separately (assuming the benchmarks show it's worthwhile). * b4-shazam-merge: RISC-V: KVM: Expose Zicboz to the guest RISC-V: KVM: Provide UAPI for Zicboz block size RISC-V: Use Zicboz in clear_page when available RISC-V: cpufeatures: Put the upper 16 bits of patch ID to work RISC-V: Add Zicboz detection and block size parsing dt-bindings: riscv: Document cboz-block-size RISC-V: Factor out body of riscv_init_cbom_blocksize loop RISC-V: alternatives: Support patching multiple insns in assembly Link: https://lore.kernel.org/r/20230224162631.405473-1-ajones@ventanamicro.comSigned-off-by:
-
Andrew Jones authored
Guests may use the cbo.zero instruction when the CPU has the Zicboz extension and the hypervisor sets henvcfg.CBZE. Add Zicboz support for KVM guests which may be enabled and disabled from KVM userspace using the ISA extension ONE_REG API. Signed-off-by:
-
Andrew Jones authored
We're about to allow guests to use the Zicboz extension. KVM userspace needs to know the cache block size in order to properly advertise it to the guest. Provide a virtual config register for userspace to get it with the GET_ONE_REG API, but setting it cannot be supported, so disallow SET_ONE_REG. Signed-off-by:
-
Andrew Jones authored
Using memset() to zero a 4K page takes 563 total instructions, where 20 are branches. clear_page(), with Zicboz and a 64 byte block size, takes 169 total instructions, where 4 are branches and 33 are nops. Even though the block size is a variable, thanks to alternatives, we can still implement a Duff device without having to do any preliminary calculations. This is achieved by using the alternatives' cpufeature value (the upper 16 bits of patch_id). The value used is the maximum zicboz block size order accepted at the patch site. This enables us to stop patching / unrolling when 4K bytes have been zeroed (we would loop and continue after 4K if the page size would be larger) For 4K pages, unrolling 16 times allows block sizes of 64 and 128 to only loop a few times and larger block sizes to not loop at all. Since cbo.zero doesn't take an offset, we also need an 'add' after each instruction, making the loop body 112 to 160 bytes. Hopefully this is small enough to not cause icache misses. Signed-off-by:
-
Andrew Jones authored
cpufeature IDs are consecutive integers starting at 26, so a 32-bit patch ID allows an aircraft carrier load of feature IDs. Repurposing the upper 16 bits still leaves a boat load of feature IDs and gains 16 bits which may be used to control patching on a per patch-site basis. This will be initially used in Zicboz's application to clear_page(), as Zicboz's block size must also be considered. In that case, the upper 16-bit value's role will be to convey the maximum block size which the Zicboz clear_page() implementation supports. cpufeature patch sites which need to check for the existence or absence of other cpufeatures may also be able to make use of this. Signed-off-by:
-
Andrew Jones authored
Parse "riscv,cboz-block-size" from the DT by piggybacking on Zicbom's riscv_init_cbom_blocksize(). Additionally check the DT for the presence of the "zicboz" extension and, when it's present, validate the parsed cboz block size as we do Zicbom's cbom block size with riscv_isa_extension_check(). Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
-
Andrew Jones authored
The Zicboz operation (cbo.zero) operates on a block-size defined for the cpu-core. While we already have the riscv,cbom-block-size property, it only provides the block size for Zicbom operations. Even though it's likely Zicboz and Zicbom will use the same size, that's not required by the specification. Create another property specifically for Zicboz. Cc: Rob Herring <robh@kernel.org> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230224162631.405473-4-ajones@ventanamicro.comSigned-off-by:
-
Andrew Jones authored
Refactor riscv_init_cbom_blocksize() to prepare for it to be used for both cbom block size and cboz block size. Signed-off-by:
-
Andrew Jones authored
As pointed out in commit d374a165 ("RISC-V: fix compile error from deduplicated __ALTERNATIVE_CFG_2"), we need quotes around parameters passed to macros within macros to avoid spaces being interpreted as separators. ALT_NEW_CONTENT was trying to handle this by defining new_c has a vararg, but this isn't sufficient for calling ALTERNATIVE() from assembly with multiple instructions in the new/old sequences. Remove the vararg "hack" and use quotes. Signed-off-by:
-
Palmer Dabbelt authored
Andrew Jones <ajones@ventanamicro.com> says: This series has no intended functional change. These cleanups were found while renaming errata_id to patch_id in order to better convey that its purpose is larger than errata (it's also for cpufeatures). * b4-shazam-merge: riscv: cpufeature: Drop errata_list.h and other unused includes riscv: lib: Include hwcap.h directly riscv: alternatives: Rename errata_id to patch_id riscv: alternatives: Remove unnecessary define and unused struct riscv: Rename Kconfig.erratas to Kconfig.errata riscv: Clarify RISCV_ALTERNATIVE help text Link: https://lore.kernel.org/r/20230224154601.88163-1-ajones@ventanamicro.comSigned-off-by:
-
