On Tue, 1 Aug 2017 17:01:08 +0200 Wolfram Sang <wsa@xxxxxxxxxxxxx> 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.
