Hi!
[sorry for not responding to v1]
2022-08-22 at 11:10, luca.ceresoli@xxxxxxxxxxx wrote:
> From: Luca Ceresoli <luca.ceresoli@xxxxxxxxxxx>
>
> "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 <luca.ceresoli@xxxxxxxxxxx>
Acked-by: Peter Rosin <peda@xxxxxxxxxx>
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
