On Fri, 26 Oct 2018 16:43:28 +0200, Boris Brezillon wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
>
> Document this generic representation.
>
> Cc: Rob Herring <robh@xxxxxxxxxx>
> Signed-off-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxx>
> ---
> Changes in v10:
> - Fix mistakes in the example (reported by Rob)
>
> Changes in v9:
> - Rework the way we encode the I2C vs I3C device in the reg property
> so that we don't need the funky macros to define and I3C or I2C dev
> - Drop Rob's Reviewed-by
>
> Changes in v8:
> - None
>
> Changes in v7:
> - None
>
> Changes in v6:
> - None
>
> Changes in v5:
> - Add Rob's R-b
>
> Changes in v4:
> - Clarify the fact that static address == I3C address and dynamic
> address == I3C address
> - Use i2c-scl-hz in the example
>
> Changes in v3:
> - Rename {i2c,i3c}-scl-frequency DT prop into {i2c,i3c}-scl-hz
> - Rework the way we expose the provisional ID and LVR information
> - Rename dynamic-address into assigned-address
> - Enforce the I3C master node name
>
> Changes in v2:
> - Define how to describe I3C devices in the DT and when it should be
> used. Note that the parsing of I3C devices is not yet implemented in
> the framework. Will be added when someone really needs it.
> ---
> Documentation/devicetree/bindings/i3c/i3c.txt | 139 ++++++++++++++++++
> 1 file changed, 139 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
>
Reviewed-by: Rob Herring <robh@xxxxxxxxxx>
