[PATCH] riscv-sbi.adoc: Use 'an' before 'SBI'


Bin Meng
 

%s/a SBI/an SBI/
%s/A SBI/An SBI/

Signed-off-by: Bin Meng <bmeng.cn@...>
---

riscv-sbi.adoc | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/riscv-sbi.adoc b/riscv-sbi.adoc
index 11c30c3..b02332e 100644
--- a/riscv-sbi.adoc
+++ b/riscv-sbi.adoc
@@ -52,8 +52,8 @@ of the SBI follows the general RISC-V philosophy of having a small core along
with a set of optional modular extensions.

The higher privilege software providing SBI interface to the supervisor-mode
-software is referred to as a SBI implemenation or Supervisor Execution
-Environment (SEE). A SBI implementation (or SEE) can be platform runtime
+software is referred to as an SBI implemenation or Supervisor Execution
+Environment (SEE). An SBI implementation (or SEE) can be platform runtime
firmware executing in machine-mode (M-mode) (see below <<fig_intro1>>) or
it can be some hypervisor executing in hypervisor-mode (HS-mode) (see below
<<fig_intro2>>).
@@ -124,7 +124,7 @@ the specification simple and easily adaptable for all RISC-V ISA types (i.e.
RV32, RV64 and RV128). In case the data is defined as 32bit wide, higher
privilege software must ensure that it only uses 32 bit data only.

-If a SBI function needs to pass a list of harts to the higher privilege mode,
+If an SBI function needs to pass a list of harts to the higher privilege mode,
it must use a hart mask as defined below. This is applicable to any extensions
defined in or after v0.2.

@@ -765,13 +765,13 @@ A platform can have multiple harts grouped into a hierarchical topology
groups (namely cores, clusters, nodes, etc) with separate platform specific
low-power states for each hierarchical group. These platform specific
low-power states of hierarchial topology groups can be represented as
-platform specific suspend states of a hart. A SBI implementation can
+platform specific suspend states of a hart. An SBI implementation can
utilize the suspend states of higher topology groups using one of the
following approaches:

. *Platform-coordinated:* In this approach, when a hart becomes idle the
supervisor-mode power-managment software will request deepest suspend
- state for the hart and higher topology groups. A SBI implementation
+ state for the hart and higher topology groups. An SBI implementation
should choose a suspend state at higher topology group which is:
.. Not deeper than the specified suspend state
.. Wake-up latency is not higher than the wake-up latency of the
@@ -782,7 +782,7 @@ following approaches:
the supervisor-mode power-managment software will always select suspend
state for the hart itself but it will select a suspend state for a higher
topology group only if the hart is the last running hart in the group.
- A SBI implementation should:
+ An SBI implementation should:
.. Never choose a suspend state for higher topology group different from
the specified suspend state
.. Always prefer most recent suspend state requested for higher topology
--
2.25.1

Join tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.