From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225LryUZfsP308qPbVeho4ObcZp8kMysbzKHNhzGH/gbIq4O0vC7QId2v6/upF1M7SlL+5eo ARC-Seal: i=1; a=rsa-sha256; t=1516610860; cv=none; d=google.com; s=arc-20160816; b=YP2tUm5jHRQW1RuCu1mmmYzqVNNTohRZpUkEYy65VnVL8AS2oTgLvE/JvOmXk3Poe/ xk3OV69uUIsBUXRLZRNULJp5qyqZ+IoOfI52Pmt3PeVqmFaohcLHG7Z3zxN22V/VJiPo lwsDrlFNJY0CteHghEogjvz8B/5RZNa51sa/GaG4fjqe9/mGOWOYWf5SWTSSO+uZ6c9Y DSuRGve7PcDcdWozGzVE9k8mZ4wEzO5hO54V4PMgW/Jdo1wyNR9Q6Up/63VvU7nRc63A PnFtWmabScQKSh+/3i87xzLIgInkiBtR5Qb3YvnOizNt79movDAntkYRi8nMxcrez1jj zH5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=r3HjuKp8cA1KseVfDFPUrlQyMnPsZrDBYKbrNIO7ilc=; b=ZliaVkaRLU+VgbWgBAXIFyYrtnv17bDqngmw1UdkyS8f33Mb58whcOSLXwdyt6aRax tU04hPYgqR+eHxELb3MRTixAbSvRaGyU03HfjlNI3oO3Kz0rzBjbdFXZo6U++Lz4VsbH GeFpYXSedD4VaDih4Zhd4T01WeBXE6B4SZCAS28ihlfmXcp4OlttMTdi+1LYwWlabgIX SzQfagrflzdSEKs1WEYJUUVd9KDxASKSXJGSLAwISbeOtjRsKdHJxv/X0qRDheM8Ikp/ pNc/6L/d93G7O6HR8DWU6LwTozkivzQ0ozZ7OrrrGejrWUAWRJQij9TH1ae+TElpQHm+ lfsw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of boris.brezillon@free-electrons.com designates 62.4.15.54 as permitted sender) smtp.mailfrom=boris.brezillon@free-electrons.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of boris.brezillon@free-electrons.com designates 62.4.15.54 as permitted sender) smtp.mailfrom=boris.brezillon@free-electrons.com Date: Mon, 22 Jan 2018 09:47:39 +0100 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 , Thomas Petazzoni , Nishanth Menon , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "linux-kernel@vger.kernel.org" , Vitor Soares , Geert Uytterhoeven , Linus Walleij Subject: Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings Message-ID: <20180122094739.6b05d5b2@bbrezillon> In-Reply-To: <20180107151425.124c2c75@bbrezillon> References: <20171214151610.19153-1-boris.brezillon@free-electrons.com> <20171214151610.19153-6-boris.brezillon@free-electrons.com> <20171216172040.jcaezouqkeb7zrqy@rob-hp-laptop> <20171216193537.0aef2e97@bbrezillon> <20171220180645.pis34opfwawakmqc@rob-hp-laptop> <20171221114144.2610d49b@bbrezillon> <20180107151425.124c2c75@bbrezillon> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1586772918554034182?= X-GMAIL-MSGID: =?utf-8?q?1590281750020435700?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: Hi Rob, On Sun, 7 Jan 2018 15:14:25 +0100 Boris Brezillon wrote: > Hi Rob, > > On Tue, 26 Dec 2017 12:29:34 -0600 > Rob Herring wrote: > > > >> > > > +Optional properties > > >> > > > +------------------- > > >> > > > +- reg: static address. Only valid is the device has a static address. > > >> > > > +- i3c-dynamic-address: dynamic address to be assigned to this device. This > > >> > > > + property depends on the reg property. > > >> > > > > >> > > Perhaps "assigned-address" property would be appropriate. I'm not all > > >> > > that familiar with it though. > > >> > > > >> > Again, the spec use the term "dynamic address" everywhere, and I'd like > > >> > to stay as close as possible to the spec. > > >> > > >> I looked at assigned-addresses a bit more and that won't really fit > > >> because it should be the same format as reg. So I think reg should > > >> always be the PID as that is fixed and always present. Then the DAA > > >> address is separate and can be the i3c-dynamic-address property. > > >> > > >> However, there's still part I don't understand... > > >> > > >> > > > + /* I3C device with a static address. */ > > >> > > > + thermal_sensor: sensor@68 { > > >> > > > + reg = <0x68>; > > >> > > > + i3c-dynamic-address = <0xa>; > > >> > > >> I'm confused as to how/why you have both reg and dynamic address? > > > > > > Some I3C devices have an I2C address (also called static or legacy > > > address in a few places). The static/I2C/legacy address is used until > > > the I3C device is assigned a dynamic address by the master. The whole > > > point of specifying both an I2C address (through the reg property) and > > > a dynamic address (through the i3c-dynamic-address) is to tell the > > > controller that a specific dynamic address should be assigned to this > > > device using the SETSADA (Set Dynamic Address from Static Address) > > > command before a DAA (Dynamic Address Assignment) procedure is started. > > > This way, the device will not participate to the DAA (because it > > > already has a valid DA) and the dynamic address can't be assigned to > > > a different device (which is one of the problem with the automatic DAA > > > procedure). > > > > Okay, think I got it now. > > > > I think we should extend "reg" to have either I2C address, I3C PID, or > > both (in a defined order). I'm assuming you can always distinguish a > > static I2C address and an I3C PID just by upper bits all being 0s for > > I2C addresses. Maybe both is not needed? This means we'd have to allow > > 64-bit I2C addresses (#address-cells=2), but that should be easily > > fixed if that causes problems in the kernel. > > > > So i3c-pid would go away and i3c-dynamic-address stays. > > Hm, actually I'm not sure this is a good idea. Sounds like we're > abusing the purpose of reg here. For busses, reg is supposed to encode > the id of the device on the bus that is used to communicate with this > device (CS line for SPI, I2C address for I2C devs, ...). With I3C, the > PID is just a way to uniquely identify a device, but is not used during > communications (we either use the static/I2C address or the dynamic > address assigned by the master). > > If your concern is just about I3C dev naming convention, maybe we > could have something like: > > i3c-master@xxxx { > ... > i2cdev@xx { > reg = ; > i3c-lvr = ; > ... > }; > ... > > i3cdev-[@zz] { > i3c-pid = ; > /* > * reg only defined if the device has a static > * address. > */ > [reg = ;] > /* > * i3c-dynamic-address only defined if a > * specific dynamic address is requested. > */ > [i3c-dynamic-address =
;] > }; > }; > > With this approach we have a way to quickly identify i3c devices by > their pid when looking at their names (with the - suffix), and > we keep reg for static/i2c addresses only. Did you have time to read this email (AKA ping)? Regards, Boris