On Tue, 1 Aug 2017 17:20:41 +0200 Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx> wrote: > 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. I tried to envision how this could be implemented but realized separating the bus and master concepts in I2C wouldn't solve all problems. Each device is attached a bus_type which defines how to match devices and drivers, uevent format, ... But it also defines where the device appears in sysfs (/sys/bus/<bus-name>/devices). First question: where should an I2C device connected on an I3C bus appear? /sys/bus/i3c/devices/ or /sys/bus/i2c/devices/? I'd say both (with one of them being a symlink to the other) but I'm not sure. Also, if we go for a 'single bus per master' representation but still want i3c and i2c to be differentiated, that means when one adds an i2c_driver we'll have to duplicate this driver object and register one instance to the i2c framework and the other one to the i3c framework, because device <-> driver matching is done per bus_type. One solution would be to go for Arnd suggestion to extend i2c_bus_type with I3C support, but then i3c related kojects would be exposed under /sys/bus/i2c/ which can be disturbing for people who are used to look at /sys/bus/<bus-name> to find devices connected on a specific bus type. Honestly, I don't know what's the best solution here. Every solution has its pros and cons: 1/ The "one i2c bus and one i3c bus per i3c master" I proposed in this RFC is non-invasive but the resulting sysfs/device-model representation is not accurate. 2/ Separating the I3C and I2C framework with a thin layer between them to propagate i2c drivers registration to the i3c framework and make sure i2c devices are exposed in both worlds is much more complicated to implement but should provide an accurate bus <-> device representation. 3/ Extending i2c_bus_type (and more generally the I2C framework) to support I3C devices/busses is invasive and we still have a non-accurate representation (i2c busses are mixed with i3c busses and all exposed under /sys/bus/i2c/). One advantage with this solution compared to #2 is that we don't need to duplicate i2c_driver objects in order to register them to both i2c and i3c bus types. Any advice is welcome. Thanks, Boris -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
