From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5087AC4320A for ; Thu, 26 Aug 2021 02:27:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 32336610C9 for ; Thu, 26 Aug 2021 02:27:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237533AbhHZC2K (ORCPT ); Wed, 25 Aug 2021 22:28:10 -0400 Received: from pi.codeconstruct.com.au ([203.29.241.158]:44924 "EHLO codeconstruct.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236800AbhHZC2K (ORCPT ); Wed, 25 Aug 2021 22:28:10 -0400 Received: from [192.168.12.102] (unknown [159.196.94.94]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id BD25B20134; Thu, 26 Aug 2021 10:27:21 +0800 (AWST) Message-ID: Subject: Re: [RFC PATCH v2 0/2] MCTP I2C devicetree binding From: Matt Johnston To: Rob Herring Cc: devicetree@vger.kernel.org, Wolfram Sang , Jeremy Kerr Date: Thu, 26 Aug 2021 10:27:21 +0800 In-Reply-To: References: <20210811034345.2424442-1-matt@codeconstruct.com.au> <0400d77489ba5350aefe576b91afb52cff3ebb48.camel@codeconstruct.com.au> <6ed12f1a09fb1f3e6ebe05992a9232bc7c34213c.camel@codeconstruct.com.au> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.0-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, 2021-08-23 at 11:16 -0500, Rob Herring wrote: > On Mon, Aug 23, 2021 at 2:52 AM Jeremy Kerr > wrote: > The issue here tends to be we design things based on not having nodes > in DT and then eventually evolve to the point where we should have had > a separate node. Connectors or per slot PCI properties are some > examples. Just something to keep in mind. When these are needed we can define a DT binding for endpoint devices, as a I2C client node. I've given the example 'mctp-device' below as a possible future binding. > > We're certainly open to other structures for flagging busses as > > MCTP-capable; we can use a more representative name for this phandle > > list, or switch to boolean properties on the subordinate nodes > > themselves (something like the gpio-controller boolean props, perhaps? > > though that seems harder to confine to a schema for mctp-i2c...) > > Either option is fine with me. A per bus property scales better (you > can add buses without changing the root MCTP node). We already have > per bus properties such as 'smbus' and 'multi-master'. How does this look, adding a property to the generic I2C bus? We'll define a 'mctp-controller' property that can be set on any I2C bus to flag it as having MCTP endpoints. A 'mctp-i2c-controller' binding client node is placed on the root bus to define the local I2C address, that needs to be present if any child mux busses have the mctp-controller property. So busses i2c1 and i2c6 will handle MCTP devices. We could omit mctp- controller from i2c1, in that case only i2c6 would have MCTP devices, though we still need the 'mctp-i2c-controller' at the root. i2c1: i2cbus1 {   compatible = "vendor,example-i2c-controller";   #address-cells = <1>;   #size-cells = <0>;   mctp-controller;   mctp@50 {     compatible = "mctp-i2c-controller";     reg = <(0x50 | I2C_OWN_SLAVE_ADDRESS)>;   }; }; i2cmux0 {   compatible = "vendor,example-i2c-mux";   #address-cells = <1>;   #size-cells = <0>;   i2c-parent = <&i2c1>;   i2c5: i2c@0 {     reg = <0>;     eeprom@33 {       compatible = "atmel,24c64";       reg = <0x33>;     };   };   i2c6: i2c@1 {     reg = <1>;     mctp-controller;     // A endpoint device can optionally be described in DT.     // (as an example, not defining it in this patch series)     nvme@0x20 {       compatible = "mctp-device";       reg = <0x20>;       // only accepts a fixed MCTP address, not using MCTP control protocol       mctp-fixed-address = 180;     };   }; }; Cheers, Matt