[RFC PATCH 0/2] MCTP I2C devicetree binding
flat view
STALE1891d
SUPERSEDED
From: Matt Johnston <matt@codeconstruct.com.au>
Date: 2021-08-02 04:12:52
Revision rfc of 2 in this series.
Revisions (2)
- rfc current
- v2 [diff vs current]
Hi,
These patches are an RFC for a devicetree binding for MCTP-over-I2C
hardware, where MCTP messages are transferred as SMBus block writes. For
this, we need to encode a little dt data about the hardware
configuration, specifically:
1) which controllers are MCTP endpoints (ie, may host MCTP I2C clients
downstream); and
2) the SMBus address of the local MCTP endpoint, which can act as an
I2C slave device
In order to represent this configuration, we've added a binding for a
node that will exist under a root-level i2c controller. This indicates
(1), and provides the address required for (2). For a fictional hardware
i2c controller:
/* for I2C_OWN_SLAVE_ADDRESS */
#include <dt-bindings/i2c/i2c.h>
/* root-level i2c controller */
i2c {
compatible = "vendor,example-i2c-controller";
reg = <...>
#address-cells = <1>;
#size-cells = <0>;
mctp@50 {
compatible = "mctp-i2c";
reg = <(0x50 | I2C_OWN_SLAVE_ADDRESS)>;
};
};
This gets a little trickier when i2c muxes are present between the
top-level controller and MCTP endpoints, as we need to specify the
downstream mux ports that may host MCTP endpoints (which allows an OS
implementation to correctly address devices which require a specific mux
state to be configured). For this, we introduce the bus-attach property
on the root-level node, which indicates subordinate i2c busses that may
host MCTP endpoints:
i2c5: i2cbus5 {
#address-cells = <1>;
#size-cells = <0>;
mctp@50 {
compatible = "mctp-i2c";
reg = <(0x50 | I2C_OWN_SLAVE_ADDRESS)>;
/* MCTP endpoints behind this controller and the mux port at i2c14 */
attach-bus = <&i2c5 &i2c14>;
};
};
i2cmux0 {
compatible = "i2c-mux-gpio";
#address-cells = <1>;
#size-cells = <0>;
i2c-parent = <&i2c5>;
i2c14: i2c@5 {
reg = <0>;
};
};
- where an absent attach-bus property implies that only the top-level
controller will host MCTP devices.
An operating system consuming these nodes may want to create a MCTP
interface device for each of the mux ports in the topology.
An alternative approach we considered: A pure property-based spec could
represent the MCTP capability of an i2c controller through top-level
properties instead:
i2c {
compatible = "mctp-i2c-controller", "vendor,example-i2c-controller";
reg = <...>
#address-cells = <1>;
#size-cells = <0>;
/* presence required by the 'mctp-i2c-controller' binding */
mctp-i2c-address = <0x50>;
};
(like the above, the i2c controller here will both be available for
standard i2c transactions as well as MCTP messaging)
and downstream MCTP-capable busses indicated with a boolean property:
i2cmux0 {
compatible = "i2c-mux-gpio";
#address-cells = <1>;
#size-cells = <0>;
i2c-parent = <&i2c5>;
i2c@5 {
/* indicates that this subordinate bus hosts MCTP endpoints */
mctp-i2c-controller;
};
};
However, this doesn't quite fit with the existing i2c client bindings
(using I2C_OWN_SLAVE_ADDRESS), which uses a distinct node for the
local client endpoint. So, we have decided on the node-base approach.
Cheers,
Matt
Matt Johnston (2):
dt-bindings: net: New binding for mctp-i2c
dt-bindings: net: Add mctp-i2c bus-attach property
.../devicetree/bindings/net/mctp-i2c.yaml | 78 +++++++++++++++++++
1 file changed, 78 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mctp-i2c.yaml
--
2.30.2