From: atish.patra@wdc.com (Atish Patra)
To: linux-riscv@lists.infradead.org
Subject: SBI extension proposal
Date: Thu, 1 Nov 2018 08:09:41 -0700 [thread overview]
Message-ID: <7c20c4d5-1726-d940-58ef-6541f0a117d2@wdc.com> (raw)
In-Reply-To: <20181101112528.GH27120@redhat.com>
On 11/1/18 4:25 AM, Richard W.M. Jones wrote:
> On Thu, Nov 01, 2018 at 12:03:49PM +0100, Philipp Hug wrote:
>> Am Do., 1. Nov. 2018 um 10:46 Uhr schrieb Richard W.M. Jones
>> <rjones@redhat.com>:
>>>
>>> I agree. Please try not to make things that depend on DT, as it's a
>>> Linux-only description which isn't suitable for other OSes and has a
>>> poorly defined ABI.
>>>
>> You don't have to depend on DT. If you implement ACPI you'd put this
>> information in ACPI as well as you do with other information about the
>> platform.
>> What's the advantage of putting static information into an SBI call
>> instead of putting it in DT, ACPI, ...?
>
> You only have to put it in one place.
>
> Rich.
>
I agree with Richard. It is better to manage it in SBI implementation.
This version will not change in every kernel release or so. I think
having global SBI version in SBI spec is fine.
However, we may need to put <function,version> for vendor specific APIs
in DT/ACPI as pointed by olof earlier. That will help to avoid conflicts.
I will update the proposal such that it is clear that we are not making
DT mandatory, ACPI is an option as well. SBI spec should independent of
OS specific spec.
Regards,
Atish
WARNING: multiple messages have this Message-ID (diff)
From: Atish Patra <atish.patra@wdc.com>
To: "Richard W.M. Jones" <rjones@redhat.com>, Philipp Hug <philipp@hug.cx>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
"hch@infradead.org" <hch@infradead.org>,
Damien Le Moal <Damien.LeMoal@wdc.com>,
"olof.johansson@gmail.com" <olof.johansson@gmail.com>,
"andrew@sifive.com" <andrew@sifive.com>,
"alankao@andestech.com" <alankao@andestech.com>,
"anup@brainfault.org" <anup@brainfault.org>,
Palmer Dabbelt <palmer@sifive.com>,
"zong@andestech.com" <zong@andestech.com>,
"vincentc@andestech.com" <vincentc@andestech.com>,
"mjc@sifive.com" <mjc@sifive.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"abner.chang@hpe.com" <abner.chang@hpe.com>,
"David.Abdurachmanov@cern.ch" <David.Abdurachmanov@cern.ch>
Subject: Re: SBI extension proposal
Date: Thu, 1 Nov 2018 08:09:41 -0700 [thread overview]
Message-ID: <7c20c4d5-1726-d940-58ef-6541f0a117d2@wdc.com> (raw)
Message-ID: <20181101150941.RTyUI_JmQdRLRQXx4wxU_jGRZ8tLRIN5wEEuNbKteRs@z> (raw)
In-Reply-To: <20181101112528.GH27120@redhat.com>
On 11/1/18 4:25 AM, Richard W.M. Jones wrote:
> On Thu, Nov 01, 2018 at 12:03:49PM +0100, Philipp Hug wrote:
>> Am Do., 1. Nov. 2018 um 10:46 Uhr schrieb Richard W.M. Jones
>> <rjones@redhat.com>:
>>>
>>> I agree. Please try not to make things that depend on DT, as it's a
>>> Linux-only description which isn't suitable for other OSes and has a
>>> poorly defined ABI.
>>>
>> You don't have to depend on DT. If you implement ACPI you'd put this
>> information in ACPI as well as you do with other information about the
>> platform.
>> What's the advantage of putting static information into an SBI call
>> instead of putting it in DT, ACPI, ...?
>
> You only have to put it in one place.
>
> Rich.
>
I agree with Richard. It is better to manage it in SBI implementation.
This version will not change in every kernel release or so. I think
having global SBI version in SBI spec is fine.
However, we may need to put <function,version> for vendor specific APIs
in DT/ACPI as pointed by olof earlier. That will help to avoid conflicts.
I will update the proposal such that it is clear that we are not making
DT mandatory, ACPI is an option as well. SBI spec should independent of
OS specific spec.
Regards,
Atish
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2018-11-01 15:09 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-31 18:23 SBI extension proposal Atish Patra
2018-10-31 18:23 ` Atish Patra
[not found] ` <CAK-hmcQeiGa3BwnzEVB_dyhFiC7rXHFN-wTsJomg-jAo7a+v3Q@mail.gmail.com>
2018-10-31 19:11 ` Olof Johansson
2018-10-31 19:11 ` Olof Johansson
2018-10-31 20:37 ` Atish Patra
2018-10-31 20:37 ` Atish Patra
2018-11-02 6:31 ` Chang, Abner (HPS SW/FW Technologist)
2018-11-02 6:31 ` Chang, Abner (HPS SW/FW Technologist)
2018-11-02 22:31 ` Atish Patra
2018-11-02 22:31 ` Atish Patra
2018-11-04 14:36 ` Chang, Abner (HPS SW/FW Technologist)
2018-11-04 14:36 ` Chang, Abner (HPS SW/FW Technologist)
[not found] ` <CA+h06zgcyWz7WMbzQxjyc9V5S3CokqSoO1mGOaynJE3uJE5QSg@mail.gmail.com>
2018-11-01 9:35 ` Anup Patel
2018-11-01 9:35 ` Anup Patel
2018-11-01 9:46 ` Richard W.M. Jones
2018-11-01 9:46 ` Richard W.M. Jones
2018-11-01 11:03 ` Philipp Hug
2018-11-01 11:03 ` Philipp Hug
2018-11-01 11:25 ` Richard W.M. Jones
2018-11-01 11:25 ` Richard W.M. Jones
2018-11-01 15:09 ` Atish Patra [this message]
2018-11-01 15:09 ` Atish Patra
2018-11-02 3:17 ` Olof Johansson
2018-11-02 3:17 ` Olof Johansson
2018-11-01 16:42 ` Karsten Merker
2018-11-02 2:49 ` Palmer Dabbelt
2018-11-02 2:49 ` Palmer Dabbelt
2018-11-02 3:27 ` Anup Patel
2018-11-02 3:27 ` Anup Patel
2018-11-02 4:29 ` Chang, Abner (HPS SW/FW Technologist)
2018-11-02 4:29 ` Chang, Abner (HPS SW/FW Technologist)
2018-11-02 15:24 ` Nick Kossifidis
2018-11-02 15:24 ` Nick Kossifidis
2018-11-02 23:12 ` Atish Patra
2018-11-02 23:12 ` Atish Patra
2018-11-02 23:45 ` Nick Kossifidis
2018-11-02 23:45 ` Nick Kossifidis
2018-11-03 0:00 ` Atish Patra
2018-11-03 0:00 ` Atish Patra
2018-11-05 13:50 ` Nick Kossifidis
2018-11-05 13:50 ` Nick Kossifidis
2018-11-05 18:51 ` Atish Patra
2018-11-05 18:51 ` Atish Patra
2018-11-06 1:55 ` Zong Li
2018-11-06 1:55 ` Zong Li
2018-11-09 21:47 ` Atish Patra
2018-11-09 21:47 ` Atish Patra
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=7c20c4d5-1726-d940-58ef-6541f0a117d2@wdc.com \
--to=atish.patra@wdc.com \
--cc=linux-riscv@lists.infradead.org \
/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: link
Be 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.