Linux 7.3 will start checking whether your USB-C cable can actually carry an alternate mode before the kernel advertises one. Until now it did not look, which is why a monitor plugged in through a charging cable could leave you with a port that claims DisplayPort is configured while nothing appears on screen. The new code, from Andrei Kuchynski of Google's Chrome OS team, inspects three things: whether an identity header exists at all, whether a passive cable is limited to USB 2.0 speeds, and whether an active cable reports the plugs that go with it. Small change, and one that removes a genuinely confusing class of failure.
The short answer
Linux 7.3 adds validation of USB Type-C cable capabilities before the kernel engages an alternate mode such as DisplayPort or Thunderbolt. Earlier kernels did not inspect what the cable could carry, which allowed incorrectly advertised state configurations and initialisation failures. The new code checks for an identity header, catches passive cables limited to USB 2.0 speeds, and requires active cables to report their corresponding plugs. It comes from Andrei Kuchynski of Google's Chrome OS team. Linux 7.3 also brings a busy_poll option for USB4STREAM and Device Tree bindings for the ASpeed AST2700 DWC3 controller.
If you have ever plugged a monitor into a laptop over USB-C, got nothing, swapped the cable for an identical looking one and got a picture, you have met this bug. Linux 7.3 does not fix the cable. It stops the kernel from claiming the first one was fine.
The gap this closes
USB Type-C alternate modes let a port carry something other than USB traffic, most commonly DisplayPort and Thunderbolt. Whether that works depends on the cable as much as on the two devices, because carrying those signals needs conductors and, for active cables, electronics that a basic charging cable simply does not have.
Until Linux 7.3 the kernel did not check. It would proceed with the alternate mode path regardless of what the cable could support, and the outcome was one of two unhelpful things: a state configuration advertised that did not match physical reality, or an initialisation failure with no obvious cause. Neither told you the useful thing, which is that the cable is wrong.
The three checks
Andrei Kuchynski of Google's Chrome OS team added validation that runs before a mode is advertised.
The kernel checks that an identity header is present. A cable that cannot identify itself over Power Delivery is not a cable you can build a Thunderbolt link on top of. It checks whether a passive cable is limited to USB 2.0 speeds, which is the signature of the charging cable that came free in a box. And for active cables it checks that the corresponding plugs are reported, because an active cable that does not describe its plugs is not describing a working path.
Fail any of those, and the mode is not offered. The practical result is that the failure moves from the far end, where you are staring at a black monitor, to the near end, where the port simply does not claim a capability it cannot deliver.
Seeing it from userspace
The information the kernel acts on is not hidden. The USB Type-C connector class exposes cable properties in sysfs, which makes this one of the rare kernel changes you can inspect on your own desk without instrumenting anything.
Under /sys/class/typec/ you will find a cable entry per port, typically port0-cable. The type attribute reports passive or active. The plug_type attribute gives the connector. The usb_power_delivery_revision attribute reports the Power Delivery revision in play, and the identity directory holds the raw vendor defined objects, including id_header. If a mode you expected is not being offered after moving to 7.3, those files are where the answer is, and it will usually be that the cable never identified itself properly in the first place.
The other USB work in 7.3
Two more items landed alongside it.
Intel contributed a busy_poll option for USB4STREAM, a ConfigFS knob that runs the transfer rings in polling mode instead of interrupts. It cuts host to host latency between systems connected over USB4 or Thunderbolt, at the cost of noticeably higher CPU usage, which makes it something you switch on for a specific workload rather than leave enabled.
There are also new Device Tree bindings for the ASpeed AST2700 DWC3 controller. That one is aimed at server hardware and baseboard management controllers rather than laptops, and it is the kind of entry that quietly determines whether a management board works out of the box two years from now.
Why a small patch is worth reading about
Cable behaviour is one of the least satisfying things to debug, because every symptom points at the wrong component. A dead external display looks like a graphics driver problem. A Thunderbolt device that will not enumerate looks like a firmware problem. It has been a recurring theme in hardware enablement work this year, from Asahi Linux getting Thunderbolt and webcams working on Apple silicon to open firmware efforts on USB4 docks.
A kernel that refuses to advertise a mode the cable cannot carry does not make anything faster. It makes the system honest, and on this particular class of hardware that is worth more.
Sources and further reading
- Linux 7.3 Will Begin Checking USB-C Cables For Alt-Mode Support, Phoronix, August 28, 2026
- USB Type-C mode selection, LWN.net
- USB Type-C connector class, kernel documentation
- sysfs-class-typec ABI documentation
Frequently asked questions
What exactly does Linux 7.3 check now?
Three conditions before an alternate mode is advertised. First, whether the cable presents an identity header at all, since a cable that cannot identify itself cannot be trusted to carry a high speed mode. Second, whether a passive cable is limited to USB 2.0 speeds, which rules out the charging cables that ship in the box with phones and chargers. Third, whether an active cable reports the corresponding plugs, because an active cable that does not describe its plugs is not describing a working alt mode path. If any check fails, the kernel does not advertise the mode.
What problem did this fix?
Incorrectly advertised state configurations and initialisation failures. Without the checks, the kernel could enter an alternate mode negotiation with a cable that had no way to carry it, and the result was either a state that claimed DisplayPort or Thunderbolt was configured while nothing worked, or an outright initialisation failure. From a user's seat that looks like an external monitor that stays black on one cable and works on another, with no clear reason. The change does not make the bad cable work; it makes the kernel stop pretending it might.
Will this break docks or monitors that currently work?
It should not, because the checks describe what a cable must be able to do rather than adding a new requirement. A cable that genuinely carries DisplayPort alternate mode presents an identity, is not a USB 2.0 passive cable, and reports its plugs if it is active. What can change is behaviour on marginal hardware that previously negotiated something it could not deliver. If a setup stops advertising a mode after the update, the cable is the first thing to swap, not the kernel.
How do I see what my cable is reporting?
The USB Type-C connector class exposes it in sysfs. Look under /sys/class/typec/ for entries like port0-cable, where type tells you passive or active, plug_type gives the connector, and usb_power_delivery_revision reports the PD revision in use. Under the identity directory you get the raw vendor defined objects including id_header. Reading those attributes tells you what the kernel learned from the cable, which is the same information the new checks act on, so it is the fastest way to work out why a mode is or is not being offered.
What else changed for USB in Linux 7.3?
Two items worth knowing. Intel added a busy_poll option to USB4STREAM, a ConfigFS knob that runs the transfer rings in polling mode rather than on interrupts, cutting host to host latency over USB4 or Thunderbolt at the cost of higher CPU usage. That is a trade you make deliberately rather than leave on. There are also new Device Tree bindings for the ASpeed AST2700 DWC3 controller, which matters if you work with baseboard management controllers on server hardware rather than with laptops and docks.