From: Luca Ceresoli <[email protected]>
"Etc" here was never meant to be a heading, it became one while converting
to ReST.
It would be easy to just convert it to plain text, but rather remove it and
add an introductory text before the list that conveys the same meaning but
with a better reading flow.
Fixes: ccf988b66d69 ("docs: i2c: convert to ReST and add to driver-api bookset")
Signed-off-by: Luca Ceresoli <[email protected]>
---
Changed in v2: none
---
Documentation/i2c/i2c-topology.rst | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/i2c/i2c-topology.rst b/Documentation/i2c/i2c-topology.rst
index 7cb53819778e..1b11535c8946 100644
--- a/Documentation/i2c/i2c-topology.rst
+++ b/Documentation/i2c/i2c-topology.rst
@@ -5,6 +5,8 @@ I2C muxes and complex topologies
There are a couple of reasons for building more complex I2C topologies
than a straight-forward I2C bus with one adapter and one or more devices.
+Some example use cases are:
+
1. A mux may be needed on the bus to prevent address collisions.
2. The bus may be accessible from some external bus master, and arbitration
@@ -14,9 +16,6 @@ than a straight-forward I2C bus with one adapter and one or more devices.
from the I2C bus, at least most of the time, and sits behind a gate
that has to be operated before the device can be accessed.
-Etc
-===
-
These constructs are represented as I2C adapter trees by Linux, where
each adapter has a parent adapter (except the root adapter) and zero or
more child adapters. The root adapter is the actual adapter that issues
--
2.34.1
Hi!
[sorry for not responding to v1]
2022-08-22 at 11:10, [email protected] wrote:
> From: Luca Ceresoli <[email protected]>
>
> "Etc" here was never meant to be a heading, it became one while converting
> to ReST.
>
> It would be easy to just convert it to plain text, but rather remove it and
> add an introductory text before the list that conveys the same meaning but
> with a better reading flow.
>
> Fixes: ccf988b66d69 ("docs: i2c: convert to ReST and add to driver-api bookset")
> Signed-off-by: Luca Ceresoli <[email protected]>
Acked-by: Peter Rosin <[email protected]>
Cheers,
Peter
>
> ---
>
> Changed in v2: none
> ---
> Documentation/i2c/i2c-topology.rst | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/i2c/i2c-topology.rst b/Documentation/i2c/i2c-topology.rst
> index 7cb53819778e..1b11535c8946 100644
> --- a/Documentation/i2c/i2c-topology.rst
> +++ b/Documentation/i2c/i2c-topology.rst
> @@ -5,6 +5,8 @@ I2C muxes and complex topologies
> There are a couple of reasons for building more complex I2C topologies
> than a straight-forward I2C bus with one adapter and one or more devices.
>
> +Some example use cases are:
> +
> 1. A mux may be needed on the bus to prevent address collisions.
>
> 2. The bus may be accessible from some external bus master, and arbitration
> @@ -14,9 +16,6 @@ than a straight-forward I2C bus with one adapter and one or more devices.
> from the I2C bus, at least most of the time, and sits behind a gate
> that has to be operated before the device can be accessed.
>
> -Etc
> -===
> -
> These constructs are represented as I2C adapter trees by Linux, where
> each adapter has a parent adapter (except the root adapter) and zero or
> more child adapters. The root adapter is the actual adapter that issues