M1 machines expose serial over Type C, so of course if you cross-connect two M1s they can talk to each other over serial. Conveniently, one of the pin pair options you can select is SBU1/2, which are cross-connected on standard cables, like a null modem serial cable, so you end up with TX connected to RX in both directions and it just works.
This is not a standard Type C feature, so unless another machine happens to also implement a 1.2V serial port compatible with Apple's version and pinout completely by chance, it won't work.
It only works on a specific port on Apple devices (the same one used for DFU, which has the fun debug features like this one), not on all the others.
Sure; Linux already has a driver for a variant of the USB-C chips in these Macs, so normal functionality should work with minimal changes. I don't know if the driver exposes the low-level command protocol to userspace off the top of my head (since we need that to send vendor-specific commands), but if it doesn't, we can probably get away with just using raw I²C access to the chip directly, via i2c-dev. Alternatively, we could add an interface, e.g. a debugfs entry for the Type-C driver that exposes raw commands.
Not sure what approach we'll end up with, but there are certainly multiple ways of doing this under Linux.
Comments
M1 machines expose serial over Type C, so of course if you cross-connect two M1s they can talk to each other over serial. Conveniently, one of the pin pair options you can select is SBU1/2, which are cross-connected on standard cables, like a null modem serial cable, so you end up with TX connected to RX in both directions and it just works.
This is not a standard Type C feature, so unless another machine happens to also implement a 1.2V serial port compatible with Apple's version and pinout completely by chance, it won't work.
It only works on a specific port on Apple devices (the same one used for DFU, which has the fun debug features like this one), not on all the others.
I see. So will Linux on the M1 have enough driver/etc support to do the serial stuff?
Sure; Linux already has a driver for a variant of the USB-C chips in these Macs, so normal functionality should work with minimal changes. I don't know if the driver exposes the low-level command protocol to userspace off the top of my head (since we need that to send vendor-specific commands), but if it doesn't, we can probably get away with just using raw I²C access to the chip directly, via i2c-dev. Alternatively, we could add an interface, e.g. a debugfs entry for the Type-C driver that exposes raw commands.
Not sure what approach we'll end up with, but there are certainly multiple ways of doing this under Linux.