From: anup@brainfault.org (Anup Patel) To: linux-riscv@lists.infradead.org Subject: SBI extension proposal Date: Thu, 1 Nov 2018 15:05:51 +0530 [thread overview] Message-ID: <CAAhSdy3mC2-tLNF5jmsHEFrKR7pG6afbM-aYu-6q2LkB7mRG7A@mail.gmail.com> (raw) In-Reply-To: <CA+h06zgcyWz7WMbzQxjyc9V5S3CokqSoO1mGOaynJE3uJE5QSg@mail.gmail.com> On Thu, Nov 1, 2018 at 2:50 PM Philipp Hug <philipp@hug.cx> wrote: > > Hi Atish, > > Am Mi., 31. Okt. 2018 um 19:24 Uhr schrieb Atish Patra <atish.patra@wdc.com>: >> >> -- u32 sbi_get_version(void): >> -- u32 sbi_check_api(unsigned long start_api_id, unsigned long count): > > > How about putting the version information into device tree and use the compatible string? This seems more reliable than probing. > e.g. > firmware { > sbi { > compatible = "riscv,sbi-r0p1", "riscv,sbi-r0p2"; > }; > }; If it was just DT then I think having this information in DT makes sense. In future, we might definitely see some ACPI support in RISC-V too (just like ARM64 world). Of course, we cannot keep adding new SBI calls for static information but we can certainly have bare-minimum mandatory SBI calls for version and capabilities. > > You could also add more information about the supported features to this sbi node. > > I'd also suggest that all functions can return an error code and are not of type void. Yes, I agree. With SBI v0.2, existing SBI calls from v0.1 should return error code. Regards, Anup
WARNING: multiple messages have this Message-ID (diff)
From: Anup Patel <anup@brainfault.org> To: philipp@hug.cx Cc: Mark Rutland <mark.rutland@arm.com>, Christoph Hellwig <hch@infradead.org>, Damien Le Moal <Damien.LeMoal@wdc.com>, olof.johansson@gmail.com, Andrew Waterman <andrew@sifive.com>, alankao@andestech.com, Palmer Dabbelt <palmer@sifive.com>, rjones@redhat.com, Zong Li <zong@andestech.com>, Atish Patra <atish.patra@wdc.com>, Michael Clark <mjc@sifive.com>, Arnd Bergmann <arnd@arndb.de>, paul.walmsley@sifive.com, linux-riscv@lists.infradead.org, abner.chang@hpe.com, vincentc@andestech.com, David.Abdurachmanov@cern.ch Subject: Re: SBI extension proposal Date: Thu, 1 Nov 2018 15:05:51 +0530 [thread overview] Message-ID: <CAAhSdy3mC2-tLNF5jmsHEFrKR7pG6afbM-aYu-6q2LkB7mRG7A@mail.gmail.com> (raw) Message-ID: <20181101093551.6GxeEjeCmkJlAj9yIEz_-LwD2ZQlSQvXZjfDDRb-Tv0@z> (raw) In-Reply-To: <CA+h06zgcyWz7WMbzQxjyc9V5S3CokqSoO1mGOaynJE3uJE5QSg@mail.gmail.com> On Thu, Nov 1, 2018 at 2:50 PM Philipp Hug <philipp@hug.cx> wrote: > > Hi Atish, > > Am Mi., 31. Okt. 2018 um 19:24 Uhr schrieb Atish Patra <atish.patra@wdc.com>: >> >> -- u32 sbi_get_version(void): >> -- u32 sbi_check_api(unsigned long start_api_id, unsigned long count): > > > How about putting the version information into device tree and use the compatible string? This seems more reliable than probing. > e.g. > firmware { > sbi { > compatible = "riscv,sbi-r0p1", "riscv,sbi-r0p2"; > }; > }; If it was just DT then I think having this information in DT makes sense. In future, we might definitely see some ACPI support in RISC-V too (just like ARM64 world). Of course, we cannot keep adding new SBI calls for static information but we can certainly have bare-minimum mandatory SBI calls for version and capabilities. > > You could also add more information about the supported features to this sbi node. > > I'd also suggest that all functions can return an error code and are not of type void. Yes, I agree. With SBI v0.2, existing SBI calls from v0.1 should return error code. Regards, Anup _______________________________________________ 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 9:35 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 [this message] 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 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=CAAhSdy3mC2-tLNF5jmsHEFrKR7pG6afbM-aYu-6q2LkB7mRG7A@mail.gmail.com \ --to=anup@brainfault.org \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).