Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751862AbdHAPVB (ORCPT ); Tue, 1 Aug 2017 11:21:01 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:46014 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751701AbdHAPU6 (ORCPT ); Tue, 1 Aug 2017 11:20:58 -0400 Date: Tue, 1 Aug 2017 17:20:41 +0200 From: Boris Brezillon To: Wolfram Sang Cc: Arnd Bergmann , linux-i2c@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Greg Kroah-Hartman , 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 Mailing List Subject: Re: [RFC 2/5] i3c: Add core I3C infrastructure Message-ID: <20170801172041.30aaac2e@bbrezillon> In-Reply-To: <20170801150108.GC1450@katana> References: <1501518290-5723-1-git-send-email-boris.brezillon@free-electrons.com> <1501518290-5723-3-git-send-email-boris.brezillon@free-electrons.com> <20170731231509.77d1fba4@bbrezillon> <20170801142936.5df48702@bbrezillon> <20170801153414.6ce34ee8@bbrezillon> <20170801141218.GA1450@katana> <20170801164826.423183ff@bbrezillon> <20170801150108.GC1450@katana> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; 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: 1249 Lines: 32 On Tue, 1 Aug 2017 17:01:08 +0200 Wolfram Sang wrote: > > I do not know of any real devices as of today (all my tests have been > > done with a dummy/fake I3C slaves emulated with a slave IP), > > I see. > > > spec clearly describe what legacy/static addresses are for and one of > > their use case is to connect an I3C device on an I2C bus and let it act > > as an I2C device. > > OK. That makes it more likely. > > > Unless you want your device (likely a sensor) to be compatible with both > > I3C and I2C so that you can target even more people. > > Right. My question was if this is a realistic or more academic scenario. > > > I'm perfectly fine with the I3C / I2C framework separation. The only > > minor problem I had with that was the inaccuracy of the > > sysfs/device-model representation: we don't have one i2c and one i3c > > bus, we just have one i3c bus with a mix of i2c and i3c devices. > > I understand that. What if I2C had the same seperation between the "bus" > and the "master"? > Yep, it might work if we can register an i2c_adapter and pass it an existing bus object. We'd still need a common base for i2c and i3c busses, unless we consider the bus as an opaque "struct device *" object.