Doc: Remove useless escape characters

Just like has been done in the porting guide a couple of patches earlier, kill all escaped underscore characters in all documents. Change-Id: I7fb5b806412849761d9221a6ce3cbd95ec43d611 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

Doc: Remove useless escape characters
Just like has been done in the porting guide a couple of patches earlier, kill all escaped underscore characters in all documents. Change-Id: I7fb5b806412849761d9221a6ce3cbd95ec43d611 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
f3cacada · Sandrine Bailleux · 337e2f1f · f3cacada · f3cacada · f3cacada
Commit f3cacada authored Feb 08, 2019 by Sandrine Bailleux
--- a/docs/auth-framework.rst
+++ b/docs/auth-framework.rst
@@ -209,7 +209,7 @@ It is responsible for:
 #. Tracking which images have been verified. In case an image is a part of
   multiple CoTs then it should be verified only once e.g. the Trusted World
   Key Certificate in the TBBR-Client spec. contains information to verify
-   SCP\_BL2, BL31, BL32 each of which have a separate CoT. (This
+   SCP_BL2, BL31, BL32 each of which have a separate CoT. (This
   responsibility has not been described in this document but should be
   trivial to implement).
@@ -627,7 +627,7 @@ The TBBR CoT
 The CoT can be found in ``drivers/auth/tbbr/tbbr_cot.c``. This CoT consists of an
 array of image descriptors and it is registered in the framework using the macro
-``REGISTER_COT(cot_desc)``, where 'cot\_desc' must be the name of the array
+``REGISTER_COT(cot_desc)``, where 'cot_desc' must be the name of the array
 (passing a pointer or any other type of indirection will cause the registration
 process to fail).

--- a/docs/change-log.rst
+++ b/docs/change-log.rst
@@ -973,7 +973,7 @@ New features
 -  Updated PSCI support:
-   -  Added support for PSCI NODE\_HW\_STATE API for Arm platforms.
+   -  Added support for PSCI NODE_HW_STATE API for Arm platforms.
   -  New optional platform hook, ``pwr_domain_pwr_down_wfi()``, in
      ``plat_psci_ops`` to enable platforms to perform platform-specific actions
@@ -1000,14 +1000,14 @@ New features
      This can be useful to map a non-cacheable memory region, such as a DMA
      buffer.
-   -  Introduced the MT\_EXECUTE/MT\_EXECUTE\_NEVER memory mapping attributes to
+   -  Introduced the MT_EXECUTE/MT_EXECUTE_NEVER memory mapping attributes to
      specify the access permissions for instruction execution of a memory
      region.
 -  Enabled support to isolate code and read-only data on separate memory pages,
   allowing independent access control to be applied to each.
-  Enabled SCR\_EL3.SIF (Secure Instruction Fetch) bit in BL1 and BL31 common
+-  Enabled SCR_EL3.SIF (Secure Instruction Fetch) bit in BL1 and BL31 common
   architectural setup code, preventing fetching instructions from non-secure
   memory when in secure state.
@@ -1025,7 +1025,7 @@ New features
      the working directory.
   -  Aligned command line options for specifying images to use same naming
-      convention as specified by TBBR and already used in cert\_create tool.
+      convention as specified by TBBR and already used in cert_create tool.
 -  Refactored the TZC-400 driver to also support memory controllers that
   integrate TZC functionality, for example Arm CoreLink DMC-500. Also added
@@ -1036,7 +1036,7 @@ New features
 -  Enhanced support for Arm platforms:
-   -  Updated image loading support to make SCP images (SCP\_BL2 and SCP\_BL2U)
+   -  Updated image loading support to make SCP images (SCP_BL2 and SCP_BL2U)
      optional.
   -  Enhanced topology description support to allow multi-cluster topology
@@ -1104,7 +1104,7 @@ New features
      **Note** the default build of TF-A will not be able to boot
      Linux kernel with GICv2 FDT blob.
-   -  Enabled wake-up from CPU\_SUSPEND to stand-by by temporarily re-routing
+   -  Enabled wake-up from CPU_SUSPEND to stand-by by temporarily re-routing
      interrupts and then restoring after resume.
 Issues resolved since last release
@@ -1219,7 +1219,7 @@ New features
   -  Better alignment with version 1.0 of the PSCI specification.
-  Added support for the SYSTEM\_SUSPEND PSCI API on Arm platforms. When invoked
+-  Added support for the SYSTEM_SUSPEND PSCI API on Arm platforms. When invoked
   on the last running core on a supported platform, this puts the system
   into a low power mode with memory retention.
@@ -1615,7 +1615,7 @@ Known issues
       <SimName>System Generator:FVP_Base_A57x4_A53x4</SimName>
   to
-   System Generator:FVP\_Base\_Cortex-A57x4\_A53x4
+   System Generator:FVP_Base_Cortex-A57x4_A53x4
   A similar change can be made to the other Cortex-A57-A53 Base FVP variants.
@@ -1643,7 +1643,7 @@ New features
 -  Moved architectural timer setup to platform-specific code.
-  Added standby state support to PSCI cpu\_suspend implementation.
+-  Added standby state support to PSCI cpu_suspend implementation.
 -  SRAM usage improvements:
@@ -1669,7 +1669,7 @@ New features
   default configuration is provided for the Base FVPs. This means the model
   parameter ``-C bp.secure_memory=1`` is now supported.
-  Started saving the PSCI cpu\_suspend 'power\_state' parameter prior to
+-  Started saving the PSCI cpu_suspend 'power_state' parameter prior to
   suspending a CPU. This allows platforms that implement multiple power-down
   states at the same affinity level to identify a specific state.
@@ -1767,13 +1767,13 @@ New features
   instructions for how to contribute and updated copyright text in all files
   to acknowledge contributors.
-  The PSCI CPU\_SUSPEND API has been stabilised to the extent where it can be
+-  The PSCI CPU_SUSPEND API has been stabilised to the extent where it can be
   used for entry into power down states with the following restrictions:
   -  Entry into standby states is not supported.
   -  The API is only supported on the AEMv8 and Cortex-A57-A53 Base FVPs.
-  The PSCI AFFINITY\_INFO api has undergone limited testing on the Base FVPs to
+-  The PSCI AFFINITY_INFO api has undergone limited testing on the Base FVPs to
   allow experimental use.
 -  Required C library and runtime header files are now included locally in
@@ -1803,7 +1803,7 @@ New features
   particular code modules to DRAM itself.
 -  Reworked BL2 to BL3-1 handover interface. A new composite structure
-   (bl31\_args) holds the superset of information that needs to be passed from
+   (bl31_args) holds the superset of information that needs to be passed from
   BL2 to BL3-1, including information on how handover execution control to
   BL3-2 (if present) and BL3-3 (non-trusted firmware).
@@ -1817,7 +1817,7 @@ New features
 -  Added a framework for implementing EL3 runtime services. Reworked the PSCI
   implementation to be one such runtime service.
-  Reworked the exception handling logic, making use of both SP\_EL0 and SP\_EL3
+-  Reworked the exception handling logic, making use of both SP_EL0 and SP_EL3
   stack pointers for determining the type of exception, managing general
   purpose and system register context on exception entry/exit, and handling
   SMCs. SMCs are directed to the correct EL3 runtime service.

--- a/docs/cpu-specific-build-macros.rst
+++ b/docs/cpu-specific-build-macros.rst
@@ -93,7 +93,7 @@ For Cortex-A53, the following errata build flags are defined :
 -  ``ERRATA_A53_855873``: This applies errata 855873 workaround to Cortex-A53
   CPUs. Though the erratum is present in every revision of the CPU,
   this workaround is only applied to CPUs from r0p3 onwards, which feature
-   a chicken bit in CPUACTLR\_EL1 to enable a hardware workaround.
+   a chicken bit in CPUACTLR_EL1 to enable a hardware workaround.
   Earlier revisions of the CPU have other errata which require the same
   workaround in software, so they should be covered anyway.

--- a/docs/firmware-design.rst
+++ b/docs/firmware-design.rst
@@ -404,16 +404,16 @@ needed in the ``bl2_plat_handle_post_image_load()`` function. These
 configuration files can be passed to next Boot Loader stages as arguments
 by updating the corresponding entrypoint information in this function.
-SCP\_BL2 (System Control Processor Firmware) image load
+SCP_BL2 (System Control Processor Firmware) image load
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Some systems have a separate System Control Processor (SCP) for power, clock,
-reset and system control. BL2 loads the optional SCP\_BL2 image from platform
+reset and system control. BL2 loads the optional SCP_BL2 image from platform
 storage into a platform-specific region of secure memory. The subsequent
-handling of SCP\_BL2 is platform specific. For example, on the Juno Arm
+handling of SCP_BL2 is platform specific. For example, on the Juno Arm
 development platform port the image is transferred into SCP's internal memory
 using the Boot Over MHU (BOM) protocol after being loaded in the trusted SRAM
-memory. The SCP executes SCP\_BL2 and signals to the Application Processor (AP)
+memory. The SCP executes SCP_BL2 and signals to the Application Processor (AP)
 for BL2 execution to continue.
 EL3 Runtime Software image load
@@ -688,7 +688,7 @@ Data structures used in the BL31 cold boot interface
 These structures are designed to support compatibility and independent
 evolution of the structures and the firmware images. For example, a version of
 BL31 that can interpret the BL3x image information from different versions of
-BL2, a platform that uses an extended entry\_point\_info structure to convey
+BL2, a platform that uses an extended entry_point_info structure to convey
 additional register information to BL31, or a ELF image loader that can convey
 more details about the firmware images.
@@ -803,10 +803,10 @@ Required CPU state for warm boot initialization
 When requesting a CPU power-on, or suspending a running CPU, AArch32 EL3
 Runtime Software must ensure execution of a warm boot initialization entrypoint.
-If TF-A BL1 is used and the PROGRAMMABLE\_RESET\_ADDRESS build flag is false,
+If TF-A BL1 is used and the PROGRAMMABLE_RESET_ADDRESS build flag is false,
 then AArch32 EL3 Runtime Software must ensure that BL1 branches to the warm
 boot entrypoint by arranging for the BL1 platform function,
-plat\_get\_my\_entrypoint(), to return a non-zero value.
+plat_get_my_entrypoint(), to return a non-zero value.
 In this case, the warm boot entrypoint must be in AArch32 EL3, little-endian
 data access and all interrupt sources masked:
@@ -996,7 +996,7 @@ mandatory APIs in PSCI v1.1, PSCI v1.0 and in PSCI v0.2 draft specification
 `Power State Coordination Interface PDD`_ are implemented. The table lists
 the PSCI v1.1 APIs and their support in generic code.
-An API implementation might have a dependency on platform code e.g. CPU\_SUSPEND
+An API implementation might have a dependency on platform code e.g. CPU_SUSPEND
 requires the platform to export a part of the implementation. Hence the level
 of support of the mandatory APIs depends upon the support exported by the
 platform port as well. The Juno and FVP (all variants) platforms export all the
@@ -1657,13 +1657,13 @@ The following list describes the memory layout on the Arm development platforms:
 -  BL2 is loaded below BL1 RW
-  EL3 Runtime Software, BL31 for AArch64 and BL32 for AArch32 (e.g. SP\_MIN),
+-  EL3 Runtime Software, BL31 for AArch64 and BL32 for AArch32 (e.g. SP_MIN),
   is loaded at the top of the Trusted SRAM, such that its NOBITS sections will
   overwrite BL1 R/W data and BL2. This implies that BL1 global variables
   remain valid only until execution reaches the EL3 Runtime Software entry
   point during a cold boot.
-  On Juno, SCP\_BL2 is loaded temporarily into the EL3 Runtime Software memory
+-  On Juno, SCP_BL2 is loaded temporarily into the EL3 Runtime Software memory
   region and transfered to the SCP before being overwritten by EL3 Runtime
   Software.
@@ -2089,11 +2089,11 @@ the update made by CPU0 as well.
 To use bakery locks when ``USE_COHERENT_MEM`` is disabled, the lock data structure
 has been redesigned. The changes utilise the characteristic of Lamport's Bakery
-algorithm mentioned earlier. The bakery\_lock structure only allocates the memory
+algorithm mentioned earlier. The bakery_lock structure only allocates the memory
 for a single CPU. The macro ``DEFINE_BAKERY_LOCK`` allocates all the bakery locks
 needed for a CPU into a section ``bakery_lock``. The linker allocates the memory
-for other cores by using the total size allocated for the bakery\_lock section
+for other cores by using the total size allocated for the bakery_lock section
-and multiplying it with (PLATFORM\_CORE\_COUNT - 1). This enables software to
+and multiplying it with (PLATFORM_CORE_COUNT - 1). This enables software to
 perform software cache maintenance on the lock data structure without running
 into coherency issues associated with mismatched attributes.
@@ -2155,7 +2155,7 @@ with n bakery locks are:
    ------------------
 Consider a system of 2 CPUs with 'N' bakery locks as shown above. For an
-operation on Lock\_N, the corresponding ``bakery_info_t`` in both CPU0 and CPU1
+operation on Lock_N, the corresponding ``bakery_info_t`` in both CPU0 and CPU1
 ``bakery_lock`` section need to be fetched and appropriate cache operations need
 to be performed for each access.
@@ -2619,8 +2619,8 @@ categories. Based upon the above, the code layout looks like this:
    lib          Yes             Yes             Yes
    services     No              No              Yes
-The build system provides a non configurable build option IMAGE\_BLx for each
+The build system provides a non configurable build option IMAGE_BLx for each
-boot loader stage (where x = BL stage). e.g. for BL1 , IMAGE\_BL1 will be
+boot loader stage (where x = BL stage). e.g. for BL1 , IMAGE_BL1 will be
 defined by the build system. This enables TF-A to compile certain code only
 for specific boot loader stages

--- a/docs/firmware-update.rst
+++ b/docs/firmware-update.rst
@@ -135,8 +135,8 @@ The following is a brief description of the supported states:
 BL1 SMC Interface
 -----------------
-BL1\_SMC\_CALL\_COUNT
+BL1_SMC_CALL_COUNT
-~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~
 ::
@@ -148,8 +148,8 @@ BL1\_SMC\_CALL\_COUNT
 This SMC returns the number of SMCs supported by BL1.
-BL1\_SMC\_UID
+BL1_SMC_UID
-~~~~~~~~~~~~~
+~~~~~~~~~~~
 ::
@@ -162,8 +162,8 @@ BL1\_SMC\_UID
 This SMC returns the 128-bit `Universally Unique Identifier`_ for the
 BL1 SMC service.
-BL1\_SMC\_VERSION
+BL1_SMC_VERSION
-~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~
 ::
@@ -176,8 +176,8 @@ BL1\_SMC\_VERSION
 This SMC returns the current version of the BL1 SMC service.
-BL1\_SMC\_RUN\_IMAGE
+BL1_SMC_RUN_IMAGE
-~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~
 ::
@@ -196,8 +196,8 @@ This SMC passes execution control to an EL3 image described by the provided
 ``entry_point_info_t`` structure. In the normal TF-A boot flow, BL2 invokes
 this SMC for BL1 to pass execution control to BL31.
-FWU\_SMC\_IMAGE\_COPY
+FWU_SMC_IMAGE_COPY
-~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~
 ::
@@ -245,8 +245,8 @@ contiguous memory.
 Once the SMC is handled, BL1 returns from exception to the normal world caller.
-FWU\_SMC\_IMAGE\_AUTH
+FWU_SMC_IMAGE_AUTH
-~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~
 ::
@@ -285,8 +285,8 @@ BL1 returns from exception to the caller. If authentication succeeds then BL1
 sets the image state to AUTHENTICATED. If authentication fails then BL1 returns
 the -EAUTH error and sets the image state back to RESET.
-FWU\_SMC\_IMAGE\_EXECUTE
+FWU_SMC_IMAGE_EXECUTE
-~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~
 ::
@@ -313,8 +313,8 @@ secure world image.
 BL1 saves the normal world caller's context, sets the secure image state to
 EXECUTED, and returns from exception to the secure image.
-FWU\_SMC\_IMAGE\_RESUME
+FWU_SMC_IMAGE_RESUME
-~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~
 ::
@@ -340,8 +340,8 @@ the resuming world. If the call is successful then the caller provided
 ``image_param`` is returned to the resumed world, otherwise an error code is
 returned to the caller.
-FWU\_SMC\_SEC\_IMAGE\_DONE
+FWU_SMC_SEC_IMAGE_DONE
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~
 ::
@@ -361,8 +361,8 @@ BL1 sets the previously executing secure image state to the RESET state,
 restores the normal world context and returns from exception into the normal
 world.
-FWU\_SMC\_UPDATE\_DONE
+FWU_SMC_UPDATE_DONE
-~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~
 ::
@@ -377,8 +377,8 @@ This SMC completes the firmware update process. BL1 calls the platform specific
 function ``bl1_plat_fwu_done``, passing the optional argument ``client_cookie`` as
 a ``void *``. The SMC does not return.
-FWU\_SMC\_IMAGE\_RESET
+FWU_SMC_IMAGE_RESET
-~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~
 ::

--- a/docs/interrupt-framework-design.rst
+++ b/docs/interrupt-framework-design.rst
@@ -451,7 +451,7 @@ requirements mentioned earlier.
   The handover agreement between the TSP and the TSPD requires that the TSPD
   masks all interrupts (``PSTATE.DAIF`` bits) when it calls
   ``tsp_sel1_intr_entry()``. The TSP has to preserve the callee saved general
-   purpose, SP\_EL1/Secure-EL0, LR, VFP and system registers. It can use
+   purpose, SP_EL1/Secure-EL0, LR, VFP and system registers. It can use
   ``x0-x18`` to enable its C runtime.
 #. The TSPD implements a handler function for Secure-EL1 interrupts. This
@@ -595,7 +595,7 @@ The TSP also replaces the default exception vector table referenced through the
 ``early_exceptions`` variable, with a vector table capable of handling FIQ and IRQ
 exceptions taken at the same (Secure-EL1) exception level. This table is
 referenced through the ``tsp_exceptions`` variable and programmed into the
-VBAR\_EL1. It caters for the asynchronous handling model.
+VBAR_EL1. It caters for the asynchronous handling model.
 The TSP also programs the Secure Physical Timer in the Arm Generic Timer block
 to raise a periodic interrupt (every half a second) for the purpose of testing
@@ -904,7 +904,7 @@ In the synchronous model, it should begin handling a Secure-EL1 interrupt after
 receiving control from the SPD service at an entrypoint agreed upon during build
 time or during the registration phase. Before handling the interrupt, the SP
 should save any Secure-EL1 system register context which is needed for resuming
-normal execution in the SP later e.g. ``SPSR_EL1,``\ ELR\_EL1\`. After handling the
+normal execution in the SP later e.g. ``SPSR_EL1,``\ ELR_EL1\`. After handling the
 interrupt, the SP could return control back to the exception level and security
 state where the interrupt was originally taken from. The SP should use an SMC32
 or SMC64 to ask the SPD service to do this.

--- a/docs/platform-compatibility-policy.rst
+++ b/docs/platform-compatibility-policy.rst
 TF-A Platform Compatibility Policy
-======================================================
+==================================
 .. section-numbering::

--- a/docs/psci-lib-integration-guide.rst
+++ b/docs/psci-lib-integration-guide.rst
@@ -140,7 +140,7 @@ to this library are declared in ``psci.h`` and are as listed below:
        void psci_register_spd_pm_hook(const spd_pm_ops_t *pm);
        void psci_prepare_next_non_secure_ctx(entry_point_info_t *next_image_info);
-The CPU context data 'cpu\_context\_t' is programmed to the registers differently
+The CPU context data 'cpu_context_t' is programmed to the registers differently
 when PSCI is integrated with an AArch32 EL3 Runtime Software compared to
 when the PSCI is integrated with an AArch64 EL3 Runtime Software (BL31). For
 example, in the case of AArch64, there is no need to retrieve ``cpu_context_t``
@@ -159,7 +159,7 @@ values if required.
 PSCI library needs the flexibility to access both secure and non-secure
 copies of banked registers. Hence it needs to be invoked in Monitor mode
-for AArch32 and in EL3 for AArch64. The NS bit in SCR (in AArch32) or SCR\_EL3
+for AArch32 and in EL3 for AArch64. The NS bit in SCR (in AArch32) or SCR_EL3
 (in AArch64) must be set to 0. Additional requirements for the PSCI library
 interfaces are:
@@ -175,8 +175,8 @@ interfaces are:
 Further requirements for each interface can be found in the interface
 description.
-Interface : psci\_setup()
+Interface : psci_setup()
-~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~
 ::
@@ -212,8 +212,8 @@ must have completed. Major actions performed by this interface are:
   `CPU Context management API`_) for all the CPUs in the
   platform
-Interface : psci\_prepare\_next\_non\_secure\_ctx()
+Interface : psci_prepare_next_non_secure_ctx()
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ::
@@ -225,11 +225,11 @@ must be called by the EL3 Runtime Software to initialize the non-secure world
 context. The non-secure world entrypoint information ``next_image_info`` (first
 argument) will be used to determine the non-secure context. After this function
 returns, the EL3 Runtime Software must retrieve the ``cpu_context_t`` (using
-cm\_get\_context()) for the current CPU and program the registers prior to exit
+cm_get_context()) for the current CPU and program the registers prior to exit
 to the non-secure world.
-Interface : psci\_register\_spd\_pm\_hook()
+Interface : psci_register_spd_pm_hook()
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ::
@@ -244,8 +244,8 @@ appropriately during power management. Calling this function is optional and
 need to be called by the primary CPU during the cold boot sequence after
 ``psci_setup()`` has completed.
-Interface : psci\_smc\_handler()
+Interface : psci_smc_handler()
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ::
@@ -270,8 +270,8 @@ PSCI API corresponding to ``smc_fid``. This function may not return back to the
 caller if PSCI API causes power down of the CPU. In this case, when the CPU
 wakes up, it will start execution from the warm reset address.
-Interface : psci\_warmboot\_entrypoint()
+Interface : psci_warmboot_entrypoint()
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ::
@@ -302,7 +302,7 @@ EL3 Runtime Software dependencies
 ---------------------------------
 The PSCI Library includes supporting frameworks like context management,
-cpu operations (cpu\_ops) and per-cpu data framework. Other helper library
+cpu operations (cpu_ops) and per-cpu data framework. Other helper library
 functions like bakery locks and spin locks are also included in the library.
 The dependencies which must be fulfilled by the EL3 Runtime Software
 for integration with PSCI library are described below.
@@ -323,7 +323,7 @@ these functions but the EL3 Runtime Software may use its own implementation.
 These must be implemented as described in ISO C Standard.
-**Function : flush\_dcache\_range()**
+**Function : flush_dcache_range()**
 ::
@@ -333,7 +333,7 @@ These must be implemented as described in ISO C Standard.
 This function cleans and invalidates (flushes) the data cache for memory
 at address ``addr`` (first argument) address and of size ``size`` (second argument).
-**Function : inv\_dcache\_range()**
+**Function : inv_dcache_range()**
 ::
@@ -343,7 +343,7 @@ at address ``addr`` (first argument) address and of size ``size`` (second argume
 This function invalidates (flushes) the data cache for memory at address
 ``addr`` (first argument) address and of size ``size`` (second argument).
-**Function : do\_panic()**
+**Function : do_panic()**
 ::
@@ -363,7 +363,7 @@ demonstrates how these APIs can be implemented but the EL3 Runtime Software can
 choose a more optimal implementation (like dedicating the secure TPIDRPRW
 system register (in AArch32) for storing these pointers).
-**Function : cm\_set\_context\_by\_index()**
+**Function : cm_set_context_by_index()**
 ::
@@ -384,7 +384,7 @@ The actual method of storing the ``context`` pointers is implementation specific
 For example, SP-MIN stores the pointers in the array ``sp_min_cpu_ctx_ptr``
 declared in ``sp_min_main.c``.
-**Function : cm\_get\_context()**
+**Function : cm_get_context()**
 ::
@@ -398,7 +398,7 @@ context pointers are stored prior to invoking this API. The ``security_state``
 will always be non-secure when called by PSCI library and this argument
 is retained for compatibility with BL31.
-**Function : cm\_get\_context\_by\_index()**
+**Function : cm_get_context_by_index()**
 ::
@@ -423,25 +423,25 @@ Runtime Software for integration with the PSCI library.
 The mandatory platform APIs are:
-  plat\_my\_core\_pos
+-  plat_my_core_pos
-  plat\_core\_pos\_by\_mpidr
+-  plat_core_pos_by_mpidr
-  plat\_get\_syscnt\_freq2
+-  plat_get_syscnt_freq2
-  plat\_get\_power\_domain\_tree\_desc
+-  plat_get_power_domain_tree_desc
-  plat\_setup\_psci\_ops
+-  plat_setup_psci_ops
-  plat\_reset\_handler
+-  plat_reset_handler
-  plat\_panic\_handler
+-  plat_panic_handler
-  plat\_get\_my\_stack
+-  plat_get_my_stack
 The mandatory platform macros are:
-  PLATFORM\_CORE\_COUNT
+-  PLATFORM_CORE_COUNT
-  PLAT\_MAX\_PWR\_LVL
+-  PLAT_MAX_PWR_LVL
-  PLAT\_NUM\_PWR\_DOMAINS
+-  PLAT_NUM_PWR_DOMAINS
-  CACHE\_WRITEBACK\_GRANULE
+-  CACHE_WRITEBACK_GRANULE
-  PLAT\_MAX\_OFF\_STATE
+-  PLAT_MAX_OFF_STATE
-  PLAT\_MAX\_RET\_STATE
+-  PLAT_MAX_RET_STATE
-  PLAT\_MAX\_PWR\_LVL\_STATES (optional)
+-  PLAT_MAX_PWR_LVL_STATES (optional)
-  PLAT\_PCPU\_DATA\_SIZE (optional)
+-  PLAT_PCPU_DATA_SIZE (optional)
 The details of these APIs/macros can be found in `Porting Guide`_.
@@ -486,50 +486,50 @@ enabled/re-targeted back to the current CPU.
 A brief description of each callback is given below:
-  svc\_on, svc\_off, svc\_on\_finish
+-  svc_on, svc_off, svc_on_finish
-   The ``svc_on``, ``svc_off`` callbacks are called during PSCI\_CPU\_ON,
+   The ``svc_on``, ``svc_off`` callbacks are called during PSCI_CPU_ON,
-   PSCI\_CPU\_OFF APIs respectively. The ``svc_on_finish`` is called when the
+   PSCI_CPU_OFF APIs respectively. The ``svc_on_finish`` is called when the
-   target CPU of PSCI\_CPU\_ON API powers up and executes the
+   target CPU of PSCI_CPU_ON API powers up and executes the
   ``psci_warmboot_entrypoint()`` PSCI library interface.
-  svc\_suspend, svc\_suspend\_finish
+-  svc_suspend, svc_suspend_finish
   The ``svc_suspend`` callback is called during power down bu either
-   PSCI\_SUSPEND or PSCI\_SYSTEM\_SUSPEND APIs. The ``svc_suspend_finish`` is
+   PSCI_SUSPEND or PSCI_SYSTEM_SUSPEND APIs. The ``svc_suspend_finish`` is
   called when the CPU wakes up from suspend and executes the
   ``psci_warmboot_entrypoint()`` PSCI library interface. The ``max_off_pwrlvl``
   (first parameter) denotes the highest power domain level being powered down
   to or woken up from suspend.
-  svc\_system\_off, svc\_system\_reset
+-  svc_system_off, svc_system_reset
-   These callbacks are called during PSCI\_SYSTEM\_OFF and PSCI\_SYSTEM\_RESET
+   These callbacks are called during PSCI_SYSTEM_OFF and PSCI_SYSTEM_RESET
   PSCI APIs respectively.
-  svc\_migrate\_info
+-  svc_migrate_info
-   This callback is called in response to PSCI\_MIGRATE\_INFO\_TYPE or
+   This callback is called in response to PSCI_MIGRATE_INFO_TYPE or
-   PSCI\_MIGRATE\_INFO\_UP\_CPU APIs. The return value of this callback must
+   PSCI_MIGRATE_INFO_UP_CPU APIs. The return value of this callback must
-   correspond to the return value of PSCI\_MIGRATE\_INFO\_TYPE API as described
+   correspond to the return value of PSCI_MIGRATE_INFO_TYPE API as described
   in `PSCI spec`_. If the secure payload is a Uniprocessor (UP)
   implementation, then it must update the mpidr of the CPU it is resident in
   via ``resident_cpu`` (first argument). The updates to ``resident_cpu`` is
   ignored if the secure payload is a multiprocessor (MP) implementation.
-  svc\_migrate
+-  svc_migrate
   This callback is only relevant if the secure payload in EL3 Runtime
   Software is a Uniprocessor (UP) implementation and supports migration from
   the current CPU ``from_cpu`` (first argument) to another CPU ``to_cpu``
-   (second argument). This callback is called in response to PSCI\_MIGRATE
+   (second argument). This callback is called in response to PSCI_MIGRATE
   API. This callback is never called if the secure payload is a
   Multiprocessor (MP) implementation.
 CPU operations
 ~~~~~~~~~~~~~~
-The CPU operations (cpu\_ops) framework implement power down sequence specific
+The CPU operations (cpu_ops) framework implement power down sequence specific
 to the CPU and the details of which can be found in the
 ``CPU specific operations framework`` section of `Firmware Design`_. The TF-A
 tree implements the ``cpu_ops`` for various supported CPUs and the EL3 Runtime

--- a/docs/rt-svc-writers-guide.rst
+++ b/docs/rt-svc-writers-guide.rst
@@ -91,7 +91,7 @@ TF-A has a `services`_ directory in the source tree under which
 each owning entity can place the implementation of its runtime service. The
 `PSCI`_ implementation is located here in the `lib/psci`_ directory.
-Runtime service sources will need to include the `runtime\_svc.h`_ header file.
+Runtime service sources will need to include the `runtime_svc.h`_ header file.
 Registering a runtime service
 -----------------------------
@@ -140,7 +140,7 @@ to ensure that the following conditions are met:
 #. The ``_type`` is one of ``SMC_TYPE_FAST`` or ``SMC_TYPE_YIELD``
 #. ``_setup`` and ``_smch`` routines have been specified
-`std\_svc\_setup.c`_ provides an example of registering a runtime service:
+`std_svc_setup.c`_ provides an example of registering a runtime service:
 .. code:: c
@@ -310,6 +310,6 @@ provide this information....
 .. _Firmware Design: ./firmware-design.rst
 .. _services: ../services
 .. _lib/psci: ../lib/psci
-.. _runtime\_svc.h: ../include/common/runtime_svc.h
+.. _runtime_svc.h: ../include/common/runtime_svc.h
 .. _smccc.h: ../include/lib/smccc.h
-.. _std\_svc\_setup.c: ../services/std_svc/std_svc_setup.c
+.. _std_svc_setup.c: ../services/std_svc/std_svc_setup.c
--- a/docs/trusted-board-boot.rst
+++ b/docs/trusted-board-boot.rst
@@ -59,7 +59,7 @@ The keys used to establish the CoT are:
 -  **Trusted world key**
   The private part is used to sign the key certificates corresponding to the
-   secure world images (SCP\_BL2, BL31 and BL32). The public part is stored in
+   secure world images (SCP_BL2, BL31 and BL32). The public part is stored in
   one of the extension fields in the trusted world certificate.
 -  **Non-trusted world key**
@@ -70,7 +70,7 @@ The keys used to establish the CoT are:
 -  **BL3-X keys**
-   For each of SCP\_BL2, BL31, BL32 and BL33, the private part is used to
+   For each of SCP_BL2, BL31, BL32 and BL33, the private part is used to
   sign the content certificate for the BL3-X image. The public part is stored
   in one of the extension fields in the corresponding key certificate.
@@ -78,7 +78,7 @@ The following images are included in the CoT:
 -  BL1
 -  BL2
-  SCP\_BL2 (optional)
+-  SCP_BL2 (optional)
 -  BL31
 -  BL33
 -  BL32 (optional)
@@ -96,14 +96,14 @@ The following certificates are used to authenticate the images.
   public part of the trusted world key and the public part of the non-trusted
   world key.
-  **SCP\_BL2 key certificate**
+-  **SCP_BL2 key certificate**
   It is self-signed with the trusted world key. It contains the public part of
-   the SCP\_BL2 key.
+   the SCP_BL2 key.
-  **SCP\_BL2 content certificate**
+-  **SCP_BL2 content certificate**
-   It is self-signed with the SCP\_BL2 key. It contains a hash of the SCP\_BL2
+   It is self-signed with the SCP_BL2 key. It contains a hash of the SCP_BL2
   image.
 -  **BL31 key certificate**
@@ -133,8 +133,8 @@ The following certificates are used to authenticate the images.
   It is self-signed with the BL33 key. It contains a hash of the BL33 image.
-The SCP\_BL2 and BL32 certificates are optional, but they must be present if the
+The SCP_BL2 and BL32 certificates are optional, but they must be present if the
-corresponding SCP\_BL2 or BL32 images are present.
+corresponding SCP_BL2 or BL32 images are present.
 Trusted Board Boot Sequence
 ---------------------------
@@ -160,8 +160,8 @@ if any of the steps fail.
   registers. If the comparison succeeds, BL2 reads and saves the trusted and
   non-trusted world public keys from the verified certificate.
-The next two steps are executed for each of the SCP\_BL2, BL31 & BL32 images.
+The next two steps are executed for each of the SCP_BL2, BL31 & BL32 images.
-The steps for the optional SCP\_BL2 and BL32 images are skipped if these images
+The steps for the optional SCP_BL2 and BL32 images are skipped if these images
 are not present.
 -  BL2 loads and verifies the BL3x key certificate. The certificate signature

--- a/docs/user-guide.rst
+++ b/docs/user-guide.rst
@@ -197,7 +197,7 @@ Building TF-A
   -  (AArch32 only) Currently only ``PLAT=fvp`` is supported.
   -  (AArch32 only) ``AARCH32_SP`` is the AArch32 EL3 Runtime Software and it
-      corresponds to the BL32 image. A minimal ``AARCH32_SP``, sp\_min, is
+      corresponds to the BL32 image. A minimal ``AARCH32_SP``, sp_min, is
      provided by TF-A to demonstrate how PSCI Library can be integrated with
      an AArch32 EL3 Runtime Software. Some AArch32 EL3 Runtime Software may
      include other runtime services, for example Trusted OS services. A guide
@@ -324,7 +324,7 @@ Common build options
   where applicable). Defaults to a string that contains the time and date of
   the compilation.
-  ``BUILD_STRING``: Input string for VERSION\_STRING, which allows the TF-A
+-  ``BUILD_STRING``: Input string for VERSION_STRING, which allows the TF-A
   build to be uniquely identified. Defaults to the current git commit id.
 -  ``CFLAGS``: Extra user options appended on the compiler's command line in
@@ -479,12 +479,12 @@ Common build options
 -  ``GENERATE_COT``: Boolean flag used to build and execute the ``cert_create``
   tool to create certificates as per the Chain of Trust described in
   `Trusted Board Boot`_. The build system then calls ``fiptool`` to
-   include the certificates in the FIP and FWU\_FIP. Default value is '0'.
+   include the certificates in the FIP and FWU_FIP. Default value is '0'.
   Specify both ``TRUSTED_BOARD_BOOT=1`` and ``GENERATE_COT=1`` to include support
   for the Trusted Board Boot feature in the BL1 and BL2 images, to generate
   the corresponding certificates, and to include those certificates in the
-   FIP and FWU\_FIP.
+   FIP and FWU_FIP.
   Note that if ``TRUSTED_BOARD_BOOT=0`` and ``GENERATE_COT=1``, the BL1 and BL2
   images will not include support for Trusted Board Boot. The FIP will still
@@ -492,7 +492,7 @@ Common build options
   Chain of Trust on the host machine through other mechanisms.
   Note that if ``TRUSTED_BOARD_BOOT=1`` and ``GENERATE_COT=0``, the BL1 and BL2
-   images will include support for Trusted Board Boot, but the FIP and FWU\_FIP
+   images will include support for Trusted Board Boot, but the FIP and FWU_FIP
   will not include the corresponding certificates, causing a boot failure.
 -  ``GICV2_G0_FOR_EL3``: Unlike GICv3, the GICv2 architecture doesn't have
@@ -566,7 +566,7 @@ Common build options
   specifies the file that contains the Non-Trusted World private key in PEM
   format. If ``SAVE_KEYS=1``, this file name will be used to save the key.
-  ``NS_BL2U``: Path to NS\_BL2U image in the host file system. This image is
+-  ``NS_BL2U``: Path to NS_BL2U image in the host file system. This image is
   optional. It is only needed if the platform makefile specifies that it
   is required in order to build the ``fwu_fip`` target.
@@ -611,7 +611,7 @@ Common build options
   to use the extended format. The default value of this flag is 0, which
   means by default the original power-state format is used by the PSCI
   implementation. This flag should be specified by the platform makefile
-   and it governs the return value of PSCI\_FEATURES API for CPU\_SUSPEND
+   and it governs the return value of PSCI_FEATURES API for CPU_SUSPEND
   smc function id. When this option is enabled on Arm platforms, the
   option ``ARM_RECOM_STATE_ID_ENC`` needs to be set to 1 as well.
@@ -629,10 +629,10 @@ Common build options
   entrypoint) or 1 (CPU reset to BL31 entrypoint).
   The default value is 0.
-  ``RESET_TO_SP_MIN``: SP\_MIN is the minimal AArch32 Secure Payload provided
+-  ``RESET_TO_SP_MIN``: SP_MIN is the minimal AArch32 Secure Payload provided
-   in TF-A. This flag configures SP\_MIN entrypoint as the CPU reset vector
+   in TF-A. This flag configures SP_MIN entrypoint as the CPU reset vector
   instead of the BL1 entrypoint. It can take the value 0 (CPU reset to BL1
-   entrypoint) or 1 (CPU reset to SP\_MIN entrypoint). The default value is 0.
+   entrypoint) or 1 (CPU reset to SP_MIN entrypoint). The default value is 0.
 -  ``ROT_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the
   file that contains the ROT private key in PEM format. If ``SAVE_KEYS=1``, this
@@ -642,15 +642,15 @@ Common build options
   certificate generation tool to save the keys used to establish the Chain of
   Trust. Allowed options are '0' or '1'. Default is '0' (do not save).
-  ``SCP_BL2``: Path to SCP\_BL2 image in the host file system. This image is optional.
+-  ``SCP_BL2``: Path to SCP_BL2 image in the host file system. This image is optional.
-   If a SCP\_BL2 image is present then this option must be passed for the ``fip``
+   If a SCP_BL2 image is present then this option must be passed for the ``fip``
   target.
 -  ``SCP_BL2_KEY``: This option is used when ``GENERATE_COT=1``. It specifies the
-   file that contains the SCP\_BL2 private key in PEM format. If ``SAVE_KEYS=1``,
+   file that contains the SCP_BL2 private key in PEM format. If ``SAVE_KEYS=1``,
   this file name will be used to save the key.
-  ``SCP_BL2U``: Path to SCP\_BL2U image in the host file system. This image is
+-  ``SCP_BL2U``: Path to SCP_BL2U image in the host file system. This image is
   optional. It is only needed if the platform makefile specifies that it
   is required in order to build the ``fwu_fip`` target.
@@ -689,7 +689,7 @@ Common build options
   Boot feature. When set to '1', BL1 and BL2 images include support to load
   and verify the certificates and images in a FIP, and BL1 includes support
   for the Firmware Update. The default value is '0'. Generation and inclusion
-   of certificates in the FIP and FWU\_FIP depends upon the value of the
+   of certificates in the FIP and FWU_FIP depends upon the value of the
   ``GENERATE_COT`` option.
   Note: This option depends on ``CREATE_KEYS`` to be enabled. If the keys
@@ -832,8 +832,8 @@ Arm CSS platform specific build options
   TF-A no longer supports earlier SCP versions. If this option is set to 1
   then TF-A will detect if an earlier version is in use. Default is 1.
-  ``CSS_LOAD_SCP_IMAGES``: Boolean flag, which when set, adds SCP\_BL2 and
+-  ``CSS_LOAD_SCP_IMAGES``: Boolean flag, which when set, adds SCP_BL2 and
-   SCP\_BL2U to the FIP and FWU\_FIP respectively, and enables them to be loaded
+   SCP_BL2U to the FIP and FWU_FIP respectively, and enables them to be loaded
   during boot. Default is 1.
 -  ``CSS_USE_SCMI_SDS_DRIVER``: Boolean flag which selects SCMI/SDS drivers
@@ -1087,7 +1087,7 @@ Trusted Board Boot primarily consists of the following two features:
 -  Image Authentication, described in `Trusted Board Boot`_, and
 -  Firmware Update, described in `Firmware Update`_
-The following steps should be followed to build FIP and (optionally) FWU\_FIP
+The following steps should be followed to build FIP and (optionally) FWU_FIP
 images with support for these features:
 #. Fulfill the dependencies of the ``mbedtls`` cryptographic and image parser
@@ -1150,13 +1150,13 @@ images with support for these features:
   described in the TBBR-client document. These certificates can also be found
   in the output build directory.
-#. The optional FWU\_FIP contains any additional images to be loaded from
+#. The optional FWU_FIP contains any additional images to be loaded from
   Non-Volatile storage during the `Firmware Update`_ process. To build the
-   FWU\_FIP, any FWU images required by the platform must be specified on the
+   FWU_FIP, any FWU images required by the platform must be specified on the
   command line. On Arm development platforms like Juno, these are:
-   -  NS\_BL2U. The AP non-secure Firmware Updater image.
+   -  NS_BL2U. The AP non-secure Firmware Updater image.
-   -  SCP\_BL2U. The SCP Firmware Update Configuration image.
+   -  SCP_BL2U. The SCP Firmware Update Configuration image.
   Example of Juno command line for generating both ``fwu`` and ``fwu_fip``
   targets using RSA development:
@@ -1173,15 +1173,15 @@ images with support for these features:
       NS_BL2U=<path-to>/<ns_bl2u_image>                               \
       all fip fwu_fip
-   Note: The BL2U image will be built by default and added to the FWU\_FIP.
+   Note: The BL2U image will be built by default and added to the FWU_FIP.
   The user may override this by adding ``BL2U=<path-to>/<bl2u_image>``
   to the command line above.
-   Note: Building and installing the non-secure and SCP FWU images (NS\_BL1U,
+   Note: Building and installing the non-secure and SCP FWU images (NS_BL1U,
-   NS\_BL2U and SCP\_BL2U) is outside the scope of this document.
+   NS_BL2U and SCP_BL2U) is outside the scope of this document.
-   The result of this build will be bl1.bin, fip.bin and fwu\_fip.bin binaries.
+   The result of this build will be bl1.bin, fip.bin and fwu_fip.bin binaries.
-   Both the FIP and FWU\_FIP will include the certificates corresponding to the
+   Both the FIP and FWU_FIP will include the certificates corresponding to the
   Chain of Trust described in the TBBR-client document. These certificates
   can also be found in the output build directory.
@@ -1198,7 +1198,7 @@ command:
    make PLAT=<platform> [DEBUG=1] [V=1] certtool
 For platforms that require their own IDs in certificate files, the generic
-'cert\_create' tool can be built with the following command:
+'cert_create' tool can be built with the following command:
 ::
@@ -1240,9 +1240,9 @@ section for more info on selecting the right FDT to use.
       make realclean
-#. Obtain SCP\_BL2 (Juno) and BL33 (all platforms)
+#. Obtain SCP_BL2 (Juno) and BL33 (all platforms)
-   Use the fiptool to extract the SCP\_BL2 and BL33 images from the FIP
+   Use the fiptool to extract the SCP_BL2 and BL33 images from the FIP
   package included in the Linaro release:
   ::
@@ -1255,7 +1255,7 @@ section for more info on selecting the right FDT to use.
            <path/to/linaro/release>/fip.bin
   The unpack operation will result in a set of binary images extracted to the
-   current working directory. The SCP\_BL2 image corresponds to
+   current working directory. The SCP_BL2 image corresponds to
   ``scp-fw.bin`` and BL33 corresponds to ``nt-fw.bin``.
   Note: The fiptool will complain if the images to be unpacked already
@@ -1406,7 +1406,7 @@ developing EL3 baremetal code by:
 -  putting the system into a known architectural state;
 -  taking care of platform secure world initialization;
-  loading the SCP\_BL2 image if required by the platform.
+-  loading the SCP_BL2 image if required by the platform.
 When booting an EL3 payload on Arm standard platforms, the configuration of the
 TrustZone controller is simplified such that only region 0 is enabled and is
@@ -1923,8 +1923,8 @@ Notes:
   ``--data="<path-to><bl32-binary>"@<base-address-of-bl32>`` to the new value of
   ``BL32_BASE``.
-Running on the AEMv8 Base FVP (AArch32) with reset to SP\_MIN entrypoint
+Running on the AEMv8 Base FVP (AArch32) with reset to SP_MIN entrypoint
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux
 with 8 CPUs using the AArch32 build of TF-A.
@@ -1991,8 +1991,8 @@ boot Linux with 8 CPUs using the AArch64 build of TF-A.
    --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000  \
    --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000
-Running on the Cortex-A32 Base FVP (AArch32) with reset to SP\_MIN entrypoint
+Running on the Cortex-A32 Base FVP (AArch32) with reset to SP_MIN entrypoint
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to
 boot Linux with 4 CPUs using the AArch32 build of TF-A.

--- a/docs/xlat-tables-lib-v2-design.rst
+++ b/docs/xlat-tables-lib-v2-design.rst
@@ -37,8 +37,8 @@ About version 1 and version 2
 -----------------------------
 This document focuses on version 2 of the library, whose sources are available
-in the `lib/xlat\_tables\_v2`_ directory. Version 1 of the library can still be
+in the `lib/xlat_tables_v2`_ directory. Version 1 of the library can still be
-found in `lib/xlat\_tables`_ directory but it is less flexible and doesn't
+found in `lib/xlat_tables`_ directory but it is less flexible and doesn't
 support dynamic mapping. Although potential bug fixes will be applied to both
 versions, future features enhancements will focus on version 2 and might not be
 back-ported to version 1. Therefore, it is recommended to use version 2,
@@ -69,7 +69,7 @@ map. It is one of the key interfaces to the library. It is identified by:
 - its attributes;
 - its mapping granularity (optional).
-See the ``struct mmap_region`` type in `xlat\_tables\_v2.h`_.
+See the ``struct mmap_region`` type in `xlat_tables_v2.h`_.
 The user usually provides a list of such mmap regions to map and lets the
 library transpose that in a set of translation tables. As a result, the library
@@ -80,7 +80,7 @@ normal memory) as well as the memory access permissions (read-only or
 read-write, executable or not, secure or non-secure, and so on). In the case of
 the EL1&0 translation regime, the attributes also specify whether the region is
 a User region (EL0) or Privileged region (EL1). See the ``MT_xxx`` definitions
-in `xlat\_tables\_v2.h`_. Note that for the EL1&0 translation regime the Execute
+in `xlat_tables_v2.h`_. Note that for the EL1&0 translation regime the Execute
 Never attribute is set simultaneously for both EL1 and EL0.
 The granularity controls the translation table level to go down to when mapping
@@ -208,7 +208,7 @@ Library APIs
 ------------
 The external APIs exposed by this library are declared and documented in the
-`xlat\_tables\_v2.h`_ header file. This should be the reference point for
+`xlat_tables_v2.h`_ header file. This should be the reference point for
 getting information about the usage of the different APIs this library
 provides. This section just provides some extra details and clarifications.
@@ -291,7 +291,7 @@ The library is divided into 4 modules:
  provides functions such as ``mmap_add_region_ctx`` that let the caller specify
  the translation tables context affected by them.
-  See `xlat\_tables\_core.c`_.
+  See `xlat_tables_core.c`_.
 - **Active context module**
@@ -300,14 +300,14 @@ The library is divided into 4 modules:
  This module provides functions such as ``mmap_add_region``, that directly
  affect the BL image using them.
-  See `xlat\_tables\_context.c`_.
+  See `xlat_tables_context.c`_.
 - **Utilities module**
  Provides additional functionality like debug print of the current state of the
  translation tables and helpers to query memory attributes and to modify them.
-  See `xlat\_tables\_utils.c`_.
+  See `xlat_tables_utils.c`_.
 - **Architectural module**
@@ -316,7 +316,7 @@ The library is divided into 4 modules:
  MMU, or calculate the Physical Address Space size. They do not need a
  translation context to work on.
-  See `aarch32/xlat\_tables\_arch.c`_ and `aarch64/xlat\_tables\_arch.c`_.
+  See `aarch32/xlat_tables_arch.c`_ and `aarch64/xlat_tables_arch.c`_.
 From mmap regions to translation tables
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -416,13 +416,13 @@ mapping cannot be cached in the TLBs.
 *Copyright (c) 2017-2018, Arm Limited and Contributors. All rights reserved.*
-.. _lib/xlat\_tables\_v2: ../lib/xlat_tables_v2
+.. _lib/xlat_tables_v2: ../lib/xlat_tables_v2
-.. _lib/xlat\_tables: ../lib/xlat_tables
+.. _lib/xlat_tables: ../lib/xlat_tables
-.. _xlat\_tables\_v2.h: ../include/lib/xlat_tables/xlat_tables_v2.h
+.. _xlat_tables_v2.h: ../include/lib/xlat_tables/xlat_tables_v2.h
-.. _xlat\_tables\_context.c: ../lib/xlat_tables_v2/xlat_tables_context.c
+.. _xlat_tables_context.c: ../lib/xlat_tables_v2/xlat_tables_context.c
-.. _xlat\_tables\_core.c: ../lib/xlat_tables_v2/xlat_tables_core.c
+.. _xlat_tables_core.c: ../lib/xlat_tables_v2/xlat_tables_core.c
-.. _xlat\_tables\_utils.c: ../lib/xlat_tables_v2/xlat_tables_utils.c
+.. _xlat_tables_utils.c: ../lib/xlat_tables_v2/xlat_tables_utils.c
-.. _aarch32/xlat\_tables\_arch.c: ../lib/xlat_tables_v2/aarch32/xlat_tables_arch.c
+.. _aarch32/xlat_tables_arch.c: ../lib/xlat_tables_v2/aarch32/xlat_tables_arch.c
-.. _aarch64/xlat\_tables\_arch.c: ../lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
+.. _aarch64/xlat_tables_arch.c: ../lib/xlat_tables_v2/aarch64/xlat_tables_arch.c
 .. _Porting Guide: porting-guide.rst
 .. |Alignment Example| image:: ./diagrams/xlat_align.png?raw=true