Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux Hardware

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

Posted by msmash from the up-next dept.
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.
This discussion has been archived. No new comments can be posted.

USB 3.2 Work Is On The Way For The Linux 4.18 Kernel: Report More

USB 3.2 Work Is On The Way For The Linux 4.18 Kernel: Report

Comments Filter:
  • Wait a sec

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

    • You can write one using a $5 Arduino.
      • You can write a host controller chip?

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

          • 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: (Score:2)

              by Junta ( 36770 )

              Pfft. Amateur.

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

              • 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.

            • 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.

              • 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.

              • 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.

            • 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).

        • Yeah, haven't you heard of Arduino nanoassemblers?

        • 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...

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

            • 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...

              • 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.

  • 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.

    • 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

      • Re: (Score:2)

        by tlhIngan ( 30335 )

        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 f

        • Re: (Score:2)

          by rsborg ( 111459 )

          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?

        • 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 Th

          • 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 expensiv

  • Will we finally get Network Bridging? (Score:3)

    by rMortyH ( 40227 ) on Monday April 30, 2018 @01:02PM (#56531069)

    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: (Score:2, Informative)

      by 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

      • 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.

        • but they have a dongle in the middle

          ur mom has a dongle in the middle ooooh sick burn

        • 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.

          • 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: (Score:1)

      by 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

  • 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.

Slashdot Top Deals

When you are working hard, get up and retch every so often.

Close