LWN: Comments on "The USB debugging arsenal"

The USB debugging arsenal

kevinpr — Fri, 02 Jul 2021 00:11:36 +0000

> There's a lot in Type-C that has basically nothing to do with USB

They're actually almost completely orthogonal systems. You can swap USB PD data role (host/device) and power role (source/sink) independent of the existing USB2.0/3.0 host/device role. You can do USB PD _only_ on a Type-C cable with no USB2.0/3.0 traffic whatsoever (like your USB-C charger) or you can do USB2.0/3.0 traffic _only_ on a Type-C cable with no USB PD traffic, in which case you'll just get the standard 5V on VBUS.

The only place they kind of combine is with Alternate Modes, some of which mandate use of the SuperSpeed lines to carry different data, like your DP video signals. But even then the SuperSpeed controller doesn't really _interact_ with the USB PD controller, it's just told to get out of the way so the physical lines can be muxed to your DP controller instead.

The USB debugging arsenal

grundler — Mon, 14 Jun 2021 18:38:48 +0000

> Does anything in the above apply to USB PD?

I didn't see anything - but I know USB PD snooping isn't expensive:
https://www.chromium.org/chromium-os/twinkie

1) Plugable: https://archive.plugable.com/products/usbc-tkey/plugable-...
2) Totalphase: https://www.totalphase.com/products/usb-power-delivery-an...
3) Twonkie: https://hackaday.com/2021/02/20/google-inspired-usb-pd-sn...

Plugable unit is no longer available. Check the alternatives.

USB C one connector for everything

giraffedata — Sun, 15 Sep 2019 18:31:08 +0000

"USB C" single connector was a really bad development for system builders. It used to be you could tell what was compatible by seeing if the connectors fit. With USB C, the same connector can carry lots of different protocols, but doesn't have to carry them all and usually doesn't. And the systems are not smart enough to give you diagnostic information even if you can get the software working. You don't get a message somewhere that says, "You've plugged in an HDMI device to a port that can't do HDMI. This port does USB 3.1 and Thunderbolt 3, though."

This was the situation a long time ago. 40 years ago, a DB-25 connector could be just about anything, from RS-232 to SCSI. But I thought we had learned our lesson.

When I first heard about USB C for everything, I thought it meant USB was being expanded to do what all those other protocols do, so if you were lucky enough to have a device with a C connector and a computer with one, you were done.

The USB debugging arsenal

marcH — Thu, 12 Sep 2019 14:13:09 +0000

> Should it be regarded as a separate subsystem?

I think so. There's a lot in Type-C that has basically nothing to do with USB (which is why "USB-C" is bad name).

This is the best Type-C resource I know: https://medium.com/@leung.benson

It's funny to observe this two phase realization with Type-C:
1. "Oh great, a single cable for everything! Simple at last!"
2. "Wait, why does this combination not display/multi-display/go high-speed/charge/etc. ?"

And let's not even get into "Type-C cable fried my laptop" or manufacturers refusing to use logos not to stain their beautiful design...

The USB debugging arsenal

dougg — Wed, 11 Sep 2019 18:32:56 +0000

Does anything in the above apply to USB PD? That is USB type C's Power Delivery protocol that runs along the CC line. IMO that is the most interesting (new-ish) USB protocol that is often forgotten. It doesn't seem to fit in with the architecture of the USB subsystem outlined here. Should it be regarded as a separate subsystem? Alternate mode (e.g. PCIe<->DP) is controlled via USB PD so it is not clear that USB PD should be part of the power subsystem, but it is related.