I3C Subsystem Appears Ready For Possible Inclusion Into Linux 4.20~5.0

[phoronix]

Phoronix: I3C Subsystem Appears Ready For Possible Inclusion Into Linux 4.20~5.0

There is already a lot of features slated for the Linux 4.20~5.0 kernel with its development cycle officially having gotten underway this morning. Adding to that lengthy list of expected work is the possible introduction of the I3C subsystem...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-I3C-Subsystem-Maybe-Ready

[uid313]

How do you communicate with these?

Is there any AF_I3C that you use with sockets?
Or it exposed as devices under /dev/ such as /dev/i3c1, /dev/i3c2, etc?

Do you send any string you want, or you use commands part of some standard protocol?

[tildearrow]

How do you communicate with these?

Is there any AF_I3C_SOCKET that you use with sockets?
Or it exposed as devices under /dev/ such as /dev/i3c1, /dev/i3c2, etc?

Device drivers usually expose devices through /dev, and after looking at the code, I don't see any references to sockets. As such I think it's the latter.

[uid313]

Device drivers usually expose devices through /dev, and after looking at the code, I don't see any references to sockets. As such I think it's the latter.

True, I guess its just wireless devices such as Bluetooth (and I guess maybe NFC?) that communicate over sockets. Example AF_BLUETOOTH. For connected devices, its better to list them as device files in the /dev/ directory.

[schmidtbag]

I hope Arduinos can be compatible with this. At least it appears to be backward-compatible with I2C.

From what I can tell, the biggest differences of I3C are:
* Higher data bandwidth
* Lower power consumption
* Hot-swapping (which I found to be one of I2C's greatest drawbacks)
* Slave interrupts (also super useful)

How do you communicate with these?

Is there any AF_I3C_SOCKET that you use with sockets?
Or it exposed as devices under /dev/ such as /dev/i3c1, /dev/i3c2, etc?

Do you send any string you want, or you use commands part of some standard protocol?

I don't have specific answers for you, but if it's anything like I2C (which so far it seems to be), you should expect the following:
* It'll have its own protocol, which isn't as simple as talking to a serial port can be.
* To my understanding, you get a /dev for each controller, not each device on the controller. So with i2c you get /dev/i2c-0, /dev/i2c-1, and so on, for each controller you have.
* Talking to each device is part of its communication protocol. From my recollection, I2C devices have no "obligation" to present themselves; you have to either probe for their address (which unlike a MAC address, is not necessarily unique), or you have to already know what the address is and talk to it that way. And even then, that doesn't guarantee you'll know how to operate it.
* Generally speaking, you're expected to write C code to use I2C, but if you don't feel like doing that, there is package called i2c-tools.

To my understanding, the best way to look at I2C was an industry-standard for a multiplexed serial port.