OpenSBI Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <ajones@ventanamicro.com>
To: opensbi@lists.infradead.org
Subject: [PATCH v6 7/7] lib: sbi: Document sbi_ecall_extension members
Date: Mon, 15 May 2023 13:12:40 +0200	[thread overview]
Message-ID: <20230515111240.95059-8-ajones@ventanamicro.com> (raw)
In-Reply-To: <20230515111240.95059-1-ajones@ventanamicro.com>

With the introduction of the register_extensions callback the
range members (extid_start and extid_end) may now change and it
has become a bit subtle as to when a probe function should be
implemented. Document all the members and their relationship to
the register_extensions callback.

Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
---
 include/sbi/sbi_ecall.h | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/include/sbi/sbi_ecall.h b/include/sbi/sbi_ecall.h
index fac26429cf5d..90f33bac0bcc 100644
--- a/include/sbi/sbi_ecall.h
+++ b/include/sbi/sbi_ecall.h
@@ -21,11 +21,46 @@ struct sbi_trap_regs;
 struct sbi_trap_info;
 
 struct sbi_ecall_extension {
+	/* head is used by the extension list */
 	struct sbi_dlist head;
+	/*
+	 * extid_start and extid_end specify the range for this extension. As
+	 * the initial range may be wider than the valid runtime range, the
+	 * register_extensions callback is responsible for narrowing the range
+	 * before other callbacks may be invoked.
+	 */
 	unsigned long extid_start;
 	unsigned long extid_end;
+	/*
+	 * register_extensions
+	 *
+	 * Calls sbi_ecall_register_extension() one or more times to register
+	 * extension ID range(s) which should be handled by this extension.
+	 * More than one sbi_ecall_extension struct and
+	 * sbi_ecall_register_extension() call is necessary when the supported
+	 * extension ID ranges have gaps. Additionally, extension availability
+	 * must be checked before registering, which means, when this callback
+	 * returns, only valid extension IDs from the initial range, which are
+	 * also available, have been registered.
+	 */
 	int (* register_extensions)(void);
+	/*
+	 * probe
+	 *
+	 * Implements the Base extension's probe function for the extension. As
+	 * the register_extensions callback ensures that no other extension
+	 * callbacks will be invoked when the extension is not available, then
+	 * probe can never fail. However, an extension may choose to set
+	 * out_val to a nonzero value other than one. In those cases, it should
+	 * implement this callback.
+	 */
 	int (* probe)(unsigned long extid, unsigned long *out_val);
+	/*
+	 * handle
+	 *
+	 * This is the extension handler. register_extensions ensures it is
+	 * never invoked with an invalid or unavailable extension ID.
+	 */
 	int (* handle)(unsigned long extid, unsigned long funcid,
 		       const struct sbi_trap_regs *regs,
 		       unsigned long *out_val,
-- 
2.40.0



  parent reply	other threads:[~2023-05-15 11:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15 11:12 [PATCH v6 0/7] lib: sbi: Ensure SBI extension is available Andrew Jones
2023-05-15 11:12 ` [PATCH v6 1/7] lib: sbi: Introduce register_extensions extension callback Andrew Jones
2023-05-21 15:26   ` Anup Patel
2023-05-15 11:12 ` [PATCH v6 2/7] lib: sbi: Narrow vendor extension range Andrew Jones
2023-05-15 13:43   ` Anup Patel
2023-05-21 15:26   ` Anup Patel
2023-05-15 11:12 ` [PATCH v6 3/7] lib: sbi: pmu: Remove unnecessary probe function Andrew Jones
2023-05-21 15:26   ` Anup Patel
2023-05-15 11:12 ` [PATCH v6 4/7] lib: sbi: Only register available extensions Andrew Jones
2023-05-21 15:31   ` Anup Patel
2023-05-15 11:12 ` [PATCH v6 5/7] lib: sbi: Optimize probe of srst/susp Andrew Jones
2023-05-21 15:31   ` Anup Patel
2023-05-15 11:12 ` [PATCH v6 6/7] lib: sbi: Remove 0/1 probe implementations Andrew Jones
2023-05-21 15:31   ` Anup Patel
2023-05-15 11:12 ` Andrew Jones [this message]
2023-05-21 15:32   ` [PATCH v6 7/7] lib: sbi: Document sbi_ecall_extension members Anup Patel

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=20230515111240.95059-8-ajones@ventanamicro.com \
    --to=ajones@ventanamicro.com \
    --cc=opensbi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox