2021-12-16 12:35:47

by Heinrich Schuchardt

[permalink] [raw]
Subject: [PATCH 1/1] riscv: default to CONFIG_RISCV_SBI_V01=n

The SBI 0.1 specification is obsolete. The current version is 0.3.
Hence we should not rely by default on SBI 0.1 being implemented.

Signed-off-by: Heinrich Schuchardt <[email protected]>
---
arch/riscv/Kconfig | 1 -
1 file changed, 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 09abf62ae0ad..f177ad3bee0f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -396,7 +396,6 @@ source "kernel/Kconfig.hz"

config RISCV_SBI_V01
bool "SBI v0.1 support"
- default y
depends on RISCV_SBI
help
This config allows kernel to use SBI v0.1 APIs. This will be
--
2.32.0



2021-12-16 13:49:40

by Jessica Clarke

[permalink] [raw]
Subject: Re: [PATCH 1/1] riscv: default to CONFIG_RISCV_SBI_V01=n

On 16 Dec 2021, at 12:35, Heinrich Schuchardt <[email protected]> wrote:
>
> The SBI 0.1 specification is obsolete. The current version is 0.3.
> Hence we should not rely by default on SBI 0.1 being implemented.

It’s what BBL implements, and some people are still using it,
especially given early hardware shipped before OpenSBI grew in
popularity.

Jess


2021-12-16 14:17:29

by Heinrich Schuchardt

[permalink] [raw]
Subject: Re: [PATCH 1/1] riscv: default to CONFIG_RISCV_SBI_V01=n

On 12/16/21 14:49, Jessica Clarke wrote:
> On 16 Dec 2021, at 12:35, Heinrich Schuchardt <[email protected]> wrote:
>>
>> The SBI 0.1 specification is obsolete. The current version is 0.3.
>> Hence we should not rely by default on SBI 0.1 being implemented.
>
> It’s what BBL implements, and some people are still using it,
> especially given early hardware shipped before OpenSBI grew in
> popularity.
>
> Jess
>

Do you mean BBL is not developed anymore?

Some people may still be using a 0.1 SBI. But that minority stuck on an
outdated software stack does not justify defaulting to deprecated
settings in future Linux releases.

Best regards

Heinrich

2021-12-16 16:51:33

by Jessica Clarke

[permalink] [raw]
Subject: Re: [PATCH 1/1] riscv: default to CONFIG_RISCV_SBI_V01=n

On 16 Dec 2021, at 14:17, Heinrich Schuchardt <[email protected]> wrote:
>
> On 12/16/21 14:49, Jessica Clarke wrote:
>> On 16 Dec 2021, at 12:35, Heinrich Schuchardt <[email protected]> wrote:
>>>
>>> The SBI 0.1 specification is obsolete. The current version is 0.3.
>>> Hence we should not rely by default on SBI 0.1 being implemented.
>> It’s what BBL implements, and some people are still using it,
>> especially given early hardware shipped before OpenSBI grew in
>> popularity.
>> Jess
>
> Do you mean BBL is not developed anymore?
>
> Some people may still be using a 0.1 SBI. But that minority stuck on an outdated software stack does not justify defaulting to deprecated settings in future Linux releases.

BBL is still actively maintained; its most recent commit was 24 days
ago. Also, the amount of code CONFIG_RISCV_SBI_V01 affects is tiny, so
I see no tangible benefit from making this change, just unnecessary
breakage of perfectly functional systems.

Jess


2021-12-17 10:42:36

by Heinrich Schuchardt

[permalink] [raw]
Subject: Re: [PATCH 1/1] riscv: default to CONFIG_RISCV_SBI_V01=n



On 12/16/21 17:51, Jessica Clarke wrote:
> On 16 Dec 2021, at 14:17, Heinrich Schuchardt <[email protected]> wrote:
>>
>> On 12/16/21 14:49, Jessica Clarke wrote:
>>> On 16 Dec 2021, at 12:35, Heinrich Schuchardt <[email protected]> wrote:
>>>>
>>>> The SBI 0.1 specification is obsolete. The current version is 0.3.
>>>> Hence we should not rely by default on SBI 0.1 being implemented.
>>> It’s what BBL implements, and some people are still using it,
>>> especially given early hardware shipped before OpenSBI grew in
>>> popularity.
>>> Jess
>>
>> Do you mean BBL is not developed anymore?
>>
>> Some people may still be using a 0.1 SBI. But that minority stuck on an outdated software stack does not justify defaulting to deprecated settings in future Linux releases.
>
> BBL is still actively maintained; its most recent commit was 24 days
> ago. Also, the amount of code CONFIG_RISCV_SBI_V01 affects is tiny, so
> I see no tangible benefit from making this change, just unnecessary
> breakage of perfectly functional systems.

Only the default is changed. How could this break any existing system?
You can still compile with the deprecated setting.

I can not see why we should keep a default that will cause issues on
systems complying to the current SBI specification.

Best regards

Heinrich


2021-12-17 12:09:49

by Anup Patel

[permalink] [raw]
Subject: Re: [PATCH 1/1] riscv: default to CONFIG_RISCV_SBI_V01=n

+Atish

