Hi Arnd, Le Mon, 31 Jul 2017 22:16:42 +0200, Arnd Bergmann <arnd@xxxxxxxx> a écrit : > On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon > <boris.brezillon@xxxxxxxxxxxxxxxxxx> wrote: > > Add core infrastructure to support I3C in Linux and document it. > > > - 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. > > Can you describe the reasons for making i3c a separate subsystem then, > rather than extending the i2c subsystem to handle both i2c devices as > before and also i3c devices and hosts? Actually, that's the first option I considered, but I3C and I2C are really different. I'm not talking about the physical layer here, but the way the bus has to be handled by the software layer. Actually, I thing the I3C bus is philosophically closer to auto-discoverable busses like USB than I2C or SPI. Indeed, all I3C devices can be discovered and do not need to be described at the board level (using DT, board files, ACPI or whatever). Also, some I3C devices are hotpluggable, and most importantly, all I3C devices describe themselves during the discovery procedure (called DAA in the I3C world). There is some kind of "device class" concept. In the I3C world it's called DCR (Device Characteristic Register), but it plays the same role: it's a set of generic interfaces devices have to comply with when they declare themselves as being compatible with a DCR ID (like accelerometer, gyroscope, or whatever). See this table of normalized DCR for more information [1]. Devices also expose a 48-bit Provisional ID which is made of sub-fields. Two of them are particularly interesting: the manufacturer ID and the part ID, which are comparable to the vendor and product ID in the USB world. These three information (DCR, ManufacturerID and PartID) can be used to match drivers instead of the compatible string or driver-name used for I2C devices So, as you can imagine, dealing with an I3C bus is really different from dealing with an I2C bus, and I found the "expose an i2c_adapter object for each i3c_master" way simpler (and less invasive) than extending the I2C framework to support I3C devices. Of course, I can move all the code in drivers/i2c/, but that won't change the fact that I3C and I2C busses are completely different with little to share between them. To me, the I2C backward compatibility is just a nice feature that was added to help people smoothly transition from mixed I3C busses with both I2C and I3C devices connected to it (I2C devices being here when no (affordable) equivalent exist in the I3C world) to pure I3C busses with only I3C devices connected to it. This being said, I'd be happy if you prove me wrong and propose a solution that allows us to extend the I2C framework to support I3C without to much pain ;-). Thanks, Boris [1]https://www.mipi.org/MIPI_I3C_device_characteristics_register
