Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5347345ybi; Wed, 12 Jun 2019 00:40:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqykLK8mSRxlXnkdwhHSwH91BDT7rgV+wdl1GW5aREMJonuVXO4RyQP39ck/QUTt4Uh3SKhk X-Received: by 2002:a63:e70c:: with SMTP id b12mr15719925pgi.242.1560325222843; Wed, 12 Jun 2019 00:40:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560325222; cv=none; d=google.com; s=arc-20160816; b=uUw+OahK3egwdLWShxw3ZOop0KlW1QNUJ0MDUDkL4GfAdbx8wFq91bT7BlGC3ZPfkf TYRyAf5zCfAKYkGpiEPF5ZmRlezqIgELYgPIoJoHEPCV+xbZ3EiZOIfkKcnRPD1lVvpJ 5HZJ7SvVb37ANIGB7UKOtJY5cmqKTWblerw5D6AUrmtKFCcKtpPy3x/OFhpP5wSsB/DV +B7Z5khuSXtxaEt/rSbPmYmUcz0/hCSdV2Y3QrUJwPYAZco9L0l9FYBRQodql0PG8pgl PNBFVgmSYgXUHbjacEmGwWUjlJL3doDuGSBm98XATz5JO6ju/hV1eCoGhunTDsBS0IeF WdmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=eGUs/1LWz30ffQlDy2A7pz9mlGjmClqKYbBKQDZNwfE=; b=m9/7210KAzNQ5Q/HnZ8CPNpywzTFREsjvsi9QAT3RxyOHfMgtify3mn5zYfhWPViPj bhqtU5MH0hFkxh6KHOIolHzNSwxidF800WMwfokXVYIm6/ARjlisZ/eKUpMzAbC1Bh4p T8bwKi8eqWNPItE+SiGymym1nxZjdYHgJT3CB0Gj27fKDuh9ULK0mhzxYuzsjIwCEHQe ypIkvLdiwBbbXovg8YeW2r8EGgN3HW+VVple7vLl3o6T9idWamLiP92Yvp3qlp91jb46 T0EB1cSuU/AxjogOPT5ZDxzSj1zCiCKhuYa2iGPFD9a+8tryoAqDUfvpl7UINhNgSitJ JLEg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a64si9813128pge.116.2019.06.12.00.40.04; Wed, 12 Jun 2019 00:40:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408494AbfFLCqq (ORCPT + 99 others); Tue, 11 Jun 2019 22:46:46 -0400 Received: from mga14.intel.com ([192.55.52.115]:25730 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404957AbfFLCqq (ORCPT ); Tue, 11 Jun 2019 22:46:46 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2019 19:46:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,363,1557212400"; d="scan'208";a="184092883" Received: from haiyuewa-mobl.ccr.corp.intel.com (HELO [10.67.64.82]) ([10.67.64.82]) by fmsmga002.fm.intel.com with ESMTP; 11 Jun 2019 19:46:43 -0700 Subject: Re: [PATCHv7 1/3] dt-bindings: i2c: document bindings for i2c-slave-mqueue To: Rob Herring , Eduardo Valentin Cc: Wolfram Sang , jarkko.nikula@linux.intel.com, andriy.shevchenko@intel.com, brendanhiggins@google.com, Mark Rutland , linux-i2c@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20190605164651.15991-1-eduval@amazon.com> <20190605164651.15991-2-eduval@amazon.com> <20190611231425.GA29500@bogus> From: "Wang, Haiyue" Message-ID: Date: Wed, 12 Jun 2019 10:46:43 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190611231425.GA29500@bogus> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ?? 2019-06-12 07:14, Rob Herring ะด??: > On Wed, Jun 05, 2019 at 09:46:49AM -0700, Eduardo Valentin wrote: >> Document the i2c-slave-mqueue binding by adding >> descriptor, required properties, and example. >> >> Cc: Rob Herring >> Cc: Mark Rutland >> Cc: Wolfram Sang >> Cc: linux-i2c@vger.kernel.org >> Cc: devicetree@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Eduardo Valentin >> --- >> >> Changes from V6 to V7: >> - none >> >> .../bindings/i2c/i2c-slave-mqueue.txt | 34 +++++++++++++++++++ >> 1 file changed, 34 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt >> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt b/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt >> new file mode 100644 >> index 000000000000..eb1881a4fc0e >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt >> @@ -0,0 +1,34 @@ >> +=============================================== >> +Device Tree for I2C slave message queue backend >> +=============================================== >> + >> +Some protocols over I2C/SMBus are designed for bi-directional transferring >> +messages by using I2C Master Write protocol. This requires that both sides >> +of the communication have slave addresses. > So the address 0x10 in the example below is the address of the I2C > controller? > >> + >> +This I2C slave mqueue (message queue) is used to receive and queue Hi Rob, This is mqueue comes from, not from specs directly. >> +messages from the remote i2c intelligent device; and it will add the target >> +slave address (with R/W# bit is always 0) into the message at the first byte. >> + >> +Links >> +---- >> +`Intelligent Platform Management Bus >> +Communications Protocol Specification >> +`_ >> + >> +`Management Component Transport Protocol (MCTP) >> +SMBus/I2C Transport Binding Specification >> +`_ >> + >> +Required Properties: >> +- compatible : should be "i2c-slave-mqueue" > There is no mention of mqueue (or queue) in these specs. Where does that > come from? Perhaps something more closely matching the protocol would be > better name. > >> +- reg : slave address >> + >> +Example: >> + >> +i2c { > Would there be other slaves? > > The common binding states 'multi-master' property should be present. > > I need a more complete example. > >> + slave_mqueue: i2c-slave-mqueue { >> + compatible = "i2c-slave-mqueue"; >> + reg = <0x10>; Hi Eduardo, Looks like the slave reg missed the key value bit: https://elinux.org/images/f/f6/ELCE15-WolframSang-ShinyNewI2CSlaveFramework.pdf Example: reg = <(I2C_OWN_SLAVE_ADDRESS | 0x42)>; >> + }; >> +}; >> -- >> 2.21.0 >>