On Mon, Jun 1, 2020 at 2:09 AM Bin Meng <bmeng...@gmail.com> wrote:
>
> Hi Rick,
>
> On Mon, Jun 1, 2020 at 5:08 PM Rick Chen <rickche...@gmail.com> wrote:
> >
> > Hi Bin
> >
> > > > From: Bin Meng [mailto:bmeng...@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.m...@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.m...@windriver.com>
> > > > ---
> > >
> > > Reviewed-by: Rick Chen <r...@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.
> See commit 7e249bc13aaf: ("riscv: Move all SMP related SBI calls to SBI_v01")
>
> Regards,
> Bin
--
Regards,
Atish
