Skip to contentSkip to conversation

dt-bindings: net: New binding mctp-i2c-controller

PATCH In review Matt Johnston 3 participants 3 messages Sep 23, 2021 – Sep 29, 2021

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH v4 1/1 dt-bindings: net: New binding mctp-i2c-controller

Used to define a local endpoint to communicate with MCTP peripherals attached to an I2C bus. This I2C endpoint can communicate with remote MCTP devices on the I2C bus.

In the example I2C topology below (matching the second yaml example) we have MCTP devices on busses i2c1 and i2c6. MCTP-supporting busses are indicated by the 'mctp-controller' DT property on an I2C bus node.

A mctp-i2c-controller I2C client DT node is placed at the top of the mux topology, since only the root I2C adapter will support I2C slave functionality.

                                               .-------.
                                               |eeprom |
    .------------.     .------.               /'-------'
    | adapter    |     | mux  --@0,i2c5------'
    | i2c1       ----.*|      --@1,i2c6--.--.
    |............|    \'------'           \  \  .........
    | mctp-i2c-  |     \                   \  \ .mctpB  .
    | controller |      \                   \  '.0x30   .
    |            |       \  .........        \  '.......'
    | 0x50       |        \ .mctpA  .         \ .........
    '------------'         '.0x1d   .          '.mctpC  .
                            '.......'          '.0x31   .
                                                '.......'

(mctpX boxes above are remote MCTP devices not included in the DT at present, they can be hotplugged/probed at runtime. A DT binding for specific fixed MCTP devices could be added later if required)

---

Changes:

v3->v4:
Formatting and YAML syntax fixes, rename .yaml file to match

v2->v3:
Change the MCTP indicator to being a property on the I2C bus node.

Thanks,
Matt

 Documentation/devicetree/bindings/i2c/i2c.txt |  4 +
 .../bindings/net/mctp-i2c-controller.yaml     | 92 +++++++++++++++++++
 2 files changed, 96 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml
Documentation/devicetree/bindings/i2c/i2c.txt +4 -0
index b864916e087f..fc3dd7ec0445 100644
@@ -95,6 +95,10 @@ wants to support one of the below features, it should adapt these bindings.
 - smbus-alert
 	states that the optional SMBus-Alert feature apply to this bus.
 
+- mctp-controller
+	indicates that the system is accessible via this bus as an endpoint for
+	MCTP over I2C transport.
+
 Required properties (per child device)
 --------------------------------------
 
Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml new file +92 -0

92 lines not on this page · raw message

Signature · 1 line
2.30.2
maintainer Reviewed-by on v4 1/1
#1 lore raw
Quoted 39 lines · Matt Johnston

Used to define a local endpoint to communicate with MCTP peripherals attached to an I2C bus. This I2C endpoint can communicate with remote MCTP devices on the I2C bus.

In the example I2C topology below (matching the second yaml example) we have MCTP devices on busses i2c1 and i2c6. MCTP-supporting busses are indicated by the 'mctp-controller' DT property on an I2C bus node.

A mctp-i2c-controller I2C client DT node is placed at the top of the mux topology, since only the root I2C adapter will support I2C slave functionality.

                                               .-------.
                                               |eeprom |
    .------------.     .------.               /'-------'
    | adapter    |     | mux  --@0,i2c5------'
    | i2c1       ----.*|      --@1,i2c6--.--.
    |............|    \'------'           \  \  .........
    | mctp-i2c-  |     \                   \  \ .mctpB  .
    | controller |      \                   \  '.0x30   .
    |            |       \  .........        \  '.......'
    | 0x50       |        \ .mctpA  .         \ .........
    '------------'         '.0x1d   .          '.mctpC  .
                            '.......'          '.0x31   .
                                                '.......'

(mctpX boxes above are remote MCTP devices not included in the DT at present, they can be hotplugged/probed at runtime. A DT binding for specific fixed MCTP devices could be added later if required)

---

Changes:

v3->v4:
Formatting and YAML syntax fixes, rename .yaml file to match

v2->v3:
Change the MCTP indicator to being a property on the I2C bus node.

Quoted 8 lines

Thanks,
Matt

 Documentation/devicetree/bindings/i2c/i2c.txt |  4 +
 .../bindings/net/mctp-i2c-controller.yaml     | 92 +++++++++++++++++++
 2 files changed, 96 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml
Acked-by on v4 1/1
#2 lore raw
In reply to Matt Johnston
Quoted 24 lines · Matt Johnston

Used to define a local endpoint to communicate with MCTP peripherals attached to an I2C bus. This I2C endpoint can communicate with remote MCTP devices on the I2C bus.

In the example I2C topology below (matching the second yaml example) we have MCTP devices on busses i2c1 and i2c6. MCTP-supporting busses are indicated by the 'mctp-controller' DT property on an I2C bus node.

A mctp-i2c-controller I2C client DT node is placed at the top of the mux topology, since only the root I2C adapter will support I2C slave functionality.

                                               .-------.
                                               |eeprom |
    .------------.     .------.               /'-------'
    | adapter    |     | mux  --@0,i2c5------'
    | i2c1       ----.*|      --@1,i2c6--.--.
    |............|    \'------'           \  \  .........
    | mctp-i2c-  |     \                   \  \ .mctpB  .
    | controller |      \                   \  '.0x30   .
    |            |       \  .........        \  '.......'
    | 0x50       |        \ .mctpA  .         \ .........
    '------------'         '.0x1d   .          '.mctpC  .
                            '.......'          '.0x31   .
                                                '.......'
Quoted 5 lines

(mctpX boxes above are remote MCTP devices not included in the DT at present, they can be hotplugged/probed at runtime. A DT binding for specific fixed MCTP devices could be added later if required)