All of 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 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.