On 07/31/2017 04:42 PM, Wolfram Sang wrote: > >> 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. > > Acked-by: Wolfram Sang <wsa@xxxxxxxxxxxxx> > >> 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. > > That wouldn't make sense. > >> 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. > > Yeah, and it is still to be seen how good this really works. Devices > which do clock stretching are out of the question. Probably everything > which needs an interrupt as well? > I'm surprised they didn't allow for slave clock stretching when communicating with a legacy i2c device, it will prohibit use of a rather large class of devices. :( As for interrupts you are always free to wire up an out-of-band interrupt like before. :) >> 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 ;-). > > From all I know, I don't see that coming. > -- 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