On Fri, Dec 17, 2021 at 4:12 PM Heinrich Schuchardt
<[email protected]> wrote:
>
>
>
> On 12/16/21 17:51, Jessica Clarke wrote:
> > On 16 Dec 2021, at 14:17, Heinrich Schuchardt <[email protected]> wrote:
> >>
> >> On 12/16/21 14:49, Jessica Clarke wrote:
> >>> On 16 Dec 2021, at 12:35, Heinrich Schuchardt <[email protected]> wrote:
> >>>>
> >>>> The SBI 0.1 specification is obsolete. The current version is 0.3.
> >>>> Hence we should not rely by default on SBI 0.1 being implemented.
> >>> It’s what BBL implements, and some people are still using it,
> >>> especially given early hardware shipped before OpenSBI grew in
> >>> popularity.
> >>> Jess
> >>
> >> Do you mean BBL is not developed anymore?
> >>
> >> Some people may still be using a 0.1 SBI. But that minority stuck on an outdated software stack does not justify defaulting to deprecated settings in future Linux releases.
> >
> > BBL is still actively maintained; its most recent commit was 24 days
> > ago. Also, the amount of code CONFIG_RISCV_SBI_V01 affects is tiny, so
> > I see no tangible benefit from making this change, just unnecessary
> > breakage of perfectly functional systems.
>
> Only the default is changed. How could this break any existing system?
> You can still compile with the deprecated setting.
>
> I can not see why we should keep a default that will cause issues on
> systems complying to the current SBI specification.

I agree with Heinrich.

Almost all SBI implementations (OpenSBI, EDK2, KVM, Xvisor, etc) are
providing at least SBI v0.2 and we can't endlessly wait for BBL to move
away from SBI v0.1. We can't totally remove SBI v0.1 but we should
at least disable it by default.

Same rationale applies to the spinwait CPU operations which are only
required for systems using BBL. The sparse HART id series from Atish
can include a patch to have spinwait CPU operations disabled by
default.

@Atish/Palmer, what do you think ?

Regards,
Anup

2021-12-17 18:35:57

by Palmer Dabbelt

[permalink] [raw]
Subject: Re: [PATCH 1/1] riscv: default to CONFIG_RISCV_SBI_V01=n

On Fri, 17 Dec 2021 04:09:22 PST (-0800), [email protected] wrote:
> +Atish
>
> On Fri, Dec 17, 2021 at 4:12 PM Heinrich Schuchardt
> <[email protected]> wrote:
>>
>>
>>
>> On 12/16/21 17:51, Jessica Clarke wrote:
>> > On 16 Dec 2021, at 14:17, Heinrich Schuchardt <[email protected]> wrote:
>> >>
>> >> On 12/16/21 14:49, Jessica Clarke wrote:
>> >>> On 16 Dec 2021, at 12:35, Heinrich Schuchardt <[email protected]> wrote:
>> >>>>
>> >>>> The SBI 0.1 specification is obsolete. The current version is 0.3.
>> >>>> Hence we should not rely by default on SBI 0.1 being implemented.
>> >>> It’s what BBL implements, and some people are still using it,
>> >>> especially given early hardware shipped before OpenSBI grew in
>> >>> popularity.
>> >>> Jess
>> >>
>> >> Do you mean BBL is not developed anymore?
>> >>
>> >> Some people may still be using a 0.1 SBI. But that minority stuck on an outdated software stack does not justify defaulting to deprecated settings in future Linux releases.
>> >
>> > BBL is still actively maintained; its most recent commit was 24 days
>> > ago. Also, the amount of code CONFIG_RISCV_SBI_V01 affects is tiny, so
>> > I see no tangible benefit from making this change, just unnecessary
>> > breakage of perfectly functional systems.
>>
>> Only the default is changed. How could this break any existing system?
>> You can still compile with the deprecated setting.
>>
>> I can not see why we should keep a default that will cause issues on
>> systems complying to the current SBI specification.
>
> I agree with Heinrich.
>
> Almost all SBI implementations (OpenSBI, EDK2, KVM, Xvisor, etc) are
> providing at least SBI v0.2 and we can't endlessly wait for BBL to move
> away from SBI v0.1. We can't totally remove SBI v0.1 but we should
> at least disable it by default.
>
> Same rationale applies to the spinwait CPU operations which are only
> required for systems using BBL. The sparse HART id series from Atish
> can include a patch to have spinwait CPU operations disabled by
> default.
>
> @Atish/Palmer, what do you think ?

I agree with Heinrich: it's just a defconfig change, we're not dropping
support for SBI-0.1. The defconfig is generally meant to reflect what
kernel developers are using, and AFAIK everyone doing upstream
development moved off the legacy SBI implementations as of a while ago.
There's some cost associated with supporting the old SBI, it's not like
this is just some backup calls we're adding.

If vendors are still shipping old firmwares as part of their SDKs that's
fine, they'll just need to flip on support for it in their configs. Who
knows, maybe this will even be the nudge they need to stop shipping
ancient firmware ;)

2022-01-21 22:26:04

by Palmer Dabbelt

[permalink] [raw]
Subject: Re: [PATCH 1/1] riscv: default to CONFIG_RISCV_SBI_V01=n

On Thu, 16 Dec 2021 04:35:38 PST (-0800), [email protected] wrote:
> The SBI 0.1 specification is obsolete. The current version is 0.3.
> Hence we should not rely by default on SBI 0.1 being implemented.
>
> Signed-off-by: Heinrich Schuchardt <[email protected]>
> ---
> arch/riscv/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 09abf62ae0ad..f177ad3bee0f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -396,7 +396,6 @@ source "kernel/Kconfig.hz"
>
> config RISCV_SBI_V01
> bool "SBI v0.1 support"
> - default y
> depends on RISCV_SBI
> help
> This config allows kernel to use SBI v0.1 APIs. This will be

Thanks, this is on for-next.