diff --git a/docs/design/firmware-design.rst b/docs/design/firmware-design.rst
index 84bba18..36238a1 100644
--- a/docs/design/firmware-design.rst
+++ b/docs/design/firmware-design.rst
@@ -900,7 +900,7 @@
 A runtime service is registered using the ``DECLARE_RT_SVC()`` macro, specifying
 the name of the service, the range of OENs covered, the type of service and
 initialization and call handler functions. This macro instantiates a ``const struct rt_svc_desc`` for the service with these details (see ``runtime_svc.h``).
-This structure is allocated in a special ELF section ``rt_svc_descs``, enabling
+This structure is allocated in a special ELF section ``.rt_svc_descs``, enabling
 the framework to find all service descriptors included into BL31.
 
 The specific service for a SMC Function is selected based on the OEN and call
@@ -2165,7 +2165,7 @@
 has been redesigned. The changes utilise the characteristic of Lamport's Bakery
 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
+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
 and multiplying it with (PLATFORM_CORE_COUNT - 1). This enables software to
 perform software cache maintenance on the lock data structure without running
@@ -2193,7 +2193,7 @@
 
 ::
 
-    bakery_lock section start
+    .bakery_lock section start
     |----------------|
     | `bakery_info_t`| <-- Lock_0 per-CPU field
     |    Lock_0      |     for CPU0
@@ -2230,7 +2230,7 @@
 
 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
-``bakery_lock`` section need to be fetched and appropriate cache operations need
+``.bakery_lock`` section need to be fetched and appropriate cache operations need
 to be performed for each access.
 
 On Arm Platforms, bakery locks are used in psci (``psci_locks``) and power controller
diff --git a/docs/getting_started/porting-guide.rst b/docs/getting_started/porting-guide.rst
index 80b72e5..ec0a468 100644
--- a/docs/getting_started/porting-guide.rst
+++ b/docs/getting_started/porting-guide.rst
@@ -66,22 +66,22 @@
 If the build option ``USE_COHERENT_MEM`` is enabled, each platform can allocate a
 block of identity mapped secure memory with Device-nGnRE attributes aligned to
 page boundary (4K) for each BL stage. All sections which allocate coherent
-memory are grouped under ``coherent_ram``. For ex: Bakery locks are placed in a
-section identified by name ``bakery_lock`` inside ``coherent_ram`` so that its
+memory are grouped under ``.coherent_ram``. For ex: Bakery locks are placed in a
+section identified by name ``.bakery_lock`` inside ``.coherent_ram`` so that its
 possible for the firmware to place variables in it using the following C code
 directive:
 
 ::
 
-    __section("bakery_lock")
+    __section(".bakery_lock")
 
 Or alternatively the following assembler code directive:
 
 ::
 
-    .section bakery_lock
+    .section .bakery_lock
 
-The ``coherent_ram`` section is a sum of all sections like ``bakery_lock`` which are
+The ``.coherent_ram`` section is a sum of all sections like ``.bakery_lock`` which are
 used to allocate any data structures that are accessed both when a CPU is
 executing with its MMU and caches enabled, and when it's running with its MMU
 and caches disabled. Examples are given below.
@@ -2411,7 +2411,7 @@
 accommodate all the bakery locks.
 
 If this constant is not defined when ``USE_COHERENT_MEM = 0``, the linker
-calculates the size of the ``bakery_lock`` input section, aligns it to the
+calculates the size of the ``.bakery_lock`` input section, aligns it to the
 nearest ``CACHE_WRITEBACK_GRANULE``, multiplies it with ``PLATFORM_CORE_COUNT``
 and stores the result in a linker symbol. This constant prevents a platform
 from relying on the linker and provide a more efficient mechanism for
@@ -3540,7 +3540,7 @@
 
 --------------
 
-*Copyright (c) 2013-2022, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2013-2023, Arm Limited and Contributors. All rights reserved.*
 
 .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
 .. _Arm Generic Interrupt Controller version 2.0 (GICv2): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0048b/index.html