interrupt-framework-design.rst: Cosmetic changes
Change-Id: Id2e2800af59ca35fc0c4cfdddd9f5c5afd56a4db
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
diff --git a/docs/interrupt-framework-design.rst b/docs/interrupt-framework-design.rst
index f65e055..0eb7f54 100644
--- a/docs/interrupt-framework-design.rst
+++ b/docs/interrupt-framework-design.rst
@@ -135,7 +135,7 @@
former's state is correctly saved by the latter.
#. **CSS=1, TEL3=0**. Interrupt is routed to FEL when execution is in
- non-secure state. This is an valid routing model as a non-secure interrupt
+ non-secure state. This is a valid routing model as a non-secure interrupt
is handled by non-secure software.
#. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in
@@ -216,17 +216,14 @@
#. Interrupt exceptions (``PSTATE.I`` and ``F`` bits) are masked during execution
in EL3.
-#. .. rubric:: Interrupt management
- :name: interrupt-management
+#. Interrupt management: the following sections describe how interrupts are
+ managed by the interrupt handling framework. This entails:
- The following sections describe how interrupts are managed by the interrupt
- handling framework. This entails:
+ #. Providing an interface to allow registration of a handler and
+ specification of the routing model for a type of interrupt.
-#. Providing an interface to allow registration of a handler and specification
- of the routing model for a type of interrupt.
-
-#. Implementing support to hand control of an interrupt type to its registered
- handler when the interrupt is generated.
+ #. Implementing support to hand control of an interrupt type to its
+ registered handler when the interrupt is generated.
Both aspects of interrupt management involve various components in the secure
software stack spanning from EL3 to Secure-EL1. These components are described
@@ -685,14 +682,14 @@
for the following:
#. Validating the interrupt. This involves ensuring that the interrupt was
- generating according to the interrupt routing model specified by the SPD
+ generated according to the interrupt routing model specified by the SPD
service during registration. It should use the security state of the
exception level (passed in the ``flags`` parameter of the handler) where
the interrupt was taken from to determine this. If the interrupt is not
recognised then the handler should treat it as an irrecoverable error
condition.
- A SPD service can register a handler for Secure-EL1 and/or Non-secure
+ An SPD service can register a handler for Secure-EL1 and/or Non-secure
interrupts. A non-secure interrupt should never be routed to EL3 from
from non-secure state. Also if a routing model is chosen where Secure-EL1
interrupts are routed to S-EL1 when execution is in Secure state, then a