From: "Hongren (Zenithal) Zheng" <i@zenithal.me> To: Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Albert Ou <aou@eecs.berkeley.edu> Cc: Atish Patra <atishp@rivosinc.com>, Anup Patel <anup@brainfault.org>, Eric Biederman <ebiederm@xmission.com>, Kees Cook <keescook@chromium.org>, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Michael Kerrisk <mtk.manpages@gmail.com>, linux-man@vger.kernel.org, Jiatai He <jiatai2021@iscas.ac.cn> Subject: [PATCH 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP Date: Sat, 30 Apr 2022 21:48:02 +0800 [thread overview] Message-ID: <Ym0+Erz5DEnB78vu@Sun> (raw) This patchset proposes a currently viable and forward compatible way to expose the bitmanip/scalar crypto capability of the platform to the userspace. Currently viable refers to the property that hardware platforms can easily modify the riscv,isa field in DT to tell the kernel it has the capability. Note that QEMU has already done so in its device tree. Forward compatible refers to the property that userspace can still detect the capability of the environment by using HWCAP regardless of how the mechanism changes below kernel in the future. I do know that it has not been settled how to discover a capability, but I think kernel has to offer some API after all, and HWCAP is the preferred way among other mechanisms for now. More discussion on userspace discovering can be found on my PR to openssl https://github.com/openssl/openssl/pull/18197 Hongren (Zenithal) Zheng (3): RISC-V: add Bitmanip/Scalar Crypto parsing from DT RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT arch/riscv/include/asm/elf.h | 2 + arch/riscv/include/asm/hwcap.h | 16 ++++++ arch/riscv/include/uapi/asm/hwcap.h | 22 ++++++++ arch/riscv/kernel/cpu.c | 14 +++++ arch/riscv/kernel/cpufeature.c | 79 +++++++++++++++++++++++++---- 5 files changed, 123 insertions(+), 10 deletions(-) -- 2.35.1
WARNING: multiple messages have this Message-ID (diff)
From: "Hongren (Zenithal) Zheng" <i@zenithal.me> To: Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Albert Ou <aou@eecs.berkeley.edu> Cc: Atish Patra <atishp@rivosinc.com>, Anup Patel <anup@brainfault.org>, Eric Biederman <ebiederm@xmission.com>, Kees Cook <keescook@chromium.org>, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Michael Kerrisk <mtk.manpages@gmail.com>, linux-man@vger.kernel.org, Jiatai He <jiatai2021@iscas.ac.cn> Subject: [PATCH 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP Date: Sat, 30 Apr 2022 21:48:02 +0800 [thread overview] Message-ID: <Ym0+Erz5DEnB78vu@Sun> (raw) This patchset proposes a currently viable and forward compatible way to expose the bitmanip/scalar crypto capability of the platform to the userspace. Currently viable refers to the property that hardware platforms can easily modify the riscv,isa field in DT to tell the kernel it has the capability. Note that QEMU has already done so in its device tree. Forward compatible refers to the property that userspace can still detect the capability of the environment by using HWCAP regardless of how the mechanism changes below kernel in the future. I do know that it has not been settled how to discover a capability, but I think kernel has to offer some API after all, and HWCAP is the preferred way among other mechanisms for now. More discussion on userspace discovering can be found on my PR to openssl https://github.com/openssl/openssl/pull/18197 Hongren (Zenithal) Zheng (3): RISC-V: add Bitmanip/Scalar Crypto parsing from DT RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT arch/riscv/include/asm/elf.h | 2 + arch/riscv/include/asm/hwcap.h | 16 ++++++ arch/riscv/include/uapi/asm/hwcap.h | 22 ++++++++ arch/riscv/kernel/cpu.c | 14 +++++ arch/riscv/kernel/cpufeature.c | 79 +++++++++++++++++++++++++---- 5 files changed, 123 insertions(+), 10 deletions(-) -- 2.35.1 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next reply other threads:[~2022-04-30 13:48 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-30 13:48 Hongren (Zenithal) Zheng [this message] 2022-04-30 13:48 ` [PATCH 0/3] RISC-V: Add Bitmanip/Scalar Crypto HWCAP Hongren (Zenithal) Zheng 2022-04-30 13:50 ` [PATCH 1/3] RISC-V: add Bitmanip/Scalar Crypto parsing from DT Hongren (Zenithal) Zheng 2022-04-30 13:50 ` Hongren (Zenithal) Zheng 2022-05-03 23:21 ` Heiko Stuebner 2022-05-03 23:21 ` Heiko Stuebner 2022-05-04 2:39 ` Hongren (Zenithal) Zheng 2022-05-04 2:39 ` Hongren (Zenithal) Zheng 2022-04-30 13:51 ` [PATCH 2/3] RISC-V: uapi: add HWCAP for Bitmanip/Scalar Crypto Hongren (Zenithal) Zheng 2022-04-30 13:51 ` Hongren (Zenithal) Zheng 2022-04-30 13:51 ` [PATCH 3/3] RISC-V: HWCAP: parse Bitmanip/Scalar Crypto HWCAP from DT Hongren (Zenithal) Zheng 2022-04-30 13:51 ` Hongren (Zenithal) Zheng
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Ym0+Erz5DEnB78vu@Sun \ --to=i@zenithal.me \ --cc=anup@brainfault.org \ --cc=aou@eecs.berkeley.edu \ --cc=atishp@rivosinc.com \ --cc=ebiederm@xmission.com \ --cc=jiatai2021@iscas.ac.cn \ --cc=keescook@chromium.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-man@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-riscv@lists.infradead.org \ --cc=mtk.manpages@gmail.com \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.