Merge "fconf: Add namespace guidance inside documentation" into integration

diff --cc docs/components/fconf.rst
index 4ea1f5ba063dfc4a55ddec429c153a1457d8cc3d,0e0f0756f9722edc97546247c35d03ace7e5a327..385660083588fc4cfb2be476a7793bc039fdbd0f
--- 1/docs/components/fconf.rst
--- 2/docs/components/fconf.rst
+++ b/docs/components/fconf.rst
@@@ -96,6 -80,33 +96,33 @@@ Populating the propertie
  Once a valid device tree is available, the ``fconf_populate(config)`` function
  can be used to fill the C data structure with the data from the config |DTB|.
  This function will call all the ``populate()`` callbacks which have been
 -registered with ``FCONF_REGISTER_POPULATOR()``.
 +registered with ``FCONF_REGISTER_POPULATOR()`` as described above.
  
  .. uml:: ../resources/diagrams/plantuml/fconf_bl2_populate.puml
+ 
+ Namespace guidance
+ ~~~~~~~~~~~~~~~~~~
+ 
+ As mentioned above, properties are logically grouped around namespaces and
+ sub-namespaces. The following concepts should be considered when adding new
+ properties/namespaces.
+ The framework differentiates two types of properties:
+  - Properties used inside common code.
+  - Properties used inside platform specific code.
+ 
+ The first category applies to properties being part of the firmware and shared
+ across multiple platforms. They should be globally accessible and defined
+ inside the ``lib/fconf`` directory. The namespace must be chosen to reflect the
+ feature/data abstracted.
+ Example:
+  - |TBBR| related properties: tbbr.cot.bl2_id
+  - Dynamic configuration information: dyn_cfg.dtb_info.hw_config_id
+ 
+ The second category should represent the majority of the properties defined
+ within the framework: Platform specific properties. They must be accessed only
+ within the platform API and are defined only inside the platform scope. The
+ namespace must contain the platform name under which the properties defined
+ belong.
+ Example:
+  - Arm io framework: arm.io_policies.bl31_id
+