USB 3.2 Work Is On The Way For The Linux 4.18 Kernel: Report (phoronix.com)

An anonymous reader shares a report: USB 3.2 was announced last summer as an incremental update to the USB standard to double the bandwidth for existing USB Type-C cables. We haven't seen much in the way of USB 3.2 mentions in the Linux kernel yet but then again we haven't really seen USB 3.2 devices yet. USB 3.2 brings a multi-lane operation mode for hosts and devices using existing Type-C cables as well as a minor update to the USB hub specification. USB 3.2 allows for new 10 Gbit/s and 20 Gbit/s rates using two lanes, USB 3.2 Gen 1x2 and USB 3.2 Gen 2x2, respectively. It looks like kernel developers are now working on getting their USB 3.2 Linux support in order. We were tipped off that as of last week there are some USB 3.2 patches queued in the usb-next tree maintained by Greg Kroah-Hartman's.

Comments

No it's not

[UltimateDuster]

Wait a sec

controller chip/card??

[amigabill]

Is a host controller chip available yet for testing any driver code with the USB3.2 framework?

Re:controller chip/card??

[bluefoxlucid]

You can write one using a $5 Arduino.

Re:controller chip/card??

[BronsCon]

You can write a host controller chip?

Re:controller chip/card??

[bluefoxlucid]

Yes. You'd control it over an RS-232 port or a USB port.

Re:controller chip/card??

[BronsCon]

You can write to a controller chip... You don't write the chip, itself, into existence, though; nor would a USB 3.2 controller chip be "written" to a generic microcontroller.

Re:controller chip/card??

[Junta]

Pfft. Amateur.

I took my 16550 UART and reprogrammed it to be a full speed 256 lane PCIe gen 4 controller.

Re:controller chip/card??

[king neckbeard]

Yeah, haven't you heard of Arduino nanoassemblers?

Re:controller chip/card??

[Anonymous Coward]

Tarduino.

Re:controller chip/card??

[bluefoxlucid]

You can write USB HCI and Client devices on Atmel microcontrollers; whether you can make it function full-speed or completely is a different matter. You may need to do some screwy stuff to get power pins working (e.g. rigging up a digitally-controlled LM with a 3.3V or 12V feed).

You can get enough to say the protocol works (HCI driver). That won't cover the individual quirks of any particular chipset, only the spec itself.

Re:controller chip/card??

[Anonymous Coward]

Oh, you lucky bastard.
I still only have a 16450 UART. Surfing the web is a bit choppy.

Re:controller chip/card??

[BronsCon]

I'm waiting for the day... can you imagine?

Re:controller chip/card??

[BronsCon]

You can get enough to say the protocol works (HCI driver). That won't cover the individual quirks of any particular chipset, only the spec itself.

OP was interested in such a particular chipset, probably to test whether said drivers would work in the real world.

Re:controller chip/card??

[Anonymous Coward]

Kids these days.

When I was young a UART was a person. In the telegraph office.

Re: controller chip/card??

[bill_mcgonigle]

Dinosaur. You're supposed to use the RPi PWM GPIO ports to do 20GBps. How? Easy, offload processing to the GPU and enable DMA. RPi has no limits (ignoring large Bitcoin blocks).

Re:controller chip/card??

[amigabill]

Essentially, yes. Digital circuit design is largely done using VHDL or Verilog (or derivatives) "hardware design language" code. Type the functionality, type the netlist connecting it together and to analog blocks like clock PLLs, voltage regulators, PowerOnResets, IO pad buffers, etc. EDA tools synthesize the code into logic gates and wire them together. Build IP libraries for reuse so you don't have to code the same thing again, buy it from vendors, find it as open-source (opencores.org) etc...

Re:controller chip/card??

[BronsCon]

Right, but that's not how arduinos work...

Re:controller chip/card??

[thegarbz]

whether you can make it function full-speed or completely is a different matter

So you can make one but it won't be functional or meet the required spec that the OP wanted to test against. Got it.

Re:controller chip/card??

[amigabill]

