Hi Atish
Atish Patra atishp@atishpatra.org 於 2020年6月3日 週三 上午2:32寫道：
On Mon, Jun 1, 2020 at 2:09 AM Bin Meng bmeng.cn@gmail.com wrote:
Hi Rick,
On Mon, Jun 1, 2020 at 5:08 PM Rick Chen rickchen36@gmail.com wrote:
Hi Bin
From: Bin Meng [mailto:bmeng.cn@gmail.com] Sent: Wednesday, May 27, 2020 5:05 PM To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List Cc: Atish Patra; Bin Meng Subject: [PATCH 2/2] riscv: sbi: Move sbi_probe_extension() out of CONFIG_SBI_V01
From: Bin Meng bin.meng@windriver.com
sbi_probe_extension() is an API defined in SBI v0.2, not v0.1.
Fixes 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to SBI_v01") Signed-off-by: Bin Meng bin.meng@windriver.com
Reviewed-by: Rick Chen rick@andestech.com
BTW, it seem look like sbi_remote_fence_i, sbi_remote_sfence_vma and sbi_remote_sfence_vma_asid are all can be used no mater in SBI_V01 or SBI_V02. Because you have distinguished them in sbi.h
No these calls are different and not compatible between SBI_V01 and SBI_V02.
In addition to that, U-Boot proper enables SMP only for SBI_V01 because U-Boot doesn't need boot all the cores if the supervisor OS & SBI provider supports SBI v0.2 with HSM.
Starting with OpenSBI v0.7 & Linux kernel 5.7 supports both. Thus, there is no advantage in adding redundant code in a generic path that is never going to be used.
Any SBI provider that only supports SBI v0.1, the user can fall back to SBI_V01 config.
Thanks for your explanation.
Regards, Rick
See commit 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to SBI_v01")
Regards, Bin
-- Regards, Atish