Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752573AbdLLT6j (ORCPT ); Tue, 12 Dec 2017 14:58:39 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:44903 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752303AbdLLT6g (ORCPT ); Tue, 12 Dec 2017 14:58:36 -0500 Date: Tue, 12 Dec 2017 20:58:32 +0100 From: Boris Brezillon To: Wolfram Sang Cc: 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 , Jan Kotas , Cyprian Wronka , Alexandre Belloni , Thomas Petazzoni , Nishanth Menon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 0/5] Add I3C subsystem Message-ID: <20171212205832.4b317b21@bbrezillon> In-Reply-To: <20170731191745.GB1542@katana> References: <1501518290-5723-1-git-send-email-boris.brezillon@free-electrons.com> <20170731191745.GB1542@katana> 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 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2401 Lines: 57 On Mon, 31 Jul 2017 21:17:45 +0200 Wolfram Sang wrote: > Hi Boris, > > > This patch series is a proposal for a new I3C [1] subsystem. > > Nice. Good luck with that! > > Some hi-level comments from me related to I2C. I can't say a lot more > because the specs are not public :( > > > - the bus element is a separate object and is not implicitly described > > by the master (as done in I2C). The reason is that I want to be able > > to handle multiple master connected to the same bus and visible to > > Linux. > > In this situation, we should only have one instance of the device and > > not one per master, and sharing the bus object would be part of the > > solution to gracefully handle this case. > > I'm not sure if we will ever need to deal with multiple masters > > controlling the same bus and exposed under Linux, but separating the > > bus and master concept is pretty easy, hence the decision to do it > > now, just in case we need it some day. > > From my experience, it is a good thing to have this separation. > > > - I2C backward compatibility has been designed to be transparent to I2C > > drivers and the I2C subsystem. The I3C master just registers an I2C > > adapter which creates a new I2C bus. I'd say that, from a > > representation PoV it's not ideal because what should appear as a > > single I3C bus exposing I3C and I2C devices here appears as 2 > > different busses connected to each other through the parenting (the > > I3C master is the parent of the I2C and I3C busses). > > On the other hand, I don't see a better solution if we want something > > that is not invasive. > > I agree this is the least invasive and also the most compatible > approach. The other solution would probably be to have some kind of > emulation layer? > > > I'd also like to get feedback on the doc. Should I detail a bit more > > the protocol or the framework API? Is this the kind of things you > > expect in a subsystem doc? > > Since the spec is not public, details about the protocol will be > especially useful, I'd say. MIPI has opened the I3C spec [1], it can be downloaded here [2]. v2 of this series will come soon (sorry for the delay). Regards, Boris [1]https://www.businesswire.com/news//home/20171212005059/en/MIPI-Alliance-Opens-Access-MIPI-I3C-Sensor [2]http://resources.mipi.org/mipi-i3c-v1-download