Fix broken links to various sections across docs
These broken links were found with the help of this command:
$> sphinx-build -M linkcheck . build
A sample broken link is reported as follows:
(line 80) -local- firmware-design.rst#secure-el1-payloads-and-dispatchers
Change-Id: I5dcefdd4b8040908658115647e957f6c2c5da7c2
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
diff --git a/docs/components/debugfs-design.rst b/docs/components/debugfs-design.rst
index 2096bdb..2536515 100644
--- a/docs/components/debugfs-design.rst
+++ b/docs/components/debugfs-design.rst
@@ -80,8 +80,8 @@
The communication with the 9p layer in BL31 is made through an SMC conduit
(`SMC Calling Convention`_), using a specific SiP Function Id. An NS
shared buffer is used to pass path string parameters, or e.g. to exchange
-data on a read operation. Refer to `ARM SiP Services`_ for a description
-of the SMC interface.
+data on a read operation. Refer to :ref:`ARM SiP Services <arm sip services>`
+for a description of the SMC interface.
Security considerations
-----------------------
diff --git a/docs/components/exception-handling.rst b/docs/components/exception-handling.rst
index 4c63a8b..86ed87c 100644
--- a/docs/components/exception-handling.rst
+++ b/docs/components/exception-handling.rst
@@ -10,13 +10,9 @@
- Asynchronous External Aborts
|TF-A|'s handling of synchronous ``SMC`` exceptions raised from lower ELs is
-described in the `Firmware Design document`__. However, the |EHF| changes the
-semantics of `interrupt handling`__ and `synchronous exceptions`__ other than
-SMCs.
-
-.. __: firmware-design.rst#handling-an-smc
-.. __: `Interrupt handling`_
-.. __: `Effect on SMC calls`_
+described in the :ref:`Firmware Design document <handling-an-smc>`. However, the
+|EHF| changes the semantics of `Interrupt handling`_ and :ref:`synchronous
+exceptions <Effect on SMC calls>` other than SMCs.
The |EHF| is selected by setting the build option ``EL3_EXCEPTION_HANDLING`` to
``1``, and is only available for AArch64 systems.
@@ -77,10 +73,9 @@
independently depending on platform choice and the nature of the exception
received.
-.. [#spd] Not to be confused with `Secure Payload Dispatcher`__, which is an
- EL3 component that operates in EL3 on behalf of Secure OS.
-
-.. __: firmware-design.rst#secure-el1-payloads-and-dispatchers
+.. [#spd] Not to be confused with :ref:`Secure Payload Dispatcher
+ <firmware_design_sel1_spd>`, which is an EL3 component that operates in EL3
+ on behalf of Secure OS.
The role of Exception Handling Framework
----------------------------------------
@@ -139,6 +134,8 @@
the case; for non-interrupts, the |EHF| monitors and asserts this. See
`Transition of priority levels`_.
+.. _interrupt-handling:
+
Interrupt handling
------------------
@@ -151,15 +148,12 @@
sufficient priority are signalled as FIQs, and therefore will be routed to
EL3. As a result, S-EL1 software cannot expect to handle Non-secure
interrupts at S-EL1. Essentially, this deprecates the routing mode described
- as `CSS=0, TEL3=0`__.
-
- .. __: interrupt-framework-design.rst#el3-interrupts
+ as :ref:`CSS=0, TEL3=0 <EL3 interrupts>`.
In order for S-EL1 software to handle Non-secure interrupts while having
|EHF| enabled, the dispatcher must adopt a model where Non-secure interrupts
- are received at EL3, but are then `synchronously`__ handled over to S-EL1.
-
- .. __: interrupt-framework-design.rst#secure-payload
+ are received at EL3, but are then :ref:`synchronously <sp-synchronous-int>`
+ handled over to S-EL1.
- On GICv2 systems, it's required that the build option ``GICV2_G0_FOR_EL3`` is
set to ``1`` so that *Group 0* interrupts target EL3.
@@ -283,15 +277,13 @@
typedef int (*ehf_handler_t)(uint32_t intr_raw, uint32_t flags, void *handle,
void *cookie);
-The parameters are as obtained from the top-level `EL3 interrupt handler`__.
+The parameters are as obtained from the top-level :ref:`EL3 interrupt handler
+<el3-runtime-firmware>`.
-.. __: interrupt-framework-design.rst#el3-runtime-firmware
-
-The `SDEI dispatcher`__, for example, expects the platform to allocate two
-different priority levels—``PLAT_SDEI_CRITICAL_PRI``, and
-``PLAT_SDEI_NORMAL_PRI``—and registers the same handler to handle both levels.
-
-.. __: sdei.rst
+The :ref:`SDEI dispatcher<SDEI: Software Delegated Exception Interface>`, for
+example, expects the platform to allocate two different priority levels—
+``PLAT_SDEI_CRITICAL_PRI``, and ``PLAT_SDEI_NORMAL_PRI`` —and registers the
+same handler to handle both levels.
Interrupt handling example
--------------------------
@@ -374,11 +366,9 @@
A priority level is said to be *active* when an exception of that priority is
being handled: for interrupts, this is implied when the interrupt is
-acknowledged; for non-interrupt exceptions, such as SErrors or `SDEI explicit
-dispatches`__, this has to be done via calling ``ehf_activate_priority()``. See
-`Run-time flow`_.
-
-.. __: sdei.rst#explicit-dispatch-of-events
+acknowledged; for non-interrupt exceptions, such as SErrors or :ref:`SDEI
+explicit dispatches <explicit-dispatch-of-events>`, this has to be done via
+calling ``ehf_activate_priority()``. See `Run-time flow`_.
Conversely, when the dispatcher has reached a logical resolution for the cause
of the exception, the corresponding priority level ought to be deactivated. As
@@ -457,6 +447,8 @@
If these are violated, a panic will result.
+.. _Effect on SMC calls:
+
Effect on SMC calls
-------------------
@@ -542,10 +534,8 @@
interrupts belonging to different dispatchers.
#. The |EHF|, during its initialisation, registers a top-level interrupt handler
- with the `Interrupt Management Framework`__ for EL3 interrupts. This also
- results in setting the routing bits in ``SCR_EL3``.
-
- .. __: interrupt-framework-design.rst#el3-runtime-firmware
+ with the :ref:`Interrupt Management Framework<el3-runtime-firmware>` for EL3
+ interrupts. This also results in setting the routing bits in ``SCR_EL3``.
#. When an interrupt belonging to a dispatcher fires, GIC raises an EL3/Group 0
interrupt, and is taken to EL3.
diff --git a/docs/components/platform-interrupt-controller-API.rst b/docs/components/platform-interrupt-controller-API.rst
index 9d02f45..069c87b 100644
--- a/docs/components/platform-interrupt-controller-API.rst
+++ b/docs/components/platform-interrupt-controller-API.rst
@@ -286,6 +286,8 @@
*Priority Mask Register*, and make sure memory updates are visible before
potential trigger due to mask update.
+.. _plat_ic_get_interrupt_id:
+
Function: unsigned int plat_ic_get_interrupt_id(unsigned int raw); [optional]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/components/sdei.rst b/docs/components/sdei.rst
index c5275a0..60259c8 100644
--- a/docs/components/sdei.rst
+++ b/docs/components/sdei.rst
@@ -205,6 +205,8 @@
See the function ``sdei_client_el()`` in ``sdei_private.h``.
+.. _explicit-dispatch-of-events:
+
Explicit dispatch of events
---------------------------
diff --git a/docs/components/secure-partition-manager-mm.rst b/docs/components/secure-partition-manager-mm.rst
index 87fc91d..d532901 100644
--- a/docs/components/secure-partition-manager-mm.rst
+++ b/docs/components/secure-partition-manager-mm.rst
@@ -6,11 +6,9 @@
Two implementations of a Secure Partition Manager co-exist in the TF-A codebase:
-- SPM based on the PSA FF-A specification (`Secure Partition Manager`__).
+- SPM based on the PSA FF-A specification (:ref:`Secure Partition Manager`).
- SPM based on the MM interface.
-.. __: secure-partition-manager.html
-
Both implementations differ in their architectures and only one can be selected
at build time.
diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst
index 2169f30..e09da53 100644
--- a/docs/components/secure-partition-manager.rst
+++ b/docs/components/secure-partition-manager.rst
@@ -833,9 +833,7 @@
.. _[2]:
-[2] `Secure Partition Manager using MM interface`__
-
-.. __: secure-partition-manager-mm.html
+[2] :ref:`Secure Partition Manager using MM interface<Secure Partition Manager (MM)>`
.. _[3]: