Received: by 10.213.65.68 with SMTP id h4csp186330imn; Wed, 28 Mar 2018 01:21:00 -0700 (PDT) X-Google-Smtp-Source: AIpwx48I4+61rf7/Gk6Z0twEmUyDI0erb9jbGG9VSE+STr9/cRadzxRuM37JPjet+/9iLpTQ8aqH X-Received: by 10.101.70.8 with SMTP id v8mr1874354pgq.336.1522225260049; Wed, 28 Mar 2018 01:21:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522225260; cv=none; d=google.com; s=arc-20160816; b=ZinfD166xy/MSUhtX7XQGAdW9wcTo8QGWCodje82XWrD494JhqUWSz0z3ui2AyLjpE w4dhC5qNcSmD2VEbghbX1IUWNSQYo3LCp0aOrgNEsotaK5JMeWiLOW0WA0GtfiDCP5on NqO9F7djjmK0wWs86d+0AuRFH55LtU0lTGDzw2Z+NFKLL3KlTZb+4tKS5nAbufc93QzF eYTeSD99Kjs3OreEKPstisb9UdqkIJ/OoPE5wNX8MJiYSsJ1Hz81SlD4wgj0Q+SKv6bR Zjh3+4TdHhGwfYrDSrFznbgtYDMictKvRglH2X6FrCtxxwQQK/lCsBlre32kTlmwUvtT h/Rg== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=6gGvTkVp3BzvfGmgvF4KrGCIk6BWosA3cbhMWtAA3nY=; b=bOeTuSizPFC43geOa3W6cSFKrbIvSDueMJ9nIlqLpIE2UxEqQv+IZpiyR6GnLv0VrA tHgd6k4s2rdt2rHZ74NOjdqqwfrBpnShDI7rtVQXLpDVsyx4Ffsa4HMem2r70u/O8+jz NUNHDdGoWGyWDTJSl/YdFsEWNnSNTTzneLXOraOzLfXyPtKNrZ+B8khxEW3VZs8epFIj QAZxyKXIFy4T6tSm7Nxnwe9zX2LgidAegk+B1boRzYUOm1+LRyDdDu0OZofbeLp2PgFw ddgUkLJ2Lep9+gtnB/TGWgoq6QS0za4U3Sjz/U9B7f+5v3vn3JMXBuekY9sia3GtArs/ LW+Q== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a69-v6si3119096pli.581.2018.03.28.01.20.44; Wed, 28 Mar 2018 01:21:00 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752620AbeC1ITo (ORCPT + 99 others); Wed, 28 Mar 2018 04:19:44 -0400 Received: from mail.bootlin.com ([62.4.15.54]:50186 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752144AbeC1ITh (ORCPT ); Wed, 28 Mar 2018 04:19:37 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 4EAAE2055E; Wed, 28 Mar 2018 10:19:33 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.bootlin.com (Postfix) with ESMTPSA id 5D4FE2055E; Wed, 28 Mar 2018 10:19:22 +0200 (CEST) Date: Wed, 28 Mar 2018 10:19:22 +0200 From: Boris Brezillon To: Rob Herring Cc: Wolfram Sang , linux-i2c@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Greg Kroah-Hartman , Arnd Bergmann , Przemyslaw Sroka , Arkadiusz Golec , Alan Douglas , Bartosz Folta , Damian Kos , Alicja Jurasik-Urbaniak , Cyprian Wronka , Suresh Punnoose , Rafal Ciepiela , Thomas Petazzoni , Nishanth Menon , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Vitor Soares , Geert Uytterhoeven , Linus Walleij , Xiang Lin , linux-gpio@vger.kernel.org, Boris Brezillon Subject: Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings Message-ID: <20180328101922.22a7039d@bbrezillon> In-Reply-To: <20180326071946.dtrhhxx3iwwymk73@rob-hp-laptop> References: <20180323110020.19080-1-boris.brezillon@bootlin.com> <20180323110020.19080-6-boris.brezillon@bootlin.com> <20180326071946.dtrhhxx3iwwymk73@rob-hp-laptop> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On Mon, 26 Mar 2018 17:24:58 -0500 Rob Herring wrote: > > + > > +I3C devices > > +=========== > > + > > +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and > > +are thus discoverable. So, by default, I3C devices do not have to be described > > +in the device tree. > > +This being said, one might want to attach extra resources to these devices, > > +and those resources may have to be described in the device tree, which in turn > > +means we have to describe I3C devices. > > + > > +Another use case for describing an I3C device in the device tree is when this > > +I3C device has a static address and we want to assign it a specific dynamic > > +address before the DAA takes place (so that other devices on the bus can't > > static is I2C address and dynamic is an I3C address. That could be > clearer throughout. I'll clarify that. > > > +take this dynamic address). > > + > > +The I3C device should be names @,, > > s/static-address/static-i2c-address/ Okay. > > > +where device-type is describing the type of device connected on the bus > > +(gpio-controller, sensor, ...). > > + > > +Required properties > > +------------------- > > +- reg: contains 3 cells > > + + first cell : encodes the I2C address. Should be 0 if the device does not > > + have one (0 is not a valid I3C address). > > Change here to "encodes the static I2C address". > > 0 is not a valid I2C address? According to [1] it is reserved, and it's reserved in the I3C spec anyway (see "Table 9 I3C Slave Address Restrictions" in the I3C spec). > > > + > > + + second and third cells: should encode the ProvisionalID. The second cell > > + contains the manufacturer ID left-shifted by 1. > > + The third cell contains ORing of the part ID > > + left-shifted by 16, the instance ID left-shifted > > + by 12 and the extra information. This encoding is > > + following the PID definition provided by the I3C > > + specification. One extra question for you: should I refer to the I3C_DEV(), I3C_DEV_WITH_STATIC_ADDR() and I2C_DEV() macros in the bindings doc? And if I do, should I use them my example? Thanks, Boris > > + > > +Optional properties > > +------------------- > > +- assigned-address: dynamic address to be assigned to this device. This > > + property is only valid if the I3C device has a static > > + address (first cell of the reg property != 0). > > + > > + > > +Example: > > + > > + i3c-master@d040000 { > > + compatible = "cdns,i3c-master"; > > + clocks = <&coreclock>, <&i3csysclock>; > > + clock-names = "pclk", "sysclk"; > > + interrupts = <3 0>; > > + reg = <0x0d040000 0x1000>; > > + #address-cells = <3>; > > + #size-cells = <0>; > > + > > + status = "okay"; > > + i2c-scl-frequency = <100000>; > > + > > + /* I2C device. */ > > + nunchuk: nunchuk@52 { > > + compatible = "nintendo,nunchuk"; > > + reg = <0x52 0x80000010 0x0>; > > + }; > > + > > + /* I3C device with a static address. */ > > + thermal_sensor: sensor@68,39200144004 { > > + reg = <0x68 0x392 0x144004>; > > + assigned-address = <0xa>; > > + }; > > + > > + /* > > + * I3C device without a static address but requiring resources > > + * described in the DT. > > + */ > > + sensor@0,39200154004 { > > + reg = <0x0 0x392 0x154004>; > > + clocks = <&clock_provider 0>; > > + }; > > + }; > > + > > -- > > 2.14.1 > > [1]http://www.i2c-bus.org/addressing -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com