%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

On Fri, 2021-06-04 at 21:00 +0800, Bin Meng wrote:

%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

Reviewed-by: Atish Patra <atish.patra@...>

--
Regards,
Atish