I'm not interested in the Arduino silliness. But in a way it is how Arduinos work. I used to work as a chip designer at the "Arduino chip" vendor, and have an understanding of how that "Arduino chip" itself was made... One of these HDL languages was involved...

Re: controller chip/card??

[BronsCon]

Ok, well the person I originally replied to was talking about writing one to an Arduino. How the Atmel microcontroller on an Arduino is made is really irrelevant to how it is programmed.

Re: controller chip/card??

[tigersha]

I did that with a piece of wire 20 years ago. In the meantime we reprogram USB to UQB (Universal Quantum Bus) where I work. You can simply encode a 1TB block of data as a superposition on a single photon.

Re:controller chip/card??

[Anonymous Coward]

Kids these days.

When I was young a UART was a person. In the telegraph office.

Pff, that's nothing. When I was young a THOUART was a person.

Oxymoron. I argue it.

[Anonymous Coward]

Latest versions of USB are becoming "Universal Parallel Bus" instead of "Universal Serial Bus".

USB-2.0 had reason itself.

Re:Oxymoron. I argue it.

[Anonymous Coward]

Parallel serial communications doesn't make it a parallel bus.

The problem with parallel buses was that the signal might become desynchronized, so the switch was made to serial buses as you avoid worrying about synchronization completely. Adding buses in parallel (that is they don't require synchronization) doesn't stop them from being serial buses.

Re:multi-lane?

[bluefoxlucid]

Not really.

A parallel bus uses a parallel data lane: an 8-pin parallel data lane sends one byte by sending 8 bits all at once, such that the single clock across all buses synchronizes all bits.

A multi-lane serial bus is sending data in packets, such that the data coming down any one lane is self-consistent. For example: bonded ethernet adapters send entire frames down each link, rather than spreading a frame out across multiple links in an alternation of bits.

That means any one lane is sending a complete signal, and any interference causing errors down another lane don't affect the unaffected lane (in parallel buses, an error in one line would affect the entire signal: if you send a packet and one line has noise, you get an erroneous packet--all of the data sent down all lines is erroneous, even though most lines are noise-free).

Weird, huh?

No USB 3.1.1 for Workgroups?

[rsborg]

Seriously so can we expect decent adoption rates by 2020?

USB support seems so fragmented it's hard to know which devices support which capabilities.

Re:No USB 3.1.1 for Workgroups?

[ilsaloving]

Not just difficult... Impossible.

And this has been a complaint by many knowledgable people right from day 1 when USB-C was announced. Until USB-C, virtually every cable ever made was tied to the protocol it carried. There was simply no question.

There were a couple cases where people tried to double up... most notably, 25-pin SCSI that used the same port as the parallel/printer port. Or the 15-pin joystick/midi port.

Every time people doubled-up, confusion reigned. In particular with the SCSI port, there were more than a few incidents of people shorting out and destroying their hardware cause they plugged into the wrong port. That mistake wasn't made again.

Until some Einstein-wannabe thought USB-C would make a great cable to handle *everything*, but without any guarantees about *anything*. So now _every_. _single_. USB C device and cable now needs to have a spec sheet kept with them because you have no way of knowing just by looking at it, what features it supports. Does it do thunderbolt passthrough? Does it support video pass through? Power pass through?

It's a god-forsaken nightmare that screams "designed by committee".

So far it hasn't been that big of a deal because the only people using it have been mobile devices (used only for charging) and apple users (to connect dongles). But as the port gets more pervasive, it's going to get a whole lot messier.

Re:No USB 3.1.1 for Workgroups?

[tlhIngan]

Until some Einstein-wannabe thought USB-C would make a great cable to handle *everything*, but without any guarantees about *anything*. So now _every_. _single_. USB C device and cable now needs to have a spec sheet kept with them because you have no way of knowing just by looking at it, what features it supports. Does it do thunderbolt passthrough? Does it support video pass through? Power pass through?

Power is easy. It's 5V 0.5A unless your device specifically supports USB-PD. And USB-PD support (in the first version) is indicated by active signalling (at 24kHz) on the Vbus (+5V) line. Or in later revisions of USB-PD, through a dedicated line (this is to reflect the fact that USB-PD is now part of USB-C and not independent. The Vbus twiddling was when USB-C did not exist and thus had to work with the 4 existling lines. This also reflects on cabling).

For DisplayPort, ThunderBolt, HDMI, USB 3.2 multi-lane, etc., these use the "alt mode" pins on the connector. There is a signalling protocol in place to detect and assign which altmode protocol you wish to use - of which only one may be in action at any one time. Typically, your device only supports one mode as well, though granted, internal USB hubs may complicate things (e.g., a dock with ethernet and display and USB ports may be USB-based for the ethernet and USB ports, and altmode for the display, or it may be thunderbolt based for ethernet, USB for display and ports, or some combination).

USB PD can be challenging since current can flow either way - it can receive power or it can distribute power

Re:No USB 3.1.1 for Workgroups?

[rsborg]

Until some Einstein-wannabe thought USB-C would make a great cable to handle *everything*, but without any guarantees about *anything*. So now _every_. _single_. USB C device and cable now needs to have a spec sheet kept with them because you have no way of knowing just by looking at it, what features it supports. Does it do thunderbolt passthrough? Does it support video pass through? Power pass through?

Power is easy. It's 5V 0.5A unless your device specifically supports USB-PD. And USB-PD support (in the first version) is indicated by active signalling (at 24kHz) on the Vbus (+5V) line. Or in later revisions of USB-PD, through a dedicated line (this is to reflect the fact that USB-PD is now part of USB-C and not independent. The Vbus twiddling was when USB-C did not exist and thus had to work with the 4 existling lines. This also reflects on cabling).

For DisplayPort, ThunderBolt, HDMI, USB 3.2 multi-lane, etc., these use the "alt mode" pins on the connector. There is a signalling protocol in place to detect and assign which altmode protocol you wish to use - of which only one may be in action at any one time. Typically, your device only supports one mode as well, though granted, internal USB hubs may complicate things (e.g., a dock with ethernet and display and USB ports may be USB-based for the ethernet and USB ports, and altmode for the display, or it may be thunderbolt based for ethernet, USB for display and ports, or some combination).

USB PD can be challenging since current can flow either way - it can receive power or it can distribute power

This is so obviously clear it only took 3 paragraphs to describe and leave me in a sense of suspense like a good thriller novel.

How do I know which power cables and endpoints support which modes of USB-PD?

Re:No USB 3.1.1 for Workgroups?

[Immerman]

The fact that available services will be auto-negotiated does indeed solve most of the technical problems, and should, if I understand correctly, completely prevent short circuits, etc. so long as you use properly certified cables. However, they do very little to address the *human* problems.

You grab a compliant USB 2 cable, you know it will work with any USB 2 (or 1) devices it fits in. USB-3.1 type C in comparison has at least three different cables mentioned on Wikipedia - full featured, active(for Thunderbolt), and adapters.

Then, even assuming you have the right cable, you still have the problem with not-necessarily-shared protocols: Say you want to send video via USB - there's four different options: DisplayPort, MHL, HDMI, and Thunderbolt, and from what I can find there's no requirement for graceful fail-over. You may quite easily find yourself in the situation where Device A and Display B both support video-over-USB, but not the same protocol. You'd hope everyone would at least support the royalty-free DisplayPort protocol as the least common denominator, but I saw no mention of such a requirement. The little support logos can help, if used, but that requires people memorize the meanings of several different logos with non-obvious relevance. And let's be honest - we're never going to see all those logos stamped on the back of an iPhone, regardless of support. And the things that do have them will likely be embossed black plastic - virtually illegible in less-than-perfect lighting.

So basically they've created a situation where human frustration is likely to abound, despite what is technically an impressive product. Or more accurately, an environment where such a situation is very likely to arise.

Re:No USB 3.1.1 for Workgroups?

[fuzzyfuzzyfungus]

Aside from people just fucking it up(downright ubiquitious in USB power delivery scenarios, sometimes of the 'likely hardware damage' flavor) the trouble is that the alt-modes move what a USB port might be capable of outside the realm of the USB implementation itself.

Alt mode support is a USB thing; so compliant USB chipsets Must correctly handle the relevant signalling and handing off; but the behavior of whatever is handed off to is outside the USB spec and often in the realm of parts that are expensive enough that there is no way the USB-IF could get any serious traction even if they tried to twist arms.

Even on expensive gear with substantial punch there typically aren't enough resources for the alt-modes to be supported without various compromises and non-obvious limitations (it isn't a 100% perfect match; because the Mac Pro predates USB-C connector thunderbolt; but it's a good example of the mismatch between various types of resources at the system's disposal: it's sorta plug and play; but "attach displays to different Thunderbolt busses when possible. Don't attach more than two displays to any bus"). It's quite typical for a computer to have 10 or more USB ports; Even if the Thunderbolt silicon were free, which it isn't, it's not so typical for a computer to have an extra 20 or 40 PCIe lanes; nor is it common to have more than two or three displayport outputs(unless you are loading up on GPUs or using classy workstation cards). Even if the extra expense and board space is provided so that any USB-C port can be used for any alt-mode for which system resources are available, that still means that "you can only plug monitors into two of them; unless you have two displayport monitors and one HDMI, in which case you can use three; but if you do that only Thunderbolt devices that use PCIe exclusively will work on the remaining ports, no Thunderbolt displays" is the order of the day.

Once you get down to realistically cheap devices; where things like not having a PCIe bus; or only having HDMI because you are a cheap SoC designed for set top boxes; or not wanted to put a fancy matrix switch in so that multi-Gb/s busses are available from any USB port are to be expected the limits of what any given USB port can do are just going to get tighter.

If(and it's a big if) some reasonably sane scheme is designed to make it clear what a device can or can't do it's still arguably a win over fixed function ports(if a laptop, say, can only actually charge via one of its ports and output video over one or two others; that's still a laptop that has USB ports where it would otherwise have a vendor barrel plug and an HDMI port, which is nice to have); but it's pretty much impossible to expect reasonably comprehensive support out of devices without making them mostly expensive and overqualified.

Re:No USB 3.1.1 for Workgroups?

[Anonymous Coward]

Not that easy. The Nintendo Switch uses a USB-C connector but it's power draw is not USB-PD compliant, meaning that non Nintendo USB-C chargers will not work on the switch, and the charger won't work on devices that are not the switch (and may potentially damage it).

It know it's easy to start blaming Nintendo for this but this isn't a unique story. There's a lot of companies out there that don't follow specifications because it's too costly to do so; not just in expense but in compromises to the engineering of the device in question. I've personally been involved in debugging a hardware issue with a compatibility issue with older Samsung televisions that had a wrong resistor installed into the HDMI port, necessitating other manufacturers of HDMI sources modify their devices to be slightly wrong as well. Samsung eventually corrected this but yeah... came back to haunt us when a newer display had over saturated red because of that wrong resister in the source that was meant to be compatible with the older Samsung displays. Another time when Intel buggered up their reference Panther Point USB controller design for ivybridge so that it could only support 64 end points (every USB device consumes 2 end points).

A lot of the decisions to break from spec are usually understandable, but it's still frustrating to deal with.

Re:No USB 3.1.1 for Workgroups?

[sjames]

It's more than easy, I'll do it right now. If their power supply is able to damage USB compliant devices or be damaged by them, they should have used a different connector. There, problem solved with no design compromise or expensive hardware.

The Samsung case you mentioned doesn't support your argument that proper support may be too costly at all. They just plain screwed it up. The correct resister wouldn't have cost any more than the wrong one. In a perfect world, Samsung would have had it's feet held to the fire to repair or replace each and every defective device or come up with a decent workaround that didn't involve the rest of the world joining them in being wrong.

The Intel one was mostly harmless since few people have 16 USB devices connected.

Re:multi-lane?

[Anonymous Coward]

Parallel used to have all sorts of limitations due to crosstalk. Meanwhile clock speeds were advancing at a torrid pace, so at a certain point it made sense to switch to serial communications at crazy cycles per second. Now, that technology has been taken as far as it can and in the interim we've made progress keeping the data lines from fucking each other all up in parallel, so back we go.

Parallel vs. multiple serial links

[DrYak]

The printer ports or the ISA bus on your old computer that is gathering dust in a corner of your basement are true parallel connection:
Each bit of a 8bit byte is traveling in parallel in a neighboring conductor.

(But this would be a technical nightmare on modern speed used in modern system, as you'd need to make sure that all the bits arrive at the exact same time in perfect unison at the destination. lenght of conductor and speed of light/speed of electricity in a medium start to matter a lot.
See the complicated squiggly traces between DIMMs and memory controllers to make sure that the path takes the exact same amount of time.
That's why it's being abandoned in modern buses)

DVI, SATA-Express, PCI-Express, USB 3, etc. have all multiple conductor, but they are all in essence still serial.
Each bit of a word is travelling one after the other in the same conductor.
And the above standard just happen to have multiple serial-links that can be used concurrently : the system can send multiple data packet more or less at the same time, each sent serially along a different line.
(And in the cases of standards such as PCIe, the various serial links might not be even talking to the same device).

Unlike the parallel situation, you do not need to make sure that the bits travel in unison down different conductors : each serial link is sending different data packets, they can arrive with slightly different timing.

(Basically, is like plugging 2 network cables in 2 ports of the same server using link aggregation. You didn't suddenly turn ethernet into a parallel bus, you just have more interfaces to spread the load of sending your packet over).

So no. Latest iteration USB are still serial. They can just have more independent serial-links used concurrently, but the bits still travel one after the other on the same link, the other link is used to send a different data packet concurrently)

At best you could invent a new term like "multi-serial" or "concurrent serial".

Re:Parallel vs. multiple serial links

[Anonymous Coward]

The physics that governs serial cable is the same that governs parrellel cable. Single-ended signaling is bad; differential synchronously clocked signaling using properly terminated twisted pairs is good. SCSI has been there, done that.

The old "parallel port" was single ended ribbon cable. Not good.

Re:Parallel vs. multiple serial links

[ChrisMaple]

Thus fiber, which is single-ended, can't be used for high speed communications?

Re:Parallel vs. multiple serial links

[Anonymous Coward]

Fiber is not single ended. It "floats" without reference to ground.

Re:Parallel vs. multiple serial links

[thegarbz]

Basically, is like plugging 2 network cables in 2 ports of the same server using link aggregation

Or it's like plugging in 1 network cable to gigabit equipment since it also uses 4 differential channels serially :-)

Re:multi-lane?

[Anonymous Coward]

Multi-lane super fast serial protocol are old hat too, such as Hypertransport and PCIe.

Will we finally get Network Bridging?

[rMortyH]

We've gone from 480Mb/sec up to 6Gb, 10Gb, now 20Gb, and we still can't use a native USB cable to network two linux boxes.
Thunderbolt on Mac has this, and there was a very limited solution for linux that was never production ready.
We're still stuck at 1Gb/sec between machines for any networking that isn't cost-prohibitive, impractical, or both.
The cables exist, I look forward to the day when I can plug two machines together and run a network between them over this cable.
Will this ever happen? Or is this a case of hardware vendors blocking open source so that they don't compete with their own jurassic and overpriced 10Gb products?

Re:Will we finally get Network Bridging?

[Anonymous Coward]

we still can't use a native USB cable to network two linux boxes.

you dumb-shit, it's been possible for over a decade

https://developer.ridgerun.com/wiki/index.php/How_to_use_USB_device_networking

google for "RNDIS", get yourself a machine with an OTG USB port and you're off to the races

Re:Will we finally get Network Bridging?

[TeknoHog]

google for "RNDIS", get yourself a machine with an OTG USB port and you're off to the races

It seems the GP is talking about two regular, host-side USB ports, and your solution needs extra hardware. AFAIK, USB always needs one "host" and one "device" to make a connection. I remember seeing USB host-to-host networking cables many years ago, but they have a dongle in the middle, so it appears as a networking device to both hosts.

Re:Will we finally get Network Bridging?

[sexconker]

but they have a dongle in the middle

ur mom has a dongle in the middle ooooh sick burn

Re:Will we finally get Network Bridging?

[Anonymous Coward]

Yet another aspect where Firewire was superior to USB...

(IP over Firewire is the name of the game.)

Re:Will we finally get Network Bridging?

[Anonymous Coward]

While hardware vendors are busy not making USB 3.x network cables with a dual headed dongle in the middle :
there is a new consumer solution at least, 2.5 Gbps Ethernet and 5 Gbps Ethernet. It's called NBase-T.
I suggest you look into that, a CAT5e cable will do.

I doesn't seem available, and that's a shame! Some desktop motherboard launched a while ago with 5Gbps Ethernet, I don't remember which.
Sorry state of the industry in general. All the little companies to do controller cards and what not are dead? Or consolidated into big business that will only launch low risk, low cost, high volume products.

Re:Will we finally get Network Bridging?

[ledow]

Shame that Firewire is using a protocol that's fundamentally insecure, isn't it? Arbitrary DMA was always a bad idea.

Re:Will we finally get Network Bridging?

[drinkypoo]

It seems the GP is talking about two regular, host-side USB ports, and your solution needs extra hardware.

No. That's why they said USB OTG. Unfortunately, only mobile devices tend to support it. Still, that covers the only important use case. GigE cards are cheap now, and 10GbE cards are rapidly coming down into the affordable range.

Re:Will we finally get Network Bridging?

[thegarbz]

No. That's why they said USB OTG.

You should learn the difference between the Parent and the GrandParent. The post being referred to never said USB OTG, and was referring to USB Bridged mode networking, something that works just fine in Windows to connect two hosts together but not in Linux.

Re:How about MTP?

[Anonymous Coward]

You may try the equivalent Ubuntu, version 18.04 on live USB at least.
Or maybe for that crap we need to set up an Arch VM, and try with the Gnome 3 file manager, then the KDE file manager. But if we all start doing that, we'll lose. "Works on my machine"

Hilariously if you try some little mtp-dedicated transfer application from the repository packages, in 16.04 at least : this poor little shit blows up hard.
From a file manager it works better but might not go very far at all.

Seriously, who cares

[gweihir]

With USB 3.0, the bus was in a reasonable final stage. All this is just people trying to sell new hardware that basically nobody needs.

Yawn, Windows 10 already has support

[Anonymous Coward]

Come on freetards, get with the program

Question for msmash

[Anonymous Coward]

How exactly does ": Report" at the end of the headline add any information whatsoever? I see this construction as well as "From a report:" in summaries. These seem like completely useless empty phrases that do nothing except take up space.

Re:Question for msmash

[Anonymous Coward]

Hey, hey, hey. Back off, friend.

Perhaps you are not keeping track of these things, but this week is msmash's bleeding week. Mark your calendar. She gets wacky like clockwork every four weeks. Take it to the bank.

no

[bussdriver]

Firewire added restrictions to DMA over a decade ago. USB 3 added DMA support afterwards; possibly they would have had that slip their mind if firewire didn't have to deal with it 1st. Even still, I never liked the idea of a shared bus with many devices having DMA access. I don't know the specifics of USB 3 and how they isolate devices from each other in their DMA space but if they do, I'd guess the CPU is still heavily involved in operations; while firewire never required a master controller for operations like USB. Firewire was more of a simple decentralized network while USB is serial bus for a computer.

Re:no

[ledow]

Nope... operating systems were still being attacked by Firewire devices in this manner into 2014 and beyond (Finfisher).

I'm unable to source any such similar attack purely over USB... there's a handful of modern ones using Thunderbolt connectors (which expose the PCIe interfaces) via USB but that's not the same.

Ditto.

[antdude]

I am still using USB2 hardwares. I have no USB3 ports since I use old hardwares.

Re:Ditto.

[gweihir]

I do mostly too. The only use for USB 3.0 I have found is attaching fast disks. But that is it.

Re:Ditto.

[antdude]

I have USB3 flash drives too, but I have no USB2 ports on my ancient hardwares. Heh.