diff --git a/docs/arm-sip-service.rst b/docs/arm-sip-service.rst
index 9f0e266..6cdac83 100644
--- a/docs/arm-sip-service.rst
+++ b/docs/arm-sip-service.rst
@@ -4,7 +4,7 @@
 This document enumerates and describes the Arm SiP (Silicon Provider) services.
 
 SiP services are non-standard, platform-specific services offered by the silicon
-implementer or platform provider. They are accessed via. ``SMC`` ("SMC calls")
+implementer or platform provider. They are accessed via ``SMC`` ("SMC calls")
 instruction executed from Exception Levels below EL3. SMC calls for SiP
 services:
 
diff --git a/docs/exception-handling.rst b/docs/exception-handling.rst
index dbcd4bc..b7cd69d 100644
--- a/docs/exception-handling.rst
+++ b/docs/exception-handling.rst
@@ -233,7 +233,7 @@
    The ``ARRAY_SIZE()`` macro therefore should be used to determine the size of
    array.
 
-Finally, this array of descriptors is exposed to |EHF| via. the
+Finally, this array of descriptors is exposed to |EHF| via the
 ``EHF_REGISTER_PRIORITIES()`` macro.
 
 Refer to the `Interrupt handling example`_ for usage. See also: `Interrupt
@@ -379,8 +379,8 @@
 
 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, viz. SErrors or `SDEI explicit
-dispatches`__, this has to be done via. calling ``ehf_activate_priority()``. See
+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
@@ -388,7 +388,7 @@
 Conversely, when the dispatcher has reached a logical resolution for the cause
 of the exception, the corresponding priority level ought to be deactivated. As
 above, for interrupts, this is implied when the interrupt is EOId in the GIC;
-for other exceptions, this has to be done via. calling
+for other exceptions, this has to be done via calling
 ``ehf_deactivate_priority()``.
 
 Thanks to `different provisions`__ for exception delegation, there are
@@ -405,7 +405,7 @@
 
 -  The dispatcher has to delegate the execution to lower ELs, and the cause of
    the exception can be considered resolved only when the lower EL returns
-   signals complete (via. an ``SMC``) at a future point in time. The following
+   signals complete (via an ``SMC``) at a future point in time. The following
    sequence ensues:
 
    #. The dispatcher calls ``setjmp()`` to setup a jump point, and arranges to
@@ -414,7 +414,7 @@
    #. Through the ensuing ``ERET`` from runtime firmware, execution is delegated
       to a lower EL.
 
-   #. The lower EL completes its execution, and signals completion via. an
+   #. The lower EL completes its execution, and signals completion via an
       ``SMC``.
 
    #. The ``SMC`` is handled by the same dispatcher that handled the exception
@@ -597,7 +597,7 @@
 dispatchers through |EHF|.
 
 As mentioned in `Partitioning priority levels`_, interrupts targeting distinct
-dispatchers fall in distinct priority levels. Because they're routed via. the
+dispatchers fall in distinct priority levels. Because they're routed via the
 GIC, interrupt delivery to the PE is subject to GIC prioritisation rules. In
 particular, when an interrupt is being handled by the PE (i.e., the interrupt is
 in *Active* state), only interrupts of higher priority are signalled to the PE,
diff --git a/docs/firmware-design.rst b/docs/firmware-design.rst
index ead7297..266de27 100644
--- a/docs/firmware-design.rst
+++ b/docs/firmware-design.rst
@@ -1282,9 +1282,9 @@
 Secure interrupt configuration are specified in an array of secure interrupt
 properties. In this scheme, in both GICv2 and GICv3 driver data structures, the
 ``interrupt_props`` member points to an array of interrupt properties. Each
-element of the array specifies the interrupt number and its configuration, viz.
-priority, group, configuration. Each element of the array shall be populated by
-the macro ``INTR_PROP_DESC()``. The macro takes the following arguments:
+element of the array specifies the interrupt number and its attributes
+(priority, group, configuration). Each element of the array shall be populated
+by the macro ``INTR_PROP_DESC()``. The macro takes the following arguments:
 
 - 10-bit interrupt number,
 
@@ -1439,7 +1439,7 @@
 
 CPU drivers that apply errata workaround can optionally implement an assembly
 function that report the status of errata workarounds pertaining to that CPU.
-For a driver that registers the CPU, for example, ``cpux`` via. ``declare_cpu_ops``
+For a driver that registers the CPU, for example, ``cpux`` via ``declare_cpu_ops``
 macro, the errata reporting function, if it exists, must be named
 ``cpux_errata_report``. This function will always be called with MMU enabled; it
 must follow AAPCS and may use stack.
diff --git a/docs/platform-interrupt-controller-API.rst b/docs/platform-interrupt-controller-API.rst
index 230a990..ad68709 100644
--- a/docs/platform-interrupt-controller-API.rst
+++ b/docs/platform-interrupt-controller-API.rst
@@ -22,7 +22,7 @@
 
 This API should return the priority of the interrupt the PE is currently
 servicing. This must be be called only after an interrupt has already been
-acknowledged via. ``plat_ic_acknowledge_interrupt``.
+acknowledged via ``plat_ic_acknowledge_interrupt``.
 
 In the case of Arm standard platforms using GIC, the *Running Priority Register*
 is read to determine the priority of the interrupt.
diff --git a/docs/porting-guide.rst b/docs/porting-guide.rst
index c3df389..3ea86b0 100644
--- a/docs/porting-guide.rst
+++ b/docs/porting-guide.rst
@@ -1936,7 +1936,7 @@
 
 The ``power-state`` parameter of a PSCI ``CPU_SUSPEND`` call can be used to
 describe composite power states specific to a platform. The PSCI implementation
-defines a generic representation of the power-state parameter viz which is an
+defines a generic representation of the power-state parameter, which is an
 array of local power states where each index corresponds to a power domain
 level. Each entry contains the local power state the power domain at that power
 level could enter. It depends on the ``validate_power_state()`` handler to
diff --git a/docs/ras.rst b/docs/ras.rst
index cea74e9..ac4d019 100644
--- a/docs/ras.rst
+++ b/docs/ras.rst
@@ -15,10 +15,10 @@
 later CPUs, and also an optional extension to the base Armv8.0 architecture.
 
 In conjunction with the |EHF|, support for RAS extension enables firmware-first
-paradigm for handling platform errors, in which exceptions resulting from
-errors—viz. Synchronous External Abort (SEA), Asynchronous External Abort
-(signalled as SErrors), Fault Handling and Error Recovery interrupts are routed
-to and handled in EL3. The |EHF| document mentions various `error handling
+paradigm for handling platform errors: exceptions resulting from errors are
+routed to and handled in EL3. Said errors are Synchronous External Abort (SEA),
+Asynchronous External Abort (signalled as SErrors), Fault Handling and Error
+Recovery interrupts.  The |EHF| document mentions various `error handling
 use-cases`__.
 
 .. __: exception-handling.rst#delegation-use-cases
@@ -66,7 +66,7 @@
 nodes contain one or more error records, which are registers through which the
 nodes advertise various properties of the signalled error. Arm recommends that
 error records are implemented in the Standard Error Record format. The RAS
-architecture allows for error records to be accessible via. system or
+architecture allows for error records to be accessible via system or
 memory-mapped registers.
 
 The platform should enumerate the error records providing for each of them:
@@ -121,7 +121,7 @@
                int probe_data, const struct err_handler_data *const data);
 
 The ``data`` constant parameter describes the various properties of the error,
-viz. the reason for the error, exception syndrome, and also ``flags``,
+including the reason for the error, exception syndrome, and also ``flags``,
 ``cookie``, and ``handle`` parameters from the `top-level exception handler`__.
 
 .. __: interrupt-framework-design.rst#el3-interrupts
diff --git a/docs/sdei.rst b/docs/sdei.rst
index 531145f..c524817 100644
--- a/docs/sdei.rst
+++ b/docs/sdei.rst
@@ -142,7 +142,7 @@
 .. __: `Defining events`_
 
 -  ``SDEI_MAPF_DYNAMIC``: Marks the event as dynamic. Dynamic events can be
-   bound to (or released from) any Non-secure interrupt at runtime via. the
+   bound to (or released from) any Non-secure interrupt at runtime via the
    ``SDEI_INTERRUPT_BIND`` and ``SDEI_INTERRUPT_RELEASE`` calls.
 
 -  ``SDEI_MAPF_BOUND``: Marks the event as statically bound to an interrupt.
@@ -226,7 +226,7 @@
 Typically, an SDEI event dispatch is caused by the PE receiving interrupts that
 are bound to an SDEI event. However, there are cases where the Secure world
 requires dispatch of an SDEI event as a direct or indirect result of a past
-activity, viz. receiving a Secure interrupt or an exception.
+activity, such as receiving a Secure interrupt or an exception.
 
 The SDEI dispatcher implementation provides ``sdei_dispatch_event()`` API for
 this purpose. The API has the following signature:
diff --git a/docs/user-guide.rst b/docs/user-guide.rst
index b420127..b602956 100644
--- a/docs/user-guide.rst
+++ b/docs/user-guide.rst
@@ -548,13 +548,13 @@
 
 -  ``KEY_ALG``: This build flag enables the user to select the algorithm to be
    used for generating the PKCS keys and subsequent signing of the certificate.
-   It accepts 3 values viz. ``rsa``, ``rsa_1_5``, ``ecdsa``. The ``rsa_1_5`` is
-   the legacy PKCS#1 RSA 1.5 algorithm which is not TBBR compliant and is
-   retained only for compatibility. The default value of this flag is ``rsa``
-   which is the TBBR compliant PKCS#1 RSA 2.1 scheme.
+   It accepts 3 values: ``rsa``, ``rsa_1_5`` and ``ecdsa``. The option
+   ``rsa_1_5`` is the legacy PKCS#1 RSA 1.5 algorithm which is not TBBR
+   compliant and is retained only for compatibility. The default value of this
+   flag is ``rsa`` which is the TBBR compliant PKCS#1 RSA 2.1 scheme.
 
 -  ``HASH_ALG``: This build flag enables the user to select the secure hash
-   algorithm. It accepts 3 values viz. ``sha256``, ``sha384``, ``sha512``.
+   algorithm. It accepts 3 values: ``sha256``, ``sha384`` and ``sha512``.
    The default value of this flag is ``sha256``.
 
 -  ``LDFLAGS``: Extra user options appended to the linkers' command line in
@@ -619,14 +619,14 @@
    does not need to be implemented in this case.
 
 -  ``PSCI_EXTENDED_STATE_ID``: As per PSCI1.0 Specification, there are 2 formats
-   possible for the PSCI power-state parameter viz original and extended
-   State-ID formats. This flag if set to 1, configures the generic PSCI layer
-   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
-   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.
+   possible for the PSCI power-state parameter: original and extended State-ID
+   formats. This flag if set to 1, configures the generic PSCI layer 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 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.
 
 -  ``RAS_EXTENSION``: When set to ``1``, enable Armv8.2 RAS features. RAS features
    are an optional extension for pre-Armv8.2 CPUs, but are mandatory for Armv8.2