[marcan_42]

It depends on whether the PD controller chip supports sending SOP'DEBUG/SOP"DEBUG packets, and, for those that do, whether it is exposed to the host OS or the firmware running on it does so.

However, even once you have that working, you still need to connect the other pins to a serial port adapter, and I don't know if any other laptops implement this in a compatible way, so you would probably still need some kind of cut-up cable that breaks out the serial wires.

[pabs3]

So what is different about an M1 that lets you do this without the serial port adaptor?

[marcan_42]

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.

[pabs3]

I see. So will Linux on the M1 have enough driver/etc support to do the serial stuff?

[marcan_42]

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.