[PATCH BlueZ v1 2/2] doc: note RangingProvider1 objects are nested in bluetoothctl-cs

[Naga Bhavani Akella <naga.akella@oss.qualcomm.com>]

register_provider's exported RangingProvider1 objects live under
/org/example/ranging rather than directly under "/", to avoid a
gdbus/object.c bug when linking new top-level children of a path
that already has an ObjectManager attached. Document that alongside
the existing default-path note.
---
 doc/bluetoothctl-cs.rst | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/doc/bluetoothctl-cs.rst b/doc/bluetoothctl-cs.rst
index 08a7cafc1..c3d67fd2d 100644
--- a/doc/bluetoothctl-cs.rst
+++ b/doc/bluetoothctl-cs.rst
@@ -135,9 +135,11 @@ illustrative distance estimate (not an accurate measurement) exposed via
 
 The provider path defaults to ``/``, the only path bluetoothctl exposes an
 ``ObjectManager`` at; a different path will register but bluetoothd will not
-discover any objects under it. See **test/example-ranging-provider** for a
-minimal standalone provider skeleton, which reports a fixed placeholder
-distance and does not parse **ProcedureData** at all.
+discover any objects under it. The exported **RangingProvider1** objects
+themselves are nested under ``/org/example/ranging`` rather than directly
+under ``/``. See **test/example-ranging-provider** for a minimal standalone
+provider skeleton, which reports a fixed placeholder distance and does not
+parse **ProcedureData** at all.
 
 Only one ranging provider may be registered per adapter at a time. If a
 real ranging daemon is already registered, this command fails with
--