From: Matt Johnston <matt@codeconstruct.com.au>
To: devicetree@vger.kernel.org
Cc: Wolfram Sang <wsa@kernel.org>,
Jeremy Kerr <jk@codeconstruct.com.au>,
Matt Johnston <matt@codeconstruct.com.au>
Subject: [RFC PATCH 0/2] MCTP I2C devicetree binding
Date: Mon, 2 Aug 2021 12:04:56 +0800 [thread overview]
Message-ID: <20210802040458.334732-1-matt@codeconstruct.com.au> (raw)
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
next reply other threads:[~2021-08-02 4:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-02 4:04 Matt Johnston [this message]
2021-08-02 4:04 ` [RFC PATCH 1/2] dt-bindings: net: New binding for mctp-i2c Matt Johnston
2021-08-02 16:45 ` Rob Herring
2021-08-11 3:39 ` Matt Johnston
2021-08-13 16:29 ` Rob Herring
2021-08-02 4:04 ` [RFC PATCH 2/2] dt-bindings: net: Add mctp-i2c bus-attach property Matt Johnston
2021-08-02 13:39 ` Rob Herring
2021-08-02 19:26 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210802040458.334732-1-matt@codeconstruct.com.au \
--to=matt@codeconstruct.com.au \
--cc=devicetree@vger.kernel.org \
--cc=jk@codeconstruct.com.au \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.