USB 3.x

Kernel-Level Device Driver Programming for Echocardiography and Robotics (In Development)

Kernel-Level Driver Control of Echocardiography and Robotic Arm: A kernel-level device driver is used to enable communication between the Philips Lumify, embedded in a robotic arm, and the hemodynamic software of Project nGene.org^®.

[USB-C] Philips Lumify, analyzed by LeCroy T2C Advanced USB Analyzer

LumifyUSBProtocol.zip

Development Environments

The software was developed in C and Python within Unix-like operating systems and was primarily tested on Debian Linux.

  -  Devices Programming

• LeCroy T2C Advanced USB Analyzer

  -  Echocardiography

• Philips Lumify - Sector/Convex/Linear
• Siemens ACUSON X300 PE - Sector
• Siemens ACUSON P500 - Sector

Introduction

The Universal Serial Bus (USB) has established itself as a pivotal interface standard, facilitating connections between peripheral devices and host systems such as computers, smartphones, and other electronic devices. Since its inception in the mid-1990s, USB has evolved through multiple iterations, each introducing significant enhancements in speed, power delivery, and functionality. USB 2.0, introduced in 2000, marked a substantial improvement over its predecessor, USB 1.1, by increasing data transfer rates and refining power management. With a maximum data transfer rate of 480 Mbps, USB 2.0 swiftly became the standard for numerous devices, including external storage drives, printers, and digital cameras. This version remained dominant for over a decade, striking a balance between performance and power consumption.

As the demand for faster data transmission and enhanced power delivery capabilities surged, the development of the USB 3.x series became imperative. The USB 3.x series, encompassing USB 3.0, USB 3.1, and USB 3.2, introduces significant advancements over USB 2.0, addressing the needs of modern computing and content creation environments.

USB 2.0 Overview

Understanding the foundation laid by USB 2.0 is essential before exploring the advancements introduced by USB 3.x. USB 2.0 introduced the High-Speed mode, elevating data transfer rates from the 12 Mbps of USB 1.1 (Full-Speed) to 480 Mbps. Additionally, USB 2.0 standardized Mini and Micro USB connectors, which became ubiquitous in mobile devices.

Key Features of USB 2.0:

• High-Speed Data Transfer: Supports up to 480 Mbps, enabling faster communication with peripherals.
• Improved Power Delivery: Provides up to 500 mA at 5 V, sufficient for most peripherals of that era.
• Broad Compatibility: Backward compatible with USB 1.1 devices and hosts.
• Wide Adoption: Became the standard interface for a diverse range of devices, from keyboards to external hard drives.

Despite its widespread adoption, USB 2.0 exhibited limitations, particularly in handling high-bandwidth applications such as high-definition video streaming and rapid data backup solutions.

    USB 2.0
    │
    ├── Data Transfer
    │   ├── High-Speed: 480 Mbps
    │   └── 8b/10b Encoding (20% Overhead)
    │
    ├── Power Delivery
    │   └── 5 V, 500 mA
    │
    ├── Connector Types
    │   ├── Type-A
    │   ├── Type-B
    │   ├── Mini USB
    │   └── Micro-B
    │
    ├── Compatibility
    │   └── Backward Compatible with USB 1.1
    │
    └── Adoption
        └── Widely Used in Keyboards, Mice, External Drives, etc.

USB 3.x Overview

The USB 3.x series introduces substantial improvements over USB 2.0, catering to the increasing demands for higher data transfer rates, enhanced power delivery, and more efficient power management. The series encompasses:

• USB 3.0: Branded as SuperSpeed USB, it supports data transfer rates up to 5 Gbps—over ten times faster than USB 2.0.
• USB 3.1: Introduced SuperSpeed+ (also known as USB 3.1 Gen 2), doubling the data rate to 10 Gbps.
• USB 3.2: Further advances the series by supporting multi-lane operations, allowing transfer rates of up to 20 Gbps over a USB Type-C connection.

These advancements address the growing needs of modern computing and content creation, which require swift data transmission for large files such as 4K video and high-resolution images.

    USB 3.x Series
    │
    ├── USB 3.0
    │   ├── SuperSpeed: 5 Gbps
    │   ├── 8b/10b Encoding (20% Overhead)
    │   ├── Power: 5 V, 900 mA
    │   └── Connectors: Type-A (Blue), Type-B, Micro-B SuperSpeed
    │
    ├── USB 3.1
    │   ├── SuperSpeed+: 10 Gbps
    │   ├── 128b/132b Encoding (~3% Overhead)
    │   ├── Power Delivery: USB PD Introduced
    │   └── Connectors: Type-A, Type-C
    │
    ├── USB 3.2
    │   ├── Multi-Lane SuperSpeed: Up to 20 Gbps
    │   ├── 128b/132b Encoding (~3% Overhead)
    │   ├── Power: 5 V, 900 mA
    │   └── Connectors: Type-C
    │
    └── USB4
        ├── Integration with Thunderbolt 3
        ├── Data Rates: Up to 40 Gbps
        ├── PCIe/TBT-based Encoding
        ├── Power Delivery: Up to 100 W
        └── Connectors: Type-C    

Data Encoding and Efficiency

USB 3.x enhances data encoding mechanisms to improve efficiency:

• USB 2.0 Encoding: Utilizes 8b/10b encoding, resulting in a 20% overhead due to the addition of two extra bits for every eight bits of data.
• USB 3.0 Encoding: Continues with 8b/10b encoding but optimizes the protocol to reduce inefficiencies.
• USB 3.1 and USB 3.2 Encoding: Shift to 128b/132b encoding, drastically reducing overhead to approximately 3%. This change ensures a higher percentage of the raw data rate is utilized for actual data transfer, minimizing losses and enhancing overall throughput.

Table: Comparison of USB Data Encoding Schemes

Power Management and Delivery

USB 3.x introduces significant advancements in power management, addressing the escalating power requirements of modern devices:

• USB 2.0 Power Output: Capped at 500 mA at 5 V.
• USB 3.0 Power Output: Increased to 900 mA at 5 V, allowing for faster charging and support for more power-hungry peripherals.
• USB Power Delivery (USB PD): Introduced alongside USB 3.1, enabling dynamic power negotiation between the host and the peripheral.

Features of USB Power Delivery (USB PD):

• Increased Power Levels: Enables power delivery up to 100 W (20 V, 5 A).
• Bi-directional Power Flow: Allows devices to supply power to the host.
• Voltage Flexibility: Supports multiple voltage levels (5 V, 9 V, 15 V, 20 V), accommodating various device requirements.

USB PD enhances the versatility of USB, enabling it to power laptops, monitors, and other high-consumption devices through the same cable that handles data transfer.

Backward Compatibility

A cornerstone of the USB standard is its commitment to backward compatibility:

• Data Transfer Protocols: USB 3.x ports can interface with USB 2.0 devices, though performance will revert to USB 2.0 levels.
• Power Management Systems: Ensures that power delivery remains compatible with legacy devices.
• Connector Compatibility: USB Type-A connectors remain consistent, allowing existing devices to connect to new hosts.

This backward compatibility minimizes costs for users, preserves the utility of legacy devices, and simplifies the transition process for manufacturers and consumers alike.

Connector Types and Physical Changes

One of the most significant changes in the USB 3.x series is the introduction of the USB Type-C connector, signaling a shift toward a universal, reversible design.

USB 3.x Connector Types:

• USB Type-A: Retains the same physical design with additional pins for SuperSpeed data transfer. USB 3.x Type-A ports often feature blue or teal inserts.
• USB Type-B: Modified for USB 3.x with additional pins; commonly used in larger peripherals like printers.
• Micro-B SuperSpeed Connector: Adds supplementary pins to the existing Micro-B connector, allowing backward compatibility and SuperSpeed data rates.
• USB Type-C: Features a reversible design, supporting data transfer, power delivery, and video output through Alternate Modes (e.g., DisplayPort, HDMI).

Benefits of USB Type-C:

• Reversible Plug Orientation: Can be inserted in any orientation, enhancing user convenience.
• Compact Size: Suitable for modern slim devices.
• High Power Delivery: Integral to USB PD, enabling up to 100 W power delivery.
• Alternate Modes Support: Allows transmission of non-USB signals (e.g., Thunderbolt 3).

Full-Duplex Data Transmission

USB 3.x supports full-duplex data transmission, enabling simultaneous communication in both directions:

• USB 2.0: Utilizes half-duplex communication, where data transmission and reception occur sequentially.
• USB 3.x: Implements separate pairs of differential signaling wires for transmitting and receiving data concurrently.

This feature significantly enhances efficiency in data-intensive applications, as the host and peripheral can send and receive data simultaneously without collisions or the need for time-multiplexed communication.

USB 3.x Enhancements Beyond Data and Power

Beyond higher data transfer rates and improved power delivery, USB 3.x introduces enhancements targeting specific industry needs:

• Isochronous Data Transfers: Essential for applications such as real-time audio and video streaming, requiring guaranteed bandwidth and low-latency communication.
• USB Attached SCSI Protocol (UASP):
  • Replaces Bulk-Only Transport (BOT): Used in USB 2.0.
  • Advantages: Enables multiple concurrent commands, reduces latency, and improves overall efficiency, especially for SSDs and high-speed storage devices.
• Stream Protocol: Allows multiple data streams within a single bulk endpoint, enhancing throughput and efficiency for devices requiring simultaneous data flows.

Integration with Modern Computing Architectures

The integration of USB 3.x into modern computing architectures has led to improvements in system resource allocation:

• xHCI (eXtensible Host Controller Interface): A unified host controller interface for USB 3.x and USB 2.0 devices. It simplifies driver development and improves system efficiency.
• Direct Memory Access (DMA): Reduces CPU overhead by allowing devices to transfer data directly to and from memory.
• Advanced Power Management: Supports low-power states (U1, U2, U3), enabling devices to conserve energy when idle. Implements Link Power Management (LPM) for enhanced energy efficiency.

Linux Kernel Support for USB 3.x

Linux offers robust support for USB 3.x, including drivers and tools that enable developers to utilize the advanced features of the standard effectively.

Key Components:

• xHCI Driver: Manages USB 3.x host controllers, providing the necessary interface between hardware and software.
• USB Core APIs: Facilitate interaction with USB devices at a low level, enabling comprehensive device management and data transfer operations.

    Linux Kernel Support
    │
    ├── xHCI (eXtensible Host Controller Interface)
    │   ├── Unified Interface for USB 3.x and 2.0
    │   ├── Simplifies Driver Development
    │   └── Enhances System Efficiency
    │
    ├── USB Core APIs
    │   ├── Low-Level Device Interaction
    │   ├── Device Management
    │   └── Data Transfer Operations
    │
    ├── Drivers
    │   ├── xHCI Driver
    │   └── UASP (USB Attached SCSI Protocol) Support
    │
    ├── Power Management
    │   ├── DMA (Direct Memory Access)
    │   ├── Advanced Power States (U1, U2, U3)
    │   └── Link Power Management (LPM)
    │
    └── Sample Driver Structure
        ├── usb_device_id Table
        ├── Probe Function
        ├── Disconnect Function
        ├── Driver Registration
        └── Module Initialization and Exit

Sample Linux Kernel Driver Code for USB 3.x:

#include <linux/module.h>
#include <linux/usb.h>

#define USB_VENDOR_ID  0x1234  // Replace with actual Vendor ID
#define USB_PRODUCT_ID 0x5678  // Replace with actual Product ID

static struct usb_device_id usb_ids_table[] = {
  { USB_DEVICE(USB_VENDOR_ID, USB_PRODUCT_ID) },
  { } // Terminating entry
};
   
MODULE_DEVICE_TABLE(usb, usb_ids_table);

static int usb_driver_probe(struct usb_interface *interface, const struct usb_device_id *id) {
   pr_info("USB 3.x Device (Vendor: %04X, Product: %04X) connected.\n", id->idVendor, id->idProduct);

   // Initialization code here
   return 0;
}

static void usb_driver_disconnect(struct usb_interface *interface) {
   pr_info("USB 3.x Device disconnected.\n");

   // Cleanup code here
}

static struct usb_driver usb_driver = {
   .name = "usb3x_driver",
   .id_table = usb_ids_table,
   .probe = usb_driver_probe,
   .disconnect = usb_driver_disconnect,
};

static int __init usb_driver_init(void) {
   int result;
   result = usb_register(&usb_driver);

   if (result < 0) {
	pr_err("usb_register failed with error %d\n", result);
	return result;
   }

   pr_info("USB 3.x Driver Registered.\n");
   return 0;
}
	     
static void __exit usb_driver_exit(void)   {
   usb_deregister(&usb_driver);
   pr_info("USB 3.x Driver Deregistered.\n");
}

module_init(usb_driver_init);
module_exit(usb_driver_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Your Name");
MODULE_DESCRIPTION("A simple USB 3.x driver example."); 

• usb_device_id Table: Specifies the Vendor ID and Product ID of the USB device the driver will handle.
• Probe Function: Called when a device matching the usb_device_id table is connected. Initialization tasks are performed here.
• Disconnect Function: Called when the device is disconnected. Cleanup tasks are performed here.
• Driver Registration: The usb_driver structure is registered with the kernel, enabling the driver to manage the specified USB devices.

Summary of USB Versions

Table: Comparison of USB Versions

Note: USB4 integrates Thunderbolt 3 technology, providing higher speeds and enhanced capabilities.

Conclusion

The USB 3.x series represents a significant evolution of the USB standard, addressing the limitations of USB 2.0 by offering higher data transfer rates, improved power delivery, and enhanced functionality. The introduction of the USB Type-C connector and USB Power Delivery has expanded the versatility of USB, establishing it as a universal interface for data, power, and video transmission.

Backward compatibility maintained throughout the USB iterations ensures a seamless transition for consumers and manufacturers, preserving the utility of existing devices while embracing new technologies. With robust support from operating systems like Linux, USB 3.x remains integral to modern computing, meeting the demands of high-speed data transfer, efficient power management, and versatile connectivity.

Comparison of USB 3.x and Thunderbolt Technologies

Universal Serial Bus (USB) and Thunderbolt are two leading interface standards for connecting peripherals to computers and other devices. USB 3.x represents the third major iteration of the USB standard, offering faster data transfer rates and improved power management compared to earlier versions. Thunderbolt, developed by Intel in collaboration with Apple, provides even higher data transfer speeds and advanced features like multi-protocol support and daisy-chaining.

This document provides a detailed overview of the USB 3.x family, presents enhanced comparison tables of USB 3.x and Thunderbolt versions, explains the differences between these technologies through tabular representation, and includes practical information on selecting appropriate cables. The aim is to help readers grasp the material more readily and make informed decisions when selecting interfaces and cables for their devices.

#1/2: USB 3.x Versions

USB 3.x Versions and Features

Below is a comprehensive table comparing different USB 3.x versions, highlighting their key features for easy comparison.

• Data Transfer Rate: Maximum theoretical speed for data transfer.
• Encoding Scheme: Method of encoding data for transmission, affecting efficiency.
• Number of Lanes: Paths used simultaneously to increase bandwidth.
• Connector Types:
  • USB Type-A: Traditional rectangular connector on hosts like computers.
  • USB Type-B: Square connector used for devices like printers.
  • USB Micro-B: Smaller connector for devices like external hard drives.
  • USB Type-C: Reversible connector supporting higher data rates and power delivery.
• Power Delivery:
  • Without USB PD: Base power supplied without USB Power Delivery protocol.
  • USB Power Delivery (USB PD): Optional protocol increasing power delivery up to 100W.
• Backward Compatibility: Ability to work with devices using older USB standards.

Clarification of USB 3.x Naming Conventions

The USB 3.2 standard introduced new naming conventions, rebranding previous versions:

• USB 3.0 and USB 3.1 Gen 1 are now USB 3.2 Gen 1x1.
• USB 3.1 Gen 2 is now USB 3.2 Gen 2x1.
• USB 3.2 Gen 1x2 and USB 3.2 Gen 2x2 indicate multi-lane operations over USB Type-C connectors.

#2/2: Thunderbolt Versions

Below is a table comparing different Thunderbolt versions, highlighting their key features for easy comparison.

• Maximum Data Rate: Aggregate bandwidth available for data transfer.
• Connector Type: Physical connector used for the interface.
• Power Delivery:
  • Without USB PD: Base power supplied without USB Power Delivery protocol.
  • USB Power Delivery (USB PD): Ability to deliver up to 100W for charging devices.
• Video Support: Version of DisplayPort protocol supported for video transmission.
• Protocol Support: Types of data protocols that can be transmitted (e.g., PCIe, USB).
• Daisy-Chaining: Ability to connect multiple devices in series.
• Backward Compatibility: Compatibility with previous Thunderbolt versions.
• Cable Length: Maximum recommended length to maintain performance.
• PCIe Data Tunneling: Version of PCI Express used for data transfer.

Differences Between USB 3.x and Thunderbolt

To facilitate easier understanding, the key differences between USB 3.x and Thunderbolt technologies are summarized in the table below.

Cables and Their Importance

Selecting the appropriate cable is crucial for achieving the desired performance and functionality of USB 3.x and Thunderbolt technologies. Understanding how to differentiate between cables and knowing which ones are suitable for specific purposes is essential.

(A) How to Identify and Choose USB Cables

Identifying USB 3.x Cables

• Physical Indicators:
  • USB 3.x Type-A and Type-B connectors often have blue-colored plastic inserts to distinguish them from USB 2.0 connectors.
  • USB 3.x Micro-B connectors have an additional set of pins, making them wider than USB 2.0 Micro-B connectors.
• Cable Markings:
  • Look for the SuperSpeed USB logo (an "SS" before the USB trident symbol) on the connectors or the cable.
  • USB Version Labeling: Some cables may have labels like "USB 3.0," "USB 3.1," or "USB 3.2" indicating their compliance.

Choosing the Right USB Cable

• Data Transfer Requirements:
  • For up to 5 Gbps: Use cables labeled as USB 3.0 or USB 3.1 Gen 1.
  • For up to 10 Gbps: Use cables labeled as USB 3.1 Gen 2 or USB 3.2 Gen 2x1.
  • For up to 20 Gbps: Use USB-C cables certified for USB 3.2 Gen 2x2.
• Connector Types:
  • Ensure that the cable has the appropriate connectors for both the host and the peripheral device.
• Power Delivery Support:
  • If high power delivery is required (e.g., charging laptops), use cables that support USB Power Delivery (USB PD) up to 100W.
• Cable Quality:
  • Use cables from reputable manufacturers to ensure compliance with standards and safety regulations.

Practical Tips

• Compatibility: USB-C cables are not all the same; some only support USB 2.0 speeds. Verify the cable's specifications before purchasing.
• Length Considerations: Longer cables may suffer from signal degradation. For high-speed data transfer, use cables of shorter lengths as recommended by the manufacturer.

(B) How to Identify and Choose Thunderbolt Cables

Identifying Thunderbolt Cables

• Thunderbolt Logo:
  • Thunderbolt cables have a lightning bolt symbol on the connector housing.
  • Thunderbolt 3 and 4 cables may also have the number 3 or 4 next to the lightning bolt.
• Cable Markings:
  • Active cables may be labeled as "Active" and support longer lengths.
  • The data rate may be printed on the cable, e.g., "40 Gbps".

Choosing the Right Thunderbolt Cable

• Data Transfer Requirements:
  • For full 40 Gbps speeds, use Thunderbolt 3 or 4 cables labeled accordingly.
  • Passive Cables: Up to 0.5 meters for full speed; longer passive cables may reduce speed to 20 Gbps.
  • Active Cables: Support full speed at lengths up to 2 meters.
• Power Delivery Support:
  • To ensure power delivery up to 100W, select cables that support USB PD.
• Compatibility with USB Devices:
  • Thunderbolt 3 and 4 cables can be used with USB-C devices but will function at the USB device's maximum capabilities.
• Identifying USB-C vs. Thunderbolt Cables:
  • USB-C cables may not have any logo or may have the USB trident symbol.
  • Thunderbolt cables always have the lightning bolt symbol.

Practical Tips

• Do Not Assume Compatibility: Not all USB-C cables support Thunderbolt speeds or features.
• Check Cable Specifications: Ensure the cable matches the required Thunderbolt version and supports the needed features like data rate and power delivery.
• Use Certified Cables: Purchase cables that are certified by Intel for Thunderbolt to guarantee performance.

(C) Choosing the Right Interface and Cables

1. Data Transfer Speed:
   • Determine the maximum data rate required for your applications.
   • Choose cables that support the necessary USB or Thunderbolt version to achieve these speeds.
2. Connector Compatibility:
   • Ensure that the cable connectors match the ports on both the host and the peripheral device.
   • Consider adapters if necessary, but be aware they may limit functionality or speed.
3. Power Requirements:
   • For devices that require power delivery, select cables that support USB PD up to the required wattage.
   • Verify that both the host and peripheral support the desired power levels.
4. Cable Length:
   • Use shorter cables for higher data rates to minimize signal loss.
   • For longer distances, consider active cables that maintain signal integrity.
5. Quality and Certification:
   • Use cables from reputable manufacturers.
   • Look for certifications like USB-IF for USB cables and Intel's certification for Thunderbolt cables.
6. Use Case Specifics:
   • For professional applications requiring high-speed data transfer and multi-protocol support, Thunderbolt cables are preferred.
   • For general consumer applications, USB 3.x cables suffice and are more cost-effective.

Conclusion

Understanding the specifications, capabilities, and differences between USB 3.x and Thunderbolt technologies is crucial for selecting appropriate interfaces and cables for devices and applications. USB 3.x offers a range of options suitable for most consumer needs, with widespread compatibility and cost-effectiveness. Thunderbolt provides superior performance and versatility for professional and high-demand environments but requires compatible hardware and certified cables.

When choosing between USB 3.x versions or considering Thunderbolt technologies, consider the following:

• Data Transfer Requirements: Match the interface and cable to the required data rates.
• Device Compatibility: Ensure both host and peripheral devices support the chosen technology.
• Connector Types: Verify that connectors are compatible or that appropriate adapters are available.
• Cable Specifications: Select cables that support the necessary speed, power delivery, and length.
• Cost and Future-Proofing: Balance current needs with potential future requirements to maximize return on investment.

By carefully evaluating these factors, optimal performance and functionality can be achieved, enhancing the overall efficiency and effectiveness of the technological setup.

Connectors

USB connectors serve as the essential physical interface between host systems and peripheral devices. Designed to ensure reliability, prevent incorrect insertion, and accommodate evolving technological demands such as higher data transfer rates and enhanced power delivery, USB connectors have continually evolved. Throughout its development, USB has maintained a commitment to backward compatibility while introducing new connector types to support these advancements.

USB 2.0 Connectors

USB 2.0 features several connector types to cater to a broad range of devices:

• Type-A: The standard rectangular connector commonly found on host devices such as computers and hubs, facilitating downstream connections to peripherals.
• Type-B: A square-shaped connector primarily used on devices like printers and scanners, designed for upstream connections to the host.
• Mini and Micro Connectors: Compact connectors such as Mini-A, Mini-B, Micro-A, and Micro-B were introduced for mobile devices like digital cameras, smartphones, and other portable electronics, offering smaller form factors.

Each USB 2.0 connector type features a keyed design to prevent incorrect insertion and ensure a stable connection, enabling reliable data transmission and power delivery.

USB 3.x Connectors

The USB 3.x series introduced new connectors to support SuperSpeed data rates and increased power demands while retaining backward compatibility where possible:

• USB 3.0 Type-A: Maintains the same physical form as USB 2.0 Type-A, with five additional pins (totaling nine) to support SuperSpeed transmission. It remains backward compatible with USB 2.0 Type-A ports.
• USB 3.0 Type-B: Larger than USB 2.0 Type-B, it features additional pins for SuperSpeed data transfer but is not physically backward compatible with USB 2.0 Type-B ports.
• USB 3.0 Micro-B: Known as Micro-B SuperSpeed, this connector integrates extra pins for higher data rates. Its stacked design enables compatibility with USB 2.0 Micro-B connectors.
• USB Type-C: Introduced with USB 3.1, USB Type-C is a reversible connector designed to replace previous connector types. It supports high data rates, enhanced power delivery, and alternate modes (e.g., DisplayPort, Thunderbolt), making it an all-in-one connector for modern devices. USB Type-C is also backward compatible with earlier USB devices through appropriate adapters and cables.

The adoption of USB Type-C marks a significant milestone, positioning it as a universal connector for data, power, and video across a wide range of devices.

Table: Comparison of USB Connector Types

    USB 2.0 Connectors
    │
    ├── Type-A
    │   ├── Introduced With: USB 1.0
    │   ├── Physical Characteristics: Rectangular, 4 pins
    │   ├── Reversible: No
    │   ├── Max Data Rate: 480 Mbps
    │   ├── SuperSpeed Support: No
    │   └── Backward Compatible: Yes
    │
    ├── Type-B
    │   ├── Introduced With: USB 1.0
    │   ├── Physical Characteristics: Square, 4 pins
    │   ├── Reversible: No
    │   ├── Max Data Rate: 480 Mbps
    │   ├── SuperSpeed Support: No
    │   └── Backward Compatible: Yes
    │
    └── Mini/Micro Connectors
        ├── Types: Mini-A, Mini-B, Micro-A, Micro-B
        ├── Introduced With: USB 2.0
        ├── Physical Characteristics: Smaller form factors
        ├── Reversible: No
        ├── Max Data Rate: 480 Mbps
        ├── SuperSpeed Support: No
        └── Backward Compatible: Yes

    USB 3.x Connectors
    │
    ├── USB 3.0 Type-A
    │   ├── Introduced With: USB 3.0
    │   ├── Physical Characteristics: Rectangular, 9 pins
    │   ├── Reversible: No
    │   ├── Max Data Rate: 5 Gbps
    │   ├── SuperSpeed Support: Yes
    │   └── Backward Compatible: Yes
    │
    ├── USB 3.0 Type-B
    │   ├── Introduced With: USB 3.0
    │   ├── Physical Characteristics: Larger square, 9 pins
    │   ├── Reversible: No
    │   ├── Max Data Rate: 5 Gbps
    │   ├── SuperSpeed Support: Yes
    │   └── Backward Compatible: No
    │
    ├── USB 3.0 Micro-B
    │   ├── Introduced With: USB 3.0
    │   ├── Physical Characteristics: Stacked design, 10 pins
    │   ├── Reversible: No
    │   ├── Max Data Rate: 5 Gbps
    │   ├── SuperSpeed Support: Yes
    │   └── Backward Compatible: Yes (with USB 2.0 Micro-B)
    │
    └── USB Type-C
        ├── Introduced With: USB 3.1
        ├── Physical Characteristics: Symmetrical, 24 pins
        ├── Reversible: Yes
        ├── Max Data Rate: Up to 40 Gbps (USB4)
        ├── SuperSpeed Support: Yes
        └── Backward Compatible: Yes (with adapters) 

Electrical Characteristics

Understanding the electrical characteristics of USB standards is crucial for ensuring compatibility, signal integrity, and reliable power delivery.

USB 2.0 Electrical Characteristics

USB 2.0 operates at a standard voltage of 5 V supplied through the V_BUS line. It uses differential signaling via two data lines (D+ and D−), with Non-Return to Zero Inverted (NRZI) encoding and bit stuffing to maintain synchronization. The signaling is half-duplex, meaning data transmission occurs in one direction at a time. This method helps mitigate electromagnetic interference (EMI), allowing for reliable data transfer at speeds up to 480 Mbps in High-Speed mode.

USB 3.x Electrical Enhancements

USB 3.x introduces multiple enhancements to support higher data rates and improved power delivery:

• SuperSpeed Signaling: USB 3.0 adds two additional pairs of differential signaling lines—SSTX+/- (SuperSpeed transmit) and SSRX+/- (SuperSpeed receive)—enabling full-duplex communication, which allows data to be transmitted and received simultaneously.
• Improved Encoding: USB 3.0 uses 8b/10b encoding, which improves signal transition and clock recovery. USB 3.1 Gen 2 adopts a more efficient 128b/132b encoding, reducing overhead and optimizing throughput.
• Power Delivery Communication: The USB Power Delivery (USB PD) protocol, supported by USB Type-C connectors, introduces Configuration Channel (CC) pins for power negotiation and alternate mode functionality, facilitating dynamic power management across various devices.

These electrical improvements enable USB 3.x to achieve much higher data transfer rates while maintaining robust signal integrity and reliability.

    Electrical Characteristics
    │
    ├── USB 2.0
    │   ├── Voltage: 5 V (VBUS)
    │   ├── Current:
    │   │   ├── Low-Power Devices: 100 mA
    │   │   └── High-Power Devices: 500 mA (after enumeration)
    │   ├── Signaling:
    │   │   ├── Differential Signaling (D+ and D−)
    │   │   ├── NRZI Encoding with Bit Stuffing
    │   │   └── Half-Duplex Communication
    │   └── Data Rate: Up to 480 Mbps (High-Speed)
    │
    ├── USB 3.x
    │   ├── Voltage: 5 V (VBUS)
    │   ├── Current:
    │   │   ├── Increased Power Output: 900 mA
    │   │   ├── Battery Charging (BC 1.2): 1.5 A
    │   │   └── USB Power Delivery (USB PD): Up to 20 V, 5 A (100 W)
    │   ├── Signaling Enhancements:
    │   │   ├── SuperSpeed Signaling (SSTX+/− and SSRX+/−)
    │   │   ├── Full-Duplex Communication
    │   │   ├── Advanced Encoding (8b/10b → 128b/132b)
    │   │   └── Scrambling and Link Training (LTSSM)
    │   └── Power Delivery Communication:
    │       └── Configuration Channel (CC) Pins for Negotiation
    │
    └── Suspend Current
        ├── USB 2.0 Suspend Mode:
        │   ├── Trigger: 3 ms of bus inactivity
        │   ├── Current Draw: 2.5 mA
        │   └── Resume: On bus activity detection
        └── USB 3.x Suspend Modes:
            ├── U1: Low-power state, microsecond resume
            ├── U2: Deeper low-power, tens of microseconds resume
            └── U3: Deep suspend, millisecond resume

Speed Identification

Speed identification is crucial for the host and device to communicate at the highest mutually supported data rate.

USB 2.0 Speed Modes

USB 2.0 supports three speed modes, allowing it to cater to a wide range of devices:

• Low Speed (1.5 Mbps): For low-bandwidth peripherals such as keyboards and mice.
• Full Speed (12 Mbps): Used by peripherals like joysticks, audio interfaces, and MIDI devices.
• High Speed (480 Mbps): Supports data-intensive devices such as external storage drives, high-resolution webcams, and printers.

Device speed is determined through the use of pull-up resistors on the data lines, with the host detecting and configuring the appropriate speed automatically.

USB 3.x Speed Modes

The USB 3.x series introduces new speed modes that significantly surpass USB 2.0's capabilities:

• SuperSpeed (USB 3.0): Offers a transfer rate of up to 5 Gbps.
• SuperSpeed+ (USB 3.1 Gen 2): Doubles the speed to 10 Gbps.
• Enhanced SuperSpeed (USB 3.2): Supports transfer rates of up to 20 Gbps using dual-lane operations over USB Type-C.
• USB4 Gen 3x2: Achieves transfer rates of up to 40 Gbps by integrating Thunderbolt 3 technology.

Speed negotiation in USB 3.x is handled through the Link Training and Status State Machine (LTSSM), which ensures the host and device operate at the highest mutually supported speed, optimizing performance.

Comparison of USB Speed Modes

Power Delivery (V_BUS)

Power delivery is a critical aspect of the USB standard, allowing devices to be powered and charged via the same cable used for data transfer.

USB 2.0 Power Delivery

USB 2.0 delivers a standard 5 V power output over the V_BUS line, with two primary power levels:

• Low-Power Devices: Limited to 100 mA.
• High-Power Devices: After enumeration, devices can draw up to 500 mA.

This power delivery standard was sufficient for early peripheral devices but became insufficient as devices required more power.

USB 3.x Power Enhancements

USB 3.x introduces substantial improvements to power delivery:

• Increased Power Output: Devices can draw up to 900 mA at 5 V, supporting more power-intensive peripherals.
• Battery Charging Specification (BC 1.2): Supports up to 1.5 A, enabling faster device charging.
• USB Power Delivery (USB PD): Allows up to 100 W (20 V, 5 A) of power, enabling USB to charge and power larger devices like laptops and monitors. USB PD also introduces role swapping, allowing devices to dynamically switch between acting as power sources or power sinks.

These power management enhancements make USB 3.x more versatile in powering a broader range of devices.

Comparison of USB Power Delivery

    USB Power Management and Delivery
    │
    ├── Power Output Enhancements
    │   ├── USB 2.0: 5 V, 500 mA
    │   ├── USB 3.0: 5 V, 900 mA
    │   ├── USB BC 1.2: 5 V, 1.5 A
    │   └── USB PD: Up to 20 V, 5 A (100 W)
    │
    ├── USB Power Delivery (USB PD)
    │   ├── Features
    │   │   ├── Bi-directional Power Flow
    │   │   ├── Role Swapping (Power Source ↔ Sink)
    │   │   └── Voltage Flexibility (5 V, 9 V, 15 V, 20 V)
    │   └── Benefits
    │       ├── Charges Larger Devices (Laptops, Monitors)
    │       ├── Dynamic Power Negotiation
    │       └── Integrates with USB Type-C Connectors
    │
    └── Battery Charging Specification (BC 1.2)
        ├── Current Support: Up to 1.5 A
        ├── Enables Faster Charging
        └── Used By: Smartphones, Tablets, Portable Electronics

Suspend Current

Power conservation is essential, especially for battery-powered devices. USB standards define mechanisms for devices to enter low-power states when not actively communicating.

USB 2.0 Suspend Mode

To conserve power, USB 2.0 devices enter suspend mode after 3 ms of bus inactivity, reducing current draw to 2.5 mA. Devices resume normal operation when bus activity is detected.

USB 3.x Suspend Mode Improvements

USB 3.x introduces more sophisticated power-saving states, known as U-states:

• U1: A low-power state with fast resume times (microseconds).
• U2: A deeper low-power state with slightly longer resume times (tens of microseconds) but improved energy savings.
• U3 (Suspend): A deep suspend mode similar to USB 2.0, where minimal power is consumed, and resume times are longer (milliseconds).

These additional U-states offer flexible power management options, allowing for greater energy efficiency without compromising performance.

    Suspend Modes and Power Conservation
    │
    ├── USB 2.0 Suspend Mode
    │   ├── Trigger: 3 ms of bus inactivity
    │   ├── Current Draw: 2.5 mA
    │   └── Resume: On bus activity detection
    │
    └── USB 3.x Suspend Modes
    ├── U1
    │   ├── Power State: Low-power
    │   ├── Resume Time: Microseconds
    │   └── Use Case: Quick resume for active devices
    ├── U2
    │   ├── Power State: Deeper low-power
    │   ├── Resume Time: Tens of microseconds
    │   └── Use Case: Improved energy savings
    └── U3 (Suspend)
        ├── Power State: Deep suspend
        ├── Current Draw: Minimal
        ├── Resume Time: Milliseconds
        └── Use Case: Long-term power conservation 

Entering Suspend Mode

Efficiently managing transitions to and from low-power states is critical for maintaining device responsiveness while conserving power.

USB 2.0 Suspend Mechanism

A USB 2.0 device enters suspend mode after detecting 3 ms of bus inactivity, reducing power consumption. It resumes normal operation upon detecting bus activity.

USB 3.x Enhanced Suspend Mechanism

USB 3.x enables more adaptive power management by negotiating transitions to U1, U2, and U3 states between the host and device. The Link Power Management (LPM) protocol coordinates these transitions, ensuring efficient power management without significant impact on data transfer performance.

Data Signaling

Data signaling methods define how information is transmitted over the USB interface, impacting speed, reliability, and efficiency.

USB 2.0 Data Signaling

USB 2.0 employs NRZI encoding with bit stuffing to ensure synchronization. Data transmission occurs in packets, with half-duplex communication requiring one-way data flow at a time. Error detection is handled using cyclic redundancy checks (CRC).

USB 3.x Data Signaling Enhancements

USB 3.x significantly upgrades data signaling:

• Full-Duplex Communication: USB 3.x supports full-duplex communication, allowing simultaneous data transmission and reception.
• Advanced Encoding: USB 3.0 uses 8b/10b encoding, while USB 3.1 Gen 2 adopts 128b/132b encoding, reducing overhead and increasing efficiency.
• Scrambling: Reduces electromagnetic interference (EMI) and enhances signal integrity by making the data pattern appear more random.
• Link Training: Ensures optimal signal quality and link integrity during initialization through the LTSSM.

These advancements enable USB 3.x to support higher data rates of up to 20 Gbps while maintaining robust and reliable communication.

    Benefits of Enhanced Signaling
    │
    ├── Higher Data Rates
    │   └── Supports Up to 20 Gbps
    │
    ├── Improved Reliability
    │   └── Enhanced Error Detection and Recovery
    │
    └── Enhanced Efficiency
        └── Optimized Throughput with Reduced Overhead


    Endpoints and Pipes Relationship
    │
    ├── Endpoints
    │   ├── Logical Data Sources or Sinks
    │   ├── Identified by Unique Endpoint Numbers
    │   ├── Directional (IN or OUT)
    │   └── Types: Control, Bulk, Interrupt, Isochronous
    │
    └── Pipes
        ├── Logical Connections to Endpoints
        ├── Categories:
        │   ├── Message Pipes (Control Endpoints)
        │   └── Stream Pipes (Bulk, Interrupt, Isochronous Endpoints)
        └── Attributes:
            ├── Transfer Type
            │   ├── Control
            │   ├── Bulk
            │   ├── Interrupt
            │   └── Isochronous
            ├── Data Flow Direction
            │   ├── IN
            │   └── OUT
            └── Maximum Packet Size 

Linux Kernel Driver Sample Code

Developers often need to interface with USB devices at the driver level. Below is an example of how to interact with USB devices in the Linux kernel, focusing on USB 3.x devices.

    Integration with Modern Computing Architectures
    │
    ├── xHCI (eXtensible Host Controller Interface)
    │   ├── Unified Interface for USB 3.x and USB 2.0
    │   ├── Simplifies Driver Development
    │   └── Enhances System Efficiency
    │
    ├── Direct Memory Access (DMA)
    │   ├── Reduces CPU Overhead
    │   └── Enables Direct Data Transfer to/from Memory
    │
    ├── Advanced Power Management
    │   ├── Supports Low-Power States (U1, U2, U3)
    │   └── Implements Link Power Management (LPM)
    │
    └── Linux Kernel Support
        ├── xHCI Driver
        ├── USB Core APIs
        ├── UASP Support
        ├── Power Management Features
        └── Sample Driver Structure 

#include <linux/module.h>
#include <linux/usb.h>

#define USB_VENDOR_ID  0x1234  // Replace with actual Vendor ID
#define USB_PRODUCT_ID 0x5678  // Replace with actual Product ID

static struct usb_device_id usb_ids_table[] = {
  { USB_DEVICE(USB_VENDOR_ID, USB_PRODUCT_ID) },
  { } // Terminating entry
};
MODULE_DEVICE_TABLE(usb, usb_ids_table);

static int usb_driver_probe(struct usb_interface *interface, const struct usb_device_id *id) {
   struct usb_device *udev = interface_to_usbdev(interface);
   struct usb_host_interface *iface_desc = interface->cur_altsetting;

   pr_info("USB 3.x Device (Vendor: %04X, Product: %04X) connected.\n", id->idVendor, id->idProduct);
   pr_info("Device Speed: %s\n",
	    (udev->speed == USB_SPEED_SUPER) ? "SuperSpeed (USB 3.0)" :
	    (udev->speed == USB_SPEED_SUPER_PLUS) ? "SuperSpeed+ (USB 3.1/3.2)" :
	    "Lower Speed");

   // Example: Enumerate endpoints
   int i;
   for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
       struct usb_endpoint_descriptor *endpoint = &iface_desc->endpoint[i].desc;
       pr_info("Endpoint %d: Address=0x%02X, Attributes=0x%02X, Max Packet Size=%d\n",
       i, endpoint->bEndpointAddress, endpoint->bmAttributes, endpoint->wMaxPacketSize);
   }

   // Initialization code here

   return 0;
}
	      
static void usb_driver_disconnect(struct usb_interface *interface)  {
   pr_info("USB 3.x Device disconnected.\n");

   // Cleanup code here
}

static struct usb_driver usb_driver = {
   .name = "usb3x_driver",
   .id_table = usb_ids_table,
   .probe = usb_driver_probe,
   .disconnect = usb_driver_disconnect,
};

static int __init usb_driver_init(void)  {
   int result;
   result = usb_register(&usb_driver);
   if (result < 0) {
      pr_err("usb_register failed with error %d\n", result);
      return result;
   }
   pr_info("USB 3.x Driver Registered.\n");
   return 0;
}

static void __exit usb_driver_exit(void)  {
   usb_deregister(&usb_driver);
   pr_info("USB 3.x Driver Deregistered.\n");
}

module_init(usb_driver_init);
module_exit(usb_driver_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Your Name");
MODULE_DESCRIPTION("A comprehensive USB 3.x driver example.");  

• usb_device_id Table: Specifies the Vendor ID and Product ID of the USB device the driver will handle. Replace 0x1234 and 0x5678 with the actual IDs of the target device.
• Probe Function: Called when a device matching the usb_device_id table is connected. It retrieves device information, such as speed and endpoint details, and performs initialization tasks.
• Disconnect Function: Called when the device is disconnected. It handles cleanup tasks to ensure resources are properly released.
• Driver Registration: The usb_driver structure is registered with the kernel, enabling the driver to manage the specified USB devices.
• Endpoint Enumeration: The sample code includes enumeration of endpoints, which is useful for understanding the communication channels provided by the device.

This sample code demonstrates how to identify the USB device's speed (e.g., USB 3.0 SuperSpeed, USB 3.1 SuperSpeed+) and set up a basic USB driver in the Linux kernel that can be extended to perform specific functions with the USB device.

Conclusion

The evolution from USB 2.0 to USB 3.x represents significant advancements in data transfer rates, power delivery, and overall functionality. The introduction of new connector types, especially USB Type-C, has modernized the interface, making it more versatile and user-friendly. Electrical enhancements and improved data signaling methods have enabled higher speeds and better power efficiency, meeting the demands of contemporary computing devices.

Understanding these changes is crucial for developers, engineers, and users to fully leverage the capabilities of USB technology, ensuring compatibility and optimizing performance across various applications.

  | USB Version | Year Introduced  | Data Rate        | Encoding Scheme     | Max Power Output         | Connector Types                              |
  |-------------|------------------|------------------|---------------------|--------------------------|----------------------------------------------|
  | USB 2.0     | 2000             | 480 Mbps         | 8b/10b              | 5 V, 500 mA              | Type-A, Type-B, Mini, Micro-B                |
  | USB 3.0     | 2008             | 5 Gbps           | 8b/10b              | 5 V, 900 mA              | Type-A (Blue), Type-B, Micro-B SuperSpeed    |
  | USB 3.1     | 2013             | 10 Gbps          | 128b/132b           | 5 V, 900 mA              | Type-A, Type-C                               |
  | USB 3.2     | 2017             | Up to 20 Gbps    | 128b/132b           | 5 V, 900 mA              | Type-C                                       |
  | USB4        | 2019             | Up to 40 Gbps    | PCIe/TBT-based      | Up to 100 W (with USB PD)| Type-C (Integrates Thunderbolt 3 Technology) |

USB Protocols

The USB protocol establishes the communication rules and mechanisms between host systems and USB devices, ensuring structured data flow, power management, and efficient bandwidth utilization. USB 2.0 introduced a robust framework based on a tiered star topology and a host-centric control model, where the host schedules all transactions and devices respond accordingly. This polling-based system allows the host to manage bandwidth and ensures consistent data flow.

Building on this foundation, USB 3.x introduces significant protocol-level enhancements aimed at improving data throughput, reducing latency, and optimizing power management. Features such as asynchronous notifications, full-duplex data flow, and better bus utilization position USB 3.x as a superior protocol for high-performance and power-sensitive applications while maintaining backward compatibility with earlier versions.

Common USB Packet Fields

USB packets are composed of multiple fields, each serving a specific purpose in facilitating communication between hosts and devices.

    USB Protocols
    │
    ├── USB 2.0 Protocol
    │   ├── Tiered Star Topology
    │   ├── Host-Centric Control Model
    │   │   └── Host Schedules All Transactions
    │   ├── Polling-Based System
    │   │   └── Host Manages Bandwidth
    │   └── Structured Data Flow
    │
    └── USB 3.x Protocol
        ├── Builds on USB 2.0 Foundation
        ├── Protocol-Level Enhancements
        │   ├── Improved Data Throughput
        │   ├── Reduced Latency
        │   └── Optimized Power Management
        ├── Asynchronous Notifications
        ├── Full-Duplex Data Flow
        ├── Better Bus Utilization
        └── Maintains Backward Compatibility

USB 2.0 Packet Fields

USB 2.0 packets consist of several essential fields:

• Sync Field: Synchronizes the receiver's clock with the transmitter at the start of each packet.
• Packet Identifier (PID): Specifies the type of packet (e.g., token, data, handshake, or Start-of-Frame (SOF)).
• Address Field: Identifies the recipient device on the USB bus.
• Endpoint Field: Specifies the particular endpoint on the device involved in the data transfer.
• Frame Number: Used in SOF packets to synchronize timing for isochronous transfers.
• Data Payload: Contains the actual data being transferred.
• Cyclic Redundancy Check (CRC): Ensures data integrity by detecting transmission errors.

These fields form the basis for reliable communication on the USB 2.0 bus.

USB 3.x Packet Fields Enhancements

USB 3.x introduces new packet structures and fields to handle higher data rates and full-duplex communication:

• Link Management Packet (LMP) Header: Manages the physical link between devices, controlling link training, power management, and flow control.
• Transaction Packet (TP) Header: Contains routing and control information for data packets.
• Data Payload: Supports larger payload sizes, accommodating the increased bandwidth and bursting capabilities of USB 3.x.
• Header and Data CRCs: USB 3.x separates error detection for the header and data fields, improving the accuracy of error recovery.
• Sequence Number (Seq_Num): Used for data packet ordering and flow control.
• Packet Framing Fields: Enhanced framing fields to support the 8b/10b and 128b/132b encoding schemes used in USB 3.x.

These enhancements provide greater reliability and efficiency, especially at higher speeds.

    Common USB Packet Fields
    │
    ├── USB 2.0 Packet Fields
    │   ├── Sync Field
    │   ├── Packet Identifier (PID)
    │   ├── Address Field
    │   ├── Endpoint Field
    │   ├── Frame Number
    │   ├── Data Payload
    │   └── Cyclic Redundancy Check (CRC)
    │
    └── USB 3.x Packet Fields Enhancements 
        ├── Link Management Packet (LMP) Header  
        ├── Transaction Packet (TP) Header
        ├── Data Payload (Larger Sizes)
        ├── Header and Data CRCs (Separate)
        ├── Sequence Number (Seq_Num)
        └── Packet Framing Fields 

Comparison of USB 2.0 and USB 3.x Packet Fields

USB Packet Types

USB packet types define the structure of communication between hosts and devices by managing the flow of data.

USB 2.0 Packet Types

USB 2.0 defines several packet types, each serving a unique function:

• Token Packets: Control the direction of data flow with IN, OUT, and SETUP tokens.
• Data Packets: Carry the data payload, labeled as DATA0 or DATA1 to facilitate error checking through data toggling.
• Handshake Packets: Provide feedback on transactions, using signals like ACK (acknowledge), NAK (negative acknowledge), STALL, and NYET (no response yet).
• Start-of-Frame (SOF) Packets: Synchronize timing for isochronous and interrupt transfers.

These packet types ensure structured and efficient communication across the USB 2.0 bus.

USB 3.x Additional Packet Types

USB 3.x introduces new packet types to support its advanced features:

• Link Management Packets (LMPs): Manage the logical link between devices, controlling link training, flow control, and power management.
• Transaction Packets (TPs): Facilitate data transfers, consisting of:
  • Header Packets (HPs): Contain control information but no data payload.
  • Data Packets (DPs): Carry larger data payloads than USB 2.0 packets, supporting bursting modes.
  • Isochronous Timestamp Packets (ITPs): Provide precise timing for isochronous transfers, improving synchronization for time-sensitive data such as audio and video streams.
• Acknowledgment Packets: Used for flow control and error handling, ensuring reliable data transmission.

These additional packet types enhance the protocol’s capacity to handle high-speed data transfers and reduce latency, especially for multimedia applications.

    USB Packet Types
    │
    ├── USB 2.0 Packet Types
    │   ├── Token Packets
    │   │   ├── IN
    │   │   ├── OUT
    │   │   └── SETUP
    │   ├── Data Packets
    │   │   ├── DATA0
    │   │   └── DATA1
    │   ├── Handshake Packets
    │   │   ├── ACK (Acknowledge)
    │   │   ├── NAK (Negative Acknowledge)
    │   │   ├── STALL
    │   │   └── NYET (No Response Yet)
    │   └── Start-of-Frame (SOF) Packets
    │       └── Synchronize Timing for Isochronous Transfers
    │
    └── USB 3.x Additional Packet Types 
        ├── Link Management Packets (LMPs)
        │   ├── Manage Logical Links
        │   ├── Control Link Training
        │   ├── Flow Control
        │   └── Power Management
        ├── Transaction Packets (TPs)
        │   ├── Header Packets (HPs)
        │   └── Data Packets (DPs)
        ├── Isochronous Timestamp Packets (ITPs)
        │   └── Provide Precise Timing for Isochronous Transfers
        └── Acknowledgment Packets
            └── Used for Flow Control and Error Handling    

USB Functions

A "Function" in USB terminology refers to the specific capabilities provided by a USB device, such as data storage, input, or networking.

USB 2.0 Functions

USB 2.0 devices present one or more functions to the host, each potentially consisting of multiple interfaces. Functions communicate with the host using endpoints assigned during the enumeration process, where the host identifies the device and allocates resources. Functions are categorized by class codes, which help the host select the correct driver.

Common USB 2.0 device classes include:

• Human Interface Device (HID): Keyboards, mice, game controllers.
• Mass Storage: USB flash drives, external hard drives.
• Audio: Microphones, speakers.
• Video: Webcams.

USB 3.x Function Enhancements

USB 3.x retains the concept of functions but introduces enhancements:

• Increased Bandwidth: Supports higher data rates, facilitating demanding applications like high-definition video streaming and high-speed storage.
• More Endpoints: Devices can now support up to 16 IN and 16 OUT endpoints, allowing for greater flexibility in data handling.
• Advanced Power Management: Functions can utilize low-power states (e.g., U1 and U2) to conserve energy when idle.
• USB Attached SCSI Protocol (UASP): Replaces the older Bulk-Only Transport (BOT) protocol for mass storage devices, improving performance by allowing multiple commands to be processed in parallel.

These improvements enable USB 3.x devices to handle more complex operations and power-hungry applications while ensuring energy efficiency.

    USB Functions
    │
    ├── USB 2.0 Functions
    │   ├── Presentation to Host
    │   │   ├── One or More Functions per Device
    │   │   └── Each Function May Have Multiple Interfaces
    │   ├── Communication via Endpoints
    │   ├── Enumeration Process
    │   │   ├── Host Identifies Device
    │   │   └── Allocates Resources
    │   ├── Class Codes for Functions
    │   │   ├── HID (Human Interface Device)
    │   │   ├── Mass Storage
    │   │   ├── Audio
    │   │   └── Video
    │   └── Common Device Classes
    │       ├── Keyboards
    │       ├── Mice
    │       ├── Game Controllers
    │       ├── USB Flash Drives
    │       ├── External Hard Drives
    │       ├── Microphones
    │       ├── Speakers
    │       └── Webcams
    │
    └── USB 3.x Function Enhancements
        ├── Increased Bandwidth
        │   └── Supports High-Definition Video Streaming, High-Speed Storage
        ├── More Endpoints
        │   └── Up to 16 IN and 16 OUT Endpoints
        ├── Advanced Power Management
        │   └── Utilizes Low-Power States (U1, U2)
        ├── USB Attached SCSI Protocol (UASP)
        │   ├── Replaces Bulk-Only Transport (BOT)
        │   ├── Allows Multiple Concurrent Commands
        │   └── Reduces Latency
        └── Enhanced Device Functionality
            ├── Supports Complex Operations
            └── Energy Efficiency for Power-Hungry Applications

Endpoints

Endpoints serve as logical data sources or sinks within a USB device, identified by a unique endpoint number. Each endpoint manages data flow in one direction (either IN or OUT) and is used for communication between the host and the device.

USB 2.0 Endpoint Characteristics

Endpoint Zero: Reserved for control transfers during device enumeration and configuration.

Endpoint Types:

• Control Endpoints: Handle device configuration and command exchanges.
• Bulk Endpoints: Manage large, bursty data transfers with no guaranteed timing.
• Interrupt Endpoints: Facilitate small, time-sensitive transfers, such as those required by keyboards or mice.
• Isochronous Endpoints: Handle time-sensitive data streams with guaranteed bandwidth, typically used for audio or video applications.

USB 3.x Endpoint Enhancements

USB 3.x expands on USB 2.0 endpoint functionality with:

• Increased Endpoint Count: Supports up to 32 endpoints (16 IN and 16 OUT), allowing for more complex devices.
• Stream Protocol: Introduces streams within bulk endpoints, enabling multiple concurrent data flows, each identified by a unique Stream ID.
• Enhanced Scheduling: Improves the granularity of scheduling for isochronous and interrupt endpoints, optimizing performance for real-time applications like video or audio.
• Error Handling Improvements: Provides limited retries for isochronous transfers, enhancing reliability without compromising timing constraints.

    Endpoints
    │
    ├── Definition
    │   └── Logical Data Sources or Sinks within a USB Device
    │
    ├── Direction
    │   ├── IN (Device to Host)
    │   └── OUT (Host to Device)
    │
    ├── Identification
    │   └── Unique Endpoint Number
    │
    ├── USB 2.0 Endpoint Characteristics
    │   ├── Endpoint Zero
    │   │   └── Reserved for Control Transfers
    │   ├── Endpoint Types
    │   │   ├── Control Endpoints
    │   │   ├── Bulk Endpoints
    │   │   ├── Interrupt Endpoints
    │   │   └── Isochronous Endpoints
    │   └── Max Endpoints
    │       └── Up to 16 (including Endpoint 0)
    │
    └── USB 3.x Endpoint Enhancements
        ├── Increased Endpoint Count
        │   └── Up to 32 (16 IN, 16 OUT)
        ├── Stream Protocol
        │   └── Multiple Data Streams within Bulk Endpoints
        ├── Enhanced Scheduling
        │   └── Improved Granularity for Isochronous and Interrupt Endpoints
        └── Error Handling Improvements
            ├── Limited Retries for Isochronous Transfers
            └── Enhanced Reliability without Compromising Timing

Comparison of Endpoint Features

Pipes

A Pipe is a logical connection between the host controller and a device endpoint, facilitating data transfer operations. Pipes are categorized as either message pipes or stream pipes, depending on their function.

USB 2.0 Pipes

Message Pipes: Associated with control endpoints, supporting bidirectional communication and structured data exchange.

Stream Pipes: Linked to bulk, interrupt, or isochronous endpoints, handling unidirectional, unstructured data flow.

Each pipe has attributes such as transfer type (control, bulk, interrupt, or isochronous), data flow direction (IN or OUT), and maximum packet size.

USB 3.x Pipe Enhancements

USB 3.x introduces several refinements to the pipe model:

• Streams within Bulk Pipes: Allows a single bulk endpoint to manage multiple data streams using unique Stream IDs, improving throughput for high-demand devices like storage arrays.
• Enhanced Error Handling: Implements improved mechanisms for error detection and recovery, utilizing separate CRCs for headers and data to reduce data loss.
• Optimized Bandwidth Management: The host dynamically allocates bandwidth across pipes, ensuring critical transfers have priority and optimizing data flow for high-speed devices.
• Burst Transactions: Supports sending multiple packets in quick succession without waiting for acknowledgments, increasing data transfer efficiency.

    Pipes
    │
    ├── Definition
    │   └── Logical Connection between Host Controller and Device Endpoint
    │
    ├── Categories
    │   ├── Message Pipes
    │   │   └── Associated with Control Endpoints
    │   └── Stream Pipes
    │       └── Linked to Bulk, Interrupt, or Isochronous Endpoints
    │
    ├── Attributes
    │   ├── Transfer Type
    │   │   ├── Control
    │   │   ├── Bulk
    │   │   ├── Interrupt
    │   │   └── Isochronous
    │   ├── Data Flow Direction
    │   │   ├── IN
    │   │   └── OUT
    │   └── Maximum Packet Size
    │
    ├── USB 2.0 Pipes
    │   ├── Message Pipes
    │   │   ├── Bidirectional Communication
    │   │   └── Structured Data Exchange
    │   └── Stream Pipes
    │       ├── Unidirectional Data Flow
    │       └── Unstructured Data Handling
    │
    └── USB 3.x Pipe Enhancements
        ├── Streams within Bulk Pipes
        │   └── Multiple Data Streams using Unique Stream IDs
        ├── Enhanced Error Handling
        │   ├── Separate CRCs for Headers and Data
        │   └── Improved Error Detection and Recovery
        ├── Optimized Bandwidth Management
        │   └── Dynamic Bandwidth Allocation Prioritizing Critical Transfers
        └── Burst Transactions
            └── Multiple Packets Sent Succession Without Awaiting ACKs

Linux Kernel Driver Implementation

Interfacing with USB devices at the driver level is crucial for developers working on Linux systems. Below is an example of a Linux kernel driver handling a USB 3.x device, illustrating how to work with endpoints and streams.

    Linux Kernel USB 3.x Driver
    │
    ├── usb_device_id Table
    │   ├── Specifies Vendor ID
    │   ├── Specifies Product ID
    │   └── Example Entries
    │
    ├── Probe Function
    │   ├── Triggered on Device Connection
    │   ├── Retrieves Device Information
    │   │   ├── Vendor ID
    │   │   ├── Product ID
    │   │   └── Device Speed
    │   ├── Enumerates Endpoints
    │   └── Performs Initialization Tasks
    │
    ├── Disconnect Function
    │   ├── Triggered on Device Disconnection
    │   ├── Handles Cleanup Tasks
    │   └── Releases Resources
    │
    ├── usb_driver Structure
    │   ├── Name: "usb3x_driver"
    │   ├── id_table: usb_ids_table
    │   ├── probe: usb_driver_probe
    │   └── disconnect: usb_driver_disconnect
    │
    ├── Module Initialization and Exit
    │   ├── __init usb_driver_init()
    │   │   ├── Registers usb_driver
    │   │   └── Logs Registration Success or Failure
    │   ├── __exit usb_driver_exit()
    │   │   ├── Deregisters usb_driver
    │   │   └── Logs Deregistration
    │   ├── module_init(usb_driver_init)
    │   └── module_exit(usb_driver_exit)
    │
    └── Module Metadata
        ├── MODULE_LICENSE("GPL")
        ├── MODULE_AUTHOR("Your Name")
        └── MODULE_DESCRIPTION("A comprehensive USB 3.x driver example.")

#include <linux/module.h>
#include <linux/usb.h>

#define USB_VENDOR_ID  0x1234  // Replace with actual Vendor ID
#define USB_PRODUCT_ID 0x5678  // Replace with actual Product ID

struct usb_device_data {
   struct usb_device *udev;
   struct usb_interface *interface;
   unsigned char bulk_in_endpointAddr;
   unsigned char bulk_out_endpointAddr;
   struct usb_endpoint_descriptor *bulk_in_ep;
   struct usb_endpoint_descriptor *bulk_out_ep;

   // Additional fields for streams can be added here
};

static struct usb_device_id usb_table[] = {
   { USB_DEVICE(USB_VENDOR_ID, USB_PRODUCT_ID) },
   {} /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, usb_table);

static int usb_probe(struct usb_interface *interface, const struct usb_device_id *id) {
   struct usb_device_data *dev_data;
   struct usb_host_interface *iface_desc;
   struct usb_endpoint_descriptor *endpoint;
   int i;

   dev_data = kzalloc(sizeof(struct usb_device_data), GFP_KERNEL);
   if (!dev_data) {
      printk(KERN_ERR "Cannot allocate memory for device data\n");
      return -ENOMEM;
   }

   dev_data->udev = usb_get_dev(interface_to_usbdev(interface));
   dev_data->interface = interface;

   iface_desc = interface->cur_altsetting;
   printk(KERN_INFO "USB interface %d now probed\n", iface_desc->desc.bInterfaceNumber);

   for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
      endpoint = &iface_desc->endpoint[i].desc;

      if (usb_endpoint_is_bulk_in(endpoint)) {
         dev_data->bulk_in_endpointAddr = endpoint->bEndpointAddress;
         dev_data->bulk_in_ep = endpoint;
	 printk(KERN_INFO "Bulk IN endpoint found at 0x%02x\n", endpoint->bEndpointAddress);
      } else if (usb_endpoint_is_bulk_out(endpoint)) {
         dev_data->bulk_out_endpointAddr = endpoint->bEndpointAddress;
	 dev_data->bulk_out_ep = endpoint;
	 printk(KERN_INFO "Bulk OUT endpoint found at 0x%02x\n", endpoint->bEndpointAddress);
      }
   }

   usb_set_intfdata(interface, dev_data);
   printk(KERN_INFO "USB 3.x device attached\n");
   return 0;
}

static void usb_disconnect(struct usb_interface *interface) {
   struct usb_device_data *dev_data;

   dev_data = usb_get_intfdata(interface);
   usb_set_intfdata(interface, NULL);

   usb_put_dev(dev_data->udev);
   kfree(dev_data);

   printk(KERN_INFO "USB 3.x device disconnected\n");
}

static struct usb_driver usb_driver = {
   .name = "usb3x_driver",
   .id_table = usb_table,
   .probe = usb_probe,
   .disconnect = usb_disconnect,
};

module_usb_driver(usb_driver);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Author Name");
MODULE_DESCRIPTION("USB 3.x Device Driver Example");  

• Device Identification: Utilizes the USB_DEVICE macro to specify the Vendor ID and Product ID of the target USB device. Replace 0x1234 and 0x5678 with the actual IDs of the device being targeted.
• Probe Function: Invoked when a device matching the usb_device_id table is connected.
  • Allocates memory for device-specific data.
  • Retrieves and stores endpoint addresses for bulk IN and OUT transfers.
  • Logs information about the connected device and its endpoints.
• Disconnect Function: Called when the device is disconnected.
  • Cleans up allocated resources to prevent memory leaks.
  • Logs the disconnection event.
• Driver Registration: Defines the usb_driver structure, associating the driver name, device ID table, and callback functions (probe and disconnect).
• Endpoint Detection: Iterates over the available endpoints in the current interface to identify bulk IN and OUT endpoints.
  • Stores the addresses and descriptors of these endpoints for future data transfers.

This sample code provides a foundation for developing a USB 3.x driver that can handle multiple endpoints and streams, leveraging the advanced capabilities of the USB 3.x protocol. Developers can extend this driver by implementing data transfer operations, handling streams, and integrating additional functionalities as required by the specific USB device.

Summary of USB Protocol Enhancements

Table: USB Protocol Enhancements from 2.0 to 3.x

    Summary of USB 3.x Protocol Enhancements
    │
    ├── Packet Structures
    │   ├── Enhanced Packet Fields
    │   ├── New Packet Types
    │   └── Advanced Encoding Schemes
    │
    ├── Communication Improvements
    │   ├── Full-Duplex Data Flow
    │   ├── Asynchronous Notifications
    │   └── Reduced Latency
    │
    ├── Endpoint and Pipe Enhancements
    │   ├── Increased Endpoint Count
    │   ├── Stream Support within Bulk Endpoints
    │   └── Enhanced Pipe Management (Streams, Burst Transactions)
    │
    ├── Power Management Advancements
    │   ├── Multiple U-States (U1, U2, U3)
    │   ├── Link Power Management (LPM)
    │   └── USB Power Delivery (USB PD)
    │
    ├── Functional Enhancements
    │   ├── Increased Bandwidth and Data Rates
    │   ├── USB Attached SCSI Protocol (UASP)
    │   └── Advanced Device Functionality
    │
    ├── Integration with Modern Systems
    │   ├── xHCI Interface
    │   ├── Direct Memory Access (DMA)
    │   └── Linux Kernel Support
    │
    └── Backward Compatibility
        └── Maintains Compatibility with USB 2.0 Devices via Adapters and Protocol Support

    
    USB4 Integration
    │
    ├── Thunderbolt 3 Integration
    │   └── Provides up to 40 Gbps data transfer rates
    │
    ├── Alternate Modes
    │   ├── DisplayPort
    │   ├── Thunderbolt
    │   └── PCI Express
    │
    ├── Reversible Connector
    │   └── USB Type-C is the standard connector
    │
    ├── Power Delivery
    │   └── Supports up to 100 W with USB PD
    │
    └── Backward Compatibility
        └── Maintains compatibility with USB 3.x and USB 2.0 devices via adapters and cables

Conclusion

USB 3.x introduces significant advancements over USB 2.0, with improvements in packet structures, enhanced packet types, expanded endpoints, and more efficient pipe management. These developments result in faster data transfers, reduced latency, improved power management, and enhanced device functionality, all while maintaining backward compatibility. With these features, USB 3.x continues to evolve as a robust and versatile standard, meeting the needs of modern high-performance devices and applications.

Understanding these protocol-level changes is crucial for developers, engineers, and users to fully leverage the capabilities of USB technology, ensuring compatibility and optimizing performance across various applications.

Endpoint Types

USB devices utilize endpoints as dedicated communication channels between the host and device. These endpoints are unidirectional and categorized by both their type and direction (IN or OUT). Each endpoint is tailored to handle specific data transfer types based on the device's requirements, allowing for efficient and structured communication.

USB 2.0 Endpoint Types

USB 2.0 defines four primary endpoint types, each optimized for a particular data transfer mode:

Control Endpoints:

• Function: Handle device configuration, status operations, and command transfers.
• Usage: Essential for device enumeration and managing device states.

Interrupt Endpoints:

• Function: Facilitate small, infrequent, but time-sensitive data transfers.
• Usage: Commonly used by input devices such as keyboards and mice to ensure prompt responses.

Isochronous Endpoints:

• Function: Provide real-time data transfers where timely delivery is prioritized over error correction.
• Usage: Ideal for audio and video data streams that require consistent data flow without delays.

Bulk Endpoints:

• Function: Manage large, non-time-critical data transfers.
• Usage: Suitable for devices like printers and mass storage devices that require high data throughput without strict timing constraints.

Each endpoint type is essential for managing different data transfer needs, ensuring that USB devices operate efficiently across various applications.

USB 3.x Endpoint Enhancements

While USB 3.x retains the core endpoint types from USB 2.0, it introduces several enhancements to improve performance and scalability:

Increased Number of Endpoints:

• Capability: USB 3.x supports up to 16 IN and 16 OUT endpoints per device (excluding Control Endpoint 0).
• Benefit: Allows more complex devices with multiple data streams to operate simultaneously without endpoint contention.

Bulk Endpoint Streams:

• Capability: Enables multiple data streams over a single bulk endpoint, each identified by a unique Stream ID.
• Benefit: Improves transfer efficiency by allowing concurrent data flows, which is particularly beneficial for high-speed storage devices.

Improved Service Intervals:

• Capability: Enhanced scheduling granularity for interrupt and isochronous transfers.
• Benefit: Allows more efficient data handling, reducing latency and improving responsiveness for time-sensitive applications.

Advanced Power Management:

• Capability: Introduces more advanced power states (U1, U2, U3), enabling devices to reduce energy consumption during idle periods.
• Benefit: Enhances overall system power efficiency, especially for portable and battery-powered devices.

These enhancements ensure that USB 3.x can meet the demands of modern high-performance devices while maintaining backward compatibility with USB 2.0.

    Endpoint Types
    │
    ├── Definition
    │   └── Logical Communication Channels within USB Devices
    │       ├── Unidirectional (IN or OUT)
    │       └── Categorized by Type and Direction
    │
    ├── USB 2.0 Endpoint Types
    │   ├── Control Endpoints
    │   │   ├── Function: Handle device configuration, status operations, and command transfers
    │   │   └── Usage: Essential for device enumeration and managing device states
    │   │
    │   ├── Interrupt Endpoints
    │   │   ├── Function: Facilitate small, infrequent, but time-sensitive data transfers
    │   │   └── Usage: Commonly used by input devices such as keyboards and mice
    │   │
    │   ├── Isochronous Endpoints
    │   │   ├── Function: Provide real-time data transfers where timely delivery is prioritized over error correction
    │   │   └── Usage: Ideal for audio and video data streams
    │   │
    │   └── Bulk Endpoints
    │       ├── Function: Manage large, non-time-critical data transfers
    │       └── Usage: Suitable for devices like printers and mass storage devices
    │
    └── USB 3.x Endpoint Enhancements
        ├── Increased Number of Endpoints
        │   ├── Capability: Supports up to 16 IN and 16 OUT endpoints per device (excluding Endpoint 0)
        │   └── Benefit: Allows more complex devices with multiple data streams to operate simultaneously
        │
        ├── Bulk Endpoint Streams
        │   ├── Capability: Enables multiple data streams over a single bulk endpoint, each identified by a unique Stream ID
        │   └── Benefit: Improves transfer efficiency by allowing concurrent data flows
        │
        ├── Improved Service Intervals
        │   ├── Capability: Enhanced scheduling granularity for interrupt and isochronous transfers
        │   └── Benefit: Reduces latency and improves responsiveness for time-sensitive applications
        │
        └── Advanced Power Management
            ├── Capability: Introduces more advanced power states (U1, U2, U3)
            └── Benefit: Enables devices to reduce energy consumption during idle periods    

Comparison of USB 2.0 and USB 3.x Endpoint Features

Table 1: Comparison of USB 2.0 and USB 3.x Endpoint Features

Control Transfers

Control transfers are essential for device configuration, enumeration, and management. Every USB device must implement a control endpoint (Endpoint 0) for these operations.

USB 2.0 Control Transfers

• Function: Handle device enumeration, configuration, and command/status operations.
• Structure: Consist of a setup stage, an optional data stage, and a status stage.
• Bidirectional Communication: Support bidirectional data flow between the host and device.

USB 3.x Control Transfers

• Faster Bus Speed:
  • Benefit: Higher speeds reduce latency for control operations, enabling quicker device initialization and configuration.
• Extended Data Payloads:
  • Benefit: Support for larger payloads improves efficiency during complex control transfers, accommodating more comprehensive configuration commands.
• Improved Error Handling:
  • Benefit: Offers better error detection and recovery mechanisms, ensuring reliable communication even at higher speeds.
• Power Management:
  • Benefit: Devices can enter low-power states without disrupting control transfers, enhancing overall system power efficiency.

Control Transfers: The Bigger Picture

• Enumeration Process:
  • Description: During enumeration, the host detects a new device, assigns it a unique address, and uses control transfers to request device descriptors.
  • Descriptors: Provide essential information about the device's capabilities, such as configurations, interfaces, and endpoints.
• Device Configuration:
  • Description: Control transfers allow the host to configure the device after enumeration, setting parameters such as operational modes and handling device-specific commands.
  • USB 3.x Enhancements:
    • Faster Initialization: Increased bandwidth reduces device initialization time.
    • Extended Control Transfers: Larger payloads support more complex device configurations.
    • Improved Reliability: Enhanced error detection ensures consistent and reliable communication.

    Control Transfers
    │
    ├── Definition
    │   └── Essential for device configuration, enumeration, and management
    │
    ├── USB 2.0 Control Transfers
    │   ├── Function
    │   │   └── Handle device enumeration, configuration, and command/status operations
    │   ├── Structure
    │   │   ├── Setup Stage
    │   │   ├── Optional Data Stage
    │   │   └── Status Stage
    │   ├── Bidirectional Communication
    │   │   └── Supports data flow between host and device
    │   └── Usage
    │       └── Device enumeration and configuration, setting operational modes
    │
    ├── USB 3.x Control Transfers Enhancements
    │   ├── Faster Bus Speed
    │   │   └── Higher speeds reduce latency, enabling quicker device initialization and configuration
    │   ├── Extended Data Payloads
    │   │   └── Support for larger payloads improves efficiency during complex control transfers
    │   ├── Improved Error Handling
    │   │   └── Better error detection and recovery mechanisms ensure reliable communication
    │   └── Power Management
    │       └── Devices can enter low-power states without disrupting control transfers
    │
    └── Control Transfers: The Bigger Picture
        ├── Enumeration Process
        │   ├── Host detects a new device
        │   ├── Assigns a unique address
        │   └── Uses control transfers to request device descriptors
        ├── Descriptors
        │   └── Provide essential information about the device's capabilities (configurations, interfaces, endpoints)
        ├── Device Configuration
        │   ├── Control transfers allow the host to configure the device after enumeration
        │   └── Setting parameters such as operational modes and handling device-specific commands
        └── USB 3.x Enhancements
            ├── Faster Initialization
            ├── Extended Control Transfers
            └── Improved Reliability

Linux Kernel Driver Implementation

Understanding and handling Setup Packets is essential for developing USB device drivers. The Linux kernel provides mechanisms to process control requests sent to the device.

Example: Handling Control Requests in a USB Driver

Below is a simplified example of a Linux kernel module handling control requests for a USB device:

#include <linux/module.h>
#include <linux/usb/composite.h>

/* Function to handle setup requests */
static int my_usb_function_setup(struct usb_function *f, const struct usb_ctrlrequest *ctrl) {
   struct usb_composite_dev *cdev = f->config->cdev;
   u16 wValue = le16_to_cpu(ctrl->wValue);
   u16 wIndex = le16_to_cpu(ctrl->wIndex);
   u16 wLength = le16_to_cpu(ctrl->wLength);
   int ret = -EOPNOTSUPP;

   switch (ctrl->bRequest) {
      case USB_REQ_GET_DESCRIPTOR:
         if ((ctrl->bmRequestType & USB_DIR_IN) && (wValue >> 8) == USB_DT_DEVICE) {
            /* Handle GET_DESCRIPTOR request */
	    ret = usb_ep0_queue(cdev->gadget, cdev->req, GFP_ATOMIC);
         }
         break;
      case USB_REQ_SET_CONFIGURATION:
	  if (!(ctrl->bmRequestType & USB_DIR_IN)) {
             /* Handle SET_CONFIGURATION request */
	     ret = 0;
	  }
	  break;
      default:	  /* Stall for unsupported requests */
	  ret = -EOPNOTSUPP;
   }

   return ret;
}

/* Define the USB function structure */
static struct usb_function my_usb_function = {
   .name       = "my_usb_function",
   .setup      = my_usb_function_setup,
   /* Other function callbacks can be added here */
};

/* Initialize the USB gadget */
static int __init my_usb_init(void) {
   /* USB gadget initialization code goes here */
   return 0;
}

/* Cleanup the USB gadget */
static void __exit my_usb_exit(void) {
   /* Cleanup code goes here */
}

module_init(my_usb_init);
module_exit(my_usb_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Author Name");
MODULE_DESCRIPTION("USB Setup Packet Handling Example");  

• usb_function_setup: This function handles setup requests directed to the USB function. It parses the usb_ctrlrequest structure, interprets the request, and takes appropriate actions based on the request type.
  • GET_DESCRIPTOR: Checks if the request is for a device descriptor and queues a response if appropriate.
  • SET_CONFIGURATION: Handles configuration requests by setting the device's configuration.
  • Default Case: Returns an error (-EOPNOTSUPP) for unsupported requests, causing the device to stall.
• usb_function Structure: Defines the USB function, associating the setup callback with the my_usb_function_setup function.
• Module Initialization and Cleanup: Registers and deregisters the USB function with the USB subsystem.

This driver provides a basic framework for reading and interpreting USB device descriptors, serving as a foundation for more complex driver development tasks.

Accessing Setup Packet Fields

Within the my_usb_function_setup function, the fields of the Setup Packet can be accessed using the usb_ctrlrequest structure:

• ctrl->bmRequestType: Accesses the bmRequestType field.
• ctrl->bRequest: Accesses the bRequest field.
• le16_to_cpu(ctrl->wValue): Converts wValue from little-endian to CPU byte order.
• le16_to_cpu(ctrl->wIndex):: Converts wIndex from little-endian to CPU byte order.
• le16_to_cpu(ctrl->wLength):: Converts wLength from little-endian to CPU byte order.

This allows the driver to interpret and respond to various control requests effectively.

Interrupt Transfers

Interrupt transfers are designed for small, infrequent data transfers that require prompt servicing by the host. They are often used by input devices such as keyboards and mice to ensure timely responses.

USB 2.0 Interrupt Transfers

• Polling Mechanism: The host regularly polls the device to check for data.
• Guaranteed Service Interval: Ensures timely responses for devices requiring consistent polling, maintaining responsiveness for user inputs.

USB 3.x Interrupt Transfers

• Faster Polling:
  • Benefit: Higher bus speeds reduce polling latency, allowing for quicker data retrieval and device responsiveness.
• More Interrupt Endpoints:
  • Capability: Supports additional interrupt endpoints per device.
  • Benefit: Enables more complex peripherals to operate efficiently without overwhelming the host controller.
• Asynchronous Notifications:
  • Capability: Devices can send notifications asynchronously.
  • Benefit: Reduces the need for constant host polling, freeing up bandwidth for other data transfers and improving overall system efficiency.

    Interrupt Transfers
    │
    ├── Definition
    │   └── Designed for small, infrequent data transfers that require prompt servicing by the host
    │
    ├── USB 2.0 Interrupt Transfers
    │   ├── Polling Mechanism
    │   │   └── Host regularly polls the device to check for data
    │   ├── Guaranteed Service Interval
    │   │   └── Ensures timely responses for devices requiring consistent polling
    │   └── Usage
    │       └── Commonly used by input devices such as keyboards and mice
    │
    ├── USB 3.x Interrupt Transfers Enhancements
    │   ├── Faster Polling
    │   │   └── Higher bus speeds reduce polling latency, allowing for quicker data retrieval
    │   ├── More Interrupt Endpoints
    │   │   └── Supports additional interrupt endpoints per device
    │   └── Asynchronous Notifications
    │       └── Devices can send notifications asynchronously, reducing the need for constant host polling
    │
    └── Linux Kernel Driver Example for Interrupt Transfers
        ├── Sample Code Overview
        │   └── Handle interrupt transfers in a Linux kernel module
        ├── Sample Code Structure
        │   ├── Includes
        │   ├── Data Structures
        │   ├── Callback Function for Interrupt URB
        │   ├── Probe Function
        │   ├── Disconnect Function
        │   ├── USB Device ID Table
        │   ├── USB Driver Structure
        │   └── Module Registration
        └── Explanation of Sample Code Components
            ├── irq_callback Function
            │   ├── Handles data received from the interrupt endpoint
            │   ├── Processes the data if the transfer is successful
            │   └── Resubmits the URB to continue listening for future interrupt data
            ├── usb_probe Function
            │   ├── Invoked when a device matching the usb_table is connected
            │   ├── Finds and stores interrupt IN endpoint address
            │   ├── Allocates and initializes the URB for interrupt transfers
            │   └── Submits the URB to start receiving interrupt data
            ├── usb_disconnect Function
            │   ├── Called when the device is disconnected
            │   ├── Cleans up resources by killing and freeing the URB
            │   └── Releases allocated memory
            ├── Driver Registration
            │   └── Defines the usb_driver structure and associates it with probe and disconnect functions
            └── Module Metadata
                ├── MODULE_LICENSE("GPL")
                ├── MODULE_AUTHOR("Author Name")
                └── MODULE_DESCRIPTION("USB Interrupt Transfer Driver Example") 

Linux Kernel Driver Example for Interrupt Transfers

An example of handling interrupt transfers in a Linux kernel module:

#include <linux/module.h>
#include <linux/usb.h>

#define USB_VENDOR_ID  0x1234
#define USB_PRODUCT_ID 0x5678

struct usb_device_data {
   struct usb_device *udev;
   struct urb *irq_urb;
   unsigned char *irq_buffer;
   size_t irq_buffer_len;
   unsigned char irq_endpointAddr;
};

/* Callback function for interrupt URB */
static void irq_callback(struct urb *urb) {
   struct usb_device_data *dev_data = urb->context;
   int retval;

   if (urb->status == 0) {
      /* Process the received data */
      printk(KERN_INFO "Interrupt data received\n");
   } else {
      printk(KERN_ERR "Interrupt transfer failed: %d\n", urb->status);
   }

   /* Resubmit the URB for continuous listening */
   retval = usb_submit_urb(dev_data->irq_urb, GFP_ATOMIC);

   if (retval)
      printk(KERN_ERR "Resubmitting interrupt URB failed: %d\n", retval);
}

/* Probe function called when a matching device is connected */
static int usb_probe(struct usb_interface *interface, const struct usb_device_id *id) {
   struct usb_device_data *dev_data;
   struct usb_endpoint_descriptor *endpoint;
   int retval;

   /* Allocate memory for device-specific data */
   dev_data = kzalloc(sizeof(struct usb_device_data), GFP_KERNEL);
   if (!dev_data)
      return -ENOMEM;

   /* Get the USB device associated with this interface */
   dev_data->udev = usb_get_dev(interface_to_usbdev(interface));

   /* Find the first interrupt IN endpoint */
   endpoint = usb_find_int_in_endpoint(interface->cur_altsetting);
   if (!endpoint) {
      printk(KERN_ERR "No interrupt IN endpoint found\n");
      retval = -ENODEV;
      goto error;
   }

   dev_data->irq_endpointAddr = endpoint->bEndpointAddress;
   dev_data->irq_buffer_len = usb_endpoint_maxp(endpoint);
   dev_data->irq_buffer = kmalloc(dev_data->irq_buffer_len, GFP_KERNEL);
   if (!dev_data->irq_buffer) {
      retval = -ENOMEM;
      goto error_buffer;
   }

   /* Allocate and initialize the URB */
   dev_data->irq_urb = usb_alloc_urb(0, GFP_KERNEL);
   if (!dev_data->irq_urb) {
      retval = -ENOMEM;
      goto error_buffer;
   }

   usb_fill_int_urb(dev_data->irq_urb, dev_data->udev,
   usb_rcvintpipe(dev_data->udev, dev_data->irq_endpointAddr),
   dev_data->irq_buffer, dev_data->irq_buffer_len,
   irq_callback, dev_data, endpoint->bInterval);

   /* Submit the URB */rr
   retval = usb_submit_urb(dev_data->irq_urb, GFP_KERNEL);
   if (retval) {
      printk(KERN_ERR "Submitting interrupt URB failed: %d\n", retval);
      goto error_urb;
   }

   /* Store the device-specific data in the interface's data pointer */
   usb_set_intfdata(interface, dev_data);
   printk(KERN_INFO "USB interrupt device connected\n");
   return 0;

   error_urb:
      usb_free_urb(dev_data->irq_urb);
   error_buffer:
      kfree(dev_data->irq_buffer);
   error:
      kfree(dev_data);

   return retval;
}

/* Disconnect function called when the device is disconnected */
static void usb_disconnect(struct usb_interface *interface) {
   struct usb_device_data *dev_data = usb_get_intfdata(interface);

   /* Kill and free the URB */
   usb_kill_urb(dev_data->irq_urb);
   usb_free_urb(dev_data->irq_urb);

   /* Free the allocated buffer and device data */
   kfree(dev_data->irq_buffer);
   usb_put_dev(dev_data->udev);
   kfree(dev_data);

   printk(KERN_INFO "USB interrupt device disconnected\n");
}

/* Define the USB device ID table */
static struct usb_device_id usb_table[] = {
   { USB_DEVICE(USB_VENDOR_ID, USB_PRODUCT_ID) },
   {} /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, usb_table);

/* Define the USB driver structure */
static struct usb_driver usb_driver = {
   .name = "usb_irq_driver",
   .id_table = usb_table,
   .probe = usb_probe,
   .disconnect = usb_disconnect,
};

/* Register the USB driver with the USB subsystem */
module_usb_driver(usb_driver);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Author Name");
MODULE_DESCRIPTION("USB Interrupt Transfer Driver Example");  

• irq_callback Function:
  • Handles data received from the interrupt endpoint.
  • Processes the data if the transfer is successful.
  • Resubmits the URB to continue listening for future interrupt data.
• usb_probe Function:
  • Invoked when a device matching the usb_table is connected.
  • Finds and stores interrupt IN endpoint address.
  • Allocates and initializes the URB for interrupt transfers.
  • Submits the URB to start receiving interrupt data.
• usb_disconnect Function:
  • Called when the device is disconnected.
  • Cleans up resources by killing and freeing the URB and releasing allocated memory.
• Driver Registration:
  • Defines the usb_driver structure, associating the driver name, device ID table, and callback functions (probe and disconnect).
  • Registers the driver with the USB subsystem using module_usb_driver, which handles module initialization and cleanup.

This driver framework facilitates the handling of interrupt transfers, ensuring that input devices can communicate efficiently and responsively with the host system.

Isochronous Transfers

Isochronous transfers prioritize timely data delivery over error correction, making them ideal for real-time data streams such as audio and video.

USB 2.0 Isochronous Transfers

• Guaranteed Bandwidth: Ensures a consistent data delivery rate for real-time applications, maintaining the flow of time-sensitive data without interruption.
• No Error Retransmission: Errors are not retransmitted to preserve the real-time nature of the data, accepting occasional data loss to maintain timing.

USB 3.x Isochronous Transfers

• Higher Bandwidth:
  • Capability: Supports high-definition audio and video streams with increased data rates.
  • Benefit: Accommodates more complex and higher-resolution multimedia applications.
• Larger Payloads:
  • Capability: Allows for larger data payloads, reducing overhead and increasing efficiency.
  • Benefit: Enables the transmission of more data per transfer, improving throughput for high-bandwidth applications.
• Isochronous Timestamp Packets (ITPs):
  • Capability: Provide precise timing information to synchronize data streams between the host and device.
  • Benefit: Ensures accurate timing for real-time applications, enhancing synchronization and reducing latency.
• Limited Error Handling:
  • Capability: Introduces limited retries for isochronous transfers.
  • Benefit: Enhances reliability without significantly impacting latency, balancing data integrity with real-time performance.

    Isochronous Transfers
    │
    ├── Definition
    │   └── Prioritize timely data delivery over error correction, ideal for real-time data streams
    │
    ├── USB 2.0 Isochronous Transfers
    │   ├── Guaranteed Bandwidth
    │   │   └── Ensures consistent data delivery rate for real-time applications
    │   ├── No Error Retransmission
    │   │   └── Accepts occasional data loss to maintain timing
    │   └── Usage
    │       └── Ideal for audio and video data streams
    │
    └── USB 3.x Isochronous Transfers Enhancements
            └── Higher Bandwidth
                │   └── Supports high-definition audio and video streams with increased data rates
                ├── Larger Payloads
                │   └── Allows for larger data payloads, reducing overhead and increasing efficiency
                ├── Isochronous Timestamp Packets (ITPs)
                │   ├── Provide precise timing information to synchronize data streams
                │   └── Ensures accurate timing for real-time applications
                └── Limited Error Handling
                    ├── Introduces limited retries for isochronous transfers
                    └── Enhances reliability without significantly impacting latency

Linux Kernel Driver Example for Isochronous Transfers

An example of handling isochronous transfers in a Linux kernel module:

#include <linux/module.h>
#include <linux/usb.h>

#define USB_VENDOR_ID     0x1234
#define USB_PRODUCT_ID    0x5678
#define ISO_PACKET_COUNT  8

struct usb_device_data {
   struct usb_device *udev;
   struct urb *iso_urb;
   unsigned char *iso_buffer;
   unsigned char iso_endpointAddr;
};

/* Callback function for isochronous URB */
static void iso_callback(struct urb *urb) {
   int i;
   for (i = 0; i < urb->number_of_packets; i++) {
      if (urb->iso_frame_desc[i].status == 0) {
         /* Process the received data */
         printk(KERN_INFO "Isochronous data received in frame %d\n", i);
      } else {
         printk(KERN_ERR "Isochronous transfer error in frame %d: %d\n", i, urb->iso_frame_desc[i].status);
      }
   }

   /* Resubmit the URB for continuous streaming */
   if (usb_submit_urb(urb, GFP_ATOMIC))
      printk(KERN_ERR "Resubmitting isochronous URB failed\n");
}

/* Probe function called when a matching device is connected */
static int usb_probe(struct usb_interface *interface, const struct usb_device_id *id)  {
   struct usb_device_data *dev_data;
   struct usb_endpoint_descriptor *endpoint;
   int retval, i;

   /* Allocate memory for device-specific data */
   dev_data = kzalloc(sizeof(struct usb_device_data), GFP_KERNEL);
   if (!dev_data)
      return -ENOMEM;
  
   /* Get the USB device associated with this interface */
   dev_data->udev = usb_get_dev(interface_to_usbdev(interface));
   endpoint = &interface->cur_altsetting->endpoint[0].desc;

   /* Find the first isochronous IN endpoint */
   if (!usb_endpoint_is_isoc_in(endpoint)) {
      printk(KERN_ERR "No isochronous IN endpoint found\n");
      retval = -ENODEV;
      goto error;
   }

   dev_data->iso_endpointAddr = endpoint->bEndpointAddress;
   dev_data->iso_buffer = kmalloc(ISO_PACKET_COUNT * usb_endpoint_maxp(endpoint), GFP_KERNEL);
   if (!dev_data->iso_buffer) {
      retval = -ENOMEM;
      goto error_buffer;
   }
  
   /* Allocate and initialize the URB */
   dev_data->iso_urb = usb_alloc_urb(ISO_PACKET_COUNT, GFP_KERNEL);
   if (!dev_data->iso_urb) {
      retval = -ENOMEM;
      goto error_buffer;
   }

   usb_fill_iso_urb(dev_data->iso_urb, dev_data->udev,
   usb_rcvisocpipe(dev_data->udev, dev_data->iso_endpointAddr),
   dev_data->iso_buffer,
   ISO_PACKET_COUNT * usb_endpoint_maxp(endpoint),
   iso_callback, dev_data, 0);

   dev_data->iso_urb->transfer_flags = URB_ISO_ASAP;
   dev_data->iso_urb->number_of_packets = ISO_PACKET_COUNT;

   /* Initialize isochronous frame descriptors */
   for (i = 0; i < ISO_PACKET_COUNT; i++) {
      dev_data->iso_urb->iso_frame_desc[i].offset = i * usb_endpoint_maxp(endpoint);
      dev_data->iso_urb->iso_frame_desc[i].length = usb_endpoint_maxp(endpoint);
   }

   /* Submit the URB */
   retval = usb_submit_urb(dev_data->iso_urb, GFP_KERNEL);
   if (retval) {
      printk(KERN_ERR "Submitting isochronous URB failed: %d\n", retval);
      goto error_urb;
   }
    
   /* Store the device-specific data in the interface's data pointer */
   usb_set_intfdata(interface, dev_data);
   printk(KERN_INFO "USB isochronous device connected\n");
   return 0;

   error_urb:
      usb_free_urb(dev_data->iso_urb);
   error_buffer:
      kfree(dev_data->iso_buffer);
   error:
      kfree(dev_data);
   return retval;
}

/* Disconnect function called when the device is disconnected */
static void usb_disconnect(struct usb_interface *interface)  {
   struct usb_device_data *dev_data = usb_get_intfdata(interface);

   /* Kill and free the URB */
   usb_kill_urb(dev_data->iso_urb);
   usb_free_urb(dev_data->iso_urb);

   /* Free the allocated buffer and device data */
   kfree(dev_data->iso_buffer);
   usb_put_dev(dev_data->udev);
   kfree(dev_data);

   printk(KERN_INFO "USB isochronous device disconnected\n");
}

/* Define the USB device ID table */
static struct usb_device_id usb_table[] = {
    { USB_DEVICE(USB_VENDOR_ID, USB_PRODUCT_ID) },
    {} /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, usb_table);

/* Define the USB driver structure */
static struct usb_driver usb_driver = {
   .name = "usb_iso_driver",
   .id_table = usb_table,
   .probe = usb_probe,
   .disconnect = usb_disconnect,
};

/* Register the USB driver with the USB subsystem */
module_usb_driver(usb_driver);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Author Name");
MODULE_DESCRIPTION("USB Isochronous Transfer Driver Example");  

• iso_callback Function:
  • Processes each isochronous frame received.
  • Checks the status of each frame and logs whether the data was received successfully or if there was an error.
  • Resubmits the URB to continue receiving isochronous data.
• usb_probe Function:
  • Invoked when a device matching the usb_table is connected.
  • Finds and stores isochronous IN endpoint address.
  • Allocates and initializes the URB for isochronous transfers with multiple frames.
  • Submits the URB to start receiving isochronous data.
• usb_disconnect Function:
  • Called when the device is disconnected.
  • Cleans up resources by killing and freeing the URB and releasing allocated memory.
• Driver Registration:
  • Defines the usb_driver structure, associating the driver name, device ID table, and callback functions (probe and disconnect).
  • Registers the driver with the USB subsystem using module_usb_driver, which handles module initialization and cleanup.

This driver framework facilitates the handling of isochronous transfers, ensuring that real-time data streams such as audio and video can be transmitted efficiently and reliably between the USB device and the host system.

Bulk Transfers

Bulk transfers are optimized for large, non-time-sensitive data transfers, such as those used by mass storage devices or printers.

USB 2.0 Bulk Transfers

• Flexible Bandwidth Usage: Utilize leftover bus capacity after time-critical transfers (like interrupt and isochronous) have been serviced.
• Error Detection and Retransmission: Ensure data integrity by retransmitting data in case of errors, maintaining reliable communication.

USB 3.x Bulk Transfers

• Bulk Streams:
  • Capability: Multiple data streams can now be handled over a single bulk endpoint, each identified by a unique Stream ID.
  • Benefit: Optimizes throughput by allowing concurrent data flows, reducing the overhead associated with managing multiple endpoints.
• Larger Packet Sizes:
  • Capability: Support for larger packets (up to 1,024 bytes) reduces overhead and increases transfer efficiency.
  • Benefit: Enhances data transfer rates, particularly beneficial for high-speed storage devices.
• Higher Throughput:
  • Capability: Increased bandwidth enables faster data transfers, taking full advantage of USB 3.x's SuperSpeed capabilities.
  • Benefit: Improves performance for data-intensive applications, reducing transfer times for large files.

Bulk Streams in USB 3.x

Bulk streams are a significant enhancement introduced in USB 3.x, allowing a single bulk endpoint to manage multiple data streams concurrently.

• Stream IDs:
  • Function: Each data stream is identified by a unique Stream ID.
  • Benefit: Enables the differentiation and management of multiple concurrent data flows within a single bulk endpoint, improving efficiency and reducing the need for multiple endpoints.
• Enhanced Command Queuing:
  • Function: Allows multiple commands to be queued and processed in parallel.
  • Benefit: Improves performance for storage devices by enabling simultaneous processing of multiple data transfer requests, reducing latency and increasing throughput.

    Bulk Transfers
    │
    ├── Definition
    │   └── Optimized for large, non-time-sensitive data transfers
    │       ├── Suitable for mass storage devices, printers
    │       └── Ensures high data throughput without strict timing constraints
    │
    ├── USB 2.0 Bulk Transfers
    │   ├── Flexible Bandwidth Usage
    │   │   └── Utilize leftover bus capacity after servicing time-critical transfers
    │   ├── Error Detection and Retransmission
    │   │   └── Ensure data integrity by retransmitting data in case of errors
    │   └── Usage
    │       └── Ideal for devices requiring high data throughput without strict timing
    │
    ├── USB 3.x Bulk Transfers Enhancements
    │   ├── Bulk Streams
    │   │   ├── Capability: Multiple data streams handled over a single bulk endpoint
    │   │   └── Benefit: Optimizes throughput by allowing concurrent data flows
    │   │
    │   ├── Larger Packet Sizes
    │   │   ├── Capability: Support for larger packets (up to 1,024 bytes)
    │   │   └── Benefit: Reduces overhead and increases transfer efficiency
    │   │
    │   ├── Higher Throughput
    │   │   ├── Capability: Increased bandwidth enables faster data transfers
    │   │   └── Benefit: Improves performance for data-intensive applications
    │   │
    │   └── Enhanced Command Queuing
    │       ├── Capability: Allows multiple commands to be queued and processed in parallel
    │       └── Benefit: Reduces latency and increases throughput for storage devices
    │
    └── Bulk Streams in USB 3.x
        ├── Stream IDs
        │   ├── Function: Identify each data stream
        │   └── Benefit: Differentiates and manages multiple concurrent data flows
        │
        └── Enhanced Command Queuing
               ├── Function: Queue and process multiple data transfer requests simultaneously
               └── Benefit: Reduces latency and increases throughput 

Linux Kernel Driver Example for Bulk Transfers with Streams

An example of handling bulk transfers with streams in a Linux kernel module:

#include <linux/module.h>
#include <linux/usb.h>
  
#define USB_VENDOR_ID    0x1234
#define USB_PRODUCT_ID   0x5678
#define BULK_STREAM_ID   1

struct usb_device_data {
   struct usb_device *udev;
   unsigned char bulk_out_endpointAddr;
   unsigned char bulk_in_endpointAddr;
};

/* Probe function called when a matching device is connected */
static int usb_probe(struct usb_interface *interface, const struct usb_device_id *id) {
   struct usb_device_data *dev_data;
   struct usb_host_endpoint *endpoint;
   int retval;

   /* Allocate memory for device-specific data */
   dev_data = kzalloc(sizeof(struct usb_device_data), GFP_KERNEL);
   if (!dev_data)
      return -ENOMEM;

   /* Get the USB device associated with this interface */
   dev_data->udev = usb_get_dev(interface_to_usbdev(interface));

   /* Locate bulk OUT endpoint */
   endpoint = usb_find_bulk_out_endpoint(interface->cur_altsetting);
   if (!endpoint) {
      printk(KERN_ERR "No bulk OUT endpoint found\n");
      retval = -ENODEV;
      goto error;
   }
   dev_data->bulk_out_endpointAddr = endpoint->desc.bEndpointAddress;

   /* Locate bulk IN endpoint */
   endpoint = usb_find_bulk_in_endpoint(interface->cur_altsetting);
   if (!endpoint) {
      printk(KERN_ERR "No bulk IN endpoint found\n");
      retval = -ENODEV;
      goto error;
   }
   dev_data->bulk_in_endpointAddr = endpoint->desc.bEndpointAddress;

   /* Allocate bulk streams (up to 65,536 streams) */
   retval = usb_alloc_streams(interface, &endpoint, 1, 1);
   if (retval) {
      printk(KERN_ERR "Failed to allocate streams: %d\n", retval);
      goto error;
   }

   /* Store the device-specific data in the interface's data pointer */
   usb_set_intfdata(interface, dev_data);
   printk(KERN_INFO "USB bulk device with streams connected\n");
   return 0;

   error:
      kfree(dev_data);
      return retval;
}

/* Disconnect function called when the device is disconnected */
static void usb_disconnect(struct usb_interface *interface) {
   struct usb_device_data *dev_data = usb_get_intfdata(interface);

   /* Free allocated streams */
   usb_free_streams(interface, &interface->cur_altsetting->endpoint[0], 1);

   /* Release the USB device and free allocated memory */
   usb_put_dev(dev_data->udev);
   kfree(dev_data);

   printk(KERN_INFO "USB bulk device disconnected\n");
}

/* Define the USB device ID table */
static struct usb_device_id usb_table[] = {
  { USB_DEVICE(USB_VENDOR_ID, USB_PRODUCT_ID) },
  {} /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, usb_table);

/* Define the USB driver structure */
static struct usb_driver usb_driver = {
   .name = "usb_bulk_stream_driver",
   .id_table = usb_table,
   .probe = usb_probe,
   .disconnect = usb_disconnect,
};

/* Register the USB driver with the USB subsystem */
module_usb_driver(usb_driver);
  
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Author Name");
MODULE_DESCRIPTION("USB Bulk Transfer with Streams Driver Example");  

• usb_alloc_streams Function:
  • Allocates stream IDs for bulk endpoints, enabling multiple concurrent data streams within a single bulk endpoint.
• usb_probe Function:
  • Invoked when a device matching the usb_table is connected.
  • Finds and stores bulk IN and OUT endpoint addresses.
  • Allocates streams for bulk transfers to support concurrent data flows.
• usb_disconnect Function:
  • Called when the device is disconnected.
  • Frees allocated streams and cleans up resources by releasing the USB device and freeing allocated memory.
• Driver Registration:
  • Defines the usb_driver structure, associating the driver name, device ID table, and callback functions (probe and disconnect).
  • Registers the driver with the USB subsystem using module_usb_driver, which handles module initialization and cleanup.

This driver framework facilitates the handling of bulk transfers with streams, ensuring that high-speed storage devices and other data-intensive peripherals can operate efficiently by managing multiple data streams concurrently.

Bandwidth Management

Effective bandwidth management ensures that all devices connected to the USB bus can operate efficiently without interference.

USB 2.0 Bandwidth Allocation

• Priority for Isochronous and Interrupt Transfers:
  • Description: These transfer types are given priority to meet their timing requirements, ensuring that time-sensitive data is transmitted promptly.
• Frame-Based Scheduling:
  • Description: The host schedules transactions within 1-millisecond frames, with Start-of-Frame (SOF) packets marking the start of each frame.
  • Benefit: Organizes data transfers in a predictable manner, maintaining consistent performance across different devices.

USB 3.x Bandwidth Enhancements

• Microframes:
  • Description: Utilizes 125-microsecond microframes instead of 1-millisecond frames.
  • Benefit: Allows more granular scheduling and better bandwidth distribution, enhancing the efficiency of data transfers.
• Dynamic Bandwidth Allocation:
  • Description: Bandwidth is dynamically allocated based on device needs.
  • Benefit: Ensures that critical transfers receive priority and that bandwidth is utilized optimally, adapting to varying data transfer demands.
• Improved Host Controller Scheduling:
  • Description: Enhanced algorithms for scheduling ensure optimal bandwidth management across connected devices.
  • Benefit: Reduces bottlenecks and ensures fair distribution of bandwidth, improving overall system performance.
• Asynchronous Notifications:
  • Description: Devices can send notifications asynchronously.
  • Benefit: Reduces the need for constant polling by the host, freeing up bandwidth for other operations and improving system efficiency.

Latency Tolerance Messaging (LTM)

• Purpose: Allows devices to inform the host of their latency tolerance, enabling the host to make better power management decisions.
• Benefit: Enhances power efficiency by allowing the host to enter deeper power-saving states without adversely affecting device performance.

Summary

USB 3.x provides significant enhancements to endpoint functionality and data transfer mechanisms compared to USB 2.0:

• Control Transfers: Faster initialization and extended payloads enable quicker device setup and more complex configurations.
• Interrupt Transfers: Lower latency and asynchronous notifications improve responsiveness for input devices and reduce bus overhead.
• Isochronous Transfers: Higher bandwidth and improved synchronization support high-definition multimedia applications.
• Bulk Transfers: Increased data rates and bulk streams enhance performance for storage devices and printers.
• Bandwidth Management: Microframes and dynamic allocation optimize bus utilization, ensuring efficient operation even with multiple high-bandwidth devices.

These advancements make USB 3.x a high-performance, scalable standard that can meet the growing demands of modern peripherals while maintaining backward compatibility with previous USB generations.

    Summary of USB Protocol Enhancements from 2.0 to 3.x
    │
    ├── Packet Structures
    │   ├── Enhanced Packet Fields
    │   ├── New Packet Types
    │   └── Advanced Encoding Schemes
    │
    ├── Communication Improvements
    │   ├── Full-Duplex Data Flow
    │   ├── Asynchronous Notifications
    │   └── Reduced Latency
    │
    ├── Endpoint and Pipe Enhancements
    │   ├── Increased Endpoint Count
    │   ├── Stream Support within Bulk Endpoints
    │   └── Enhanced Pipe Management (Streams, Burst Transactions)
    │
    ├── Power Management Advancements
    │   ├── Multiple U-States (U1, U2, U3)
    │   ├── Link Power Management (LPM)
    │   └── USB Power Delivery (USB PD)
    │
    ├── Functional Enhancements
    │   ├── Increased Bandwidth and Data Rates
    │   ├── USB Attached SCSI Protocol (UASP)
    │   └── Advanced Device Functionality
    │
    ├── Integration with Modern Systems
    │   ├── xHCI Interface
    │   ├── Direct Memory Access (DMA)
    │   └── Linux Kernel Support
    │
    └── Backward Compatibility
        └── Maintains Compatibility with USB 2.0 Devices via Adapters and Protocol Support 

USB Descriptors

USB descriptors are fundamental data structures utilized by USB devices to communicate their capabilities, configurations, and power requirements to the host during the enumeration process. These descriptors provide the host with essential information, enabling it to load appropriate drivers and establish effective communication with the device. Descriptors encompass details ranging from device type and supported configurations to power needs, ensuring seamless interaction between the device and the host system.

Overview of USB Descriptors

USB descriptors are organized hierarchically, mirroring the internal architecture of the device. This hierarchical structure facilitates the host's ability to sequentially gather comprehensive information about the device, starting from its overarching characteristics and progressively delving into specific configurations, interfaces, and endpoints.

Hierarchy of USB Descriptors:

• Device Descriptor: Provides general information about the USB device.
• Configuration Descriptors: Describe device power requirements and the number of interfaces.
• Interface Descriptors: Define individual interfaces within a configuration.
• Endpoint Descriptors: Specify details about each endpoint used by an interface.
• String Descriptors: Contain human-readable information such as manufacturer and product names.
• Additional Descriptors (USB 3.x): Include Binary Device Object Store (BOS) and SuperSpeed Endpoint Companion descriptors.

This structured organization ensures that the host can efficiently interpret and utilize the device's capabilities, facilitating optimal performance and compatibility.

    USB Descriptors
    │
    ├── Definition
    │   └── Fundamental data structures used by USB devices to communicate capabilities, configurations, and power requirements to the host during enumeration.
    │
    ├── Purpose
    │   ├── Enable the host to load appropriate drivers.
    │   └── Establish effective communication between the device and the host system.
    │
    └── Hierarchical Structure
        ├── Device Descriptor
        ├── Configuration Descriptors
        ├── Interface Descriptors
        ├── Endpoint Descriptors
        ├── String Descriptors
        └── Additional Descriptors (USB 3.x)
            ├── Binary Device Object Store (BOS) Descriptor
            └── SuperSpeed Endpoint Companion Descriptors

Device Descriptors

The device descriptor serves as the cornerstone of USB communication, offering an overview of the device's essential attributes. It includes information such as supported USB versions, vendor and product IDs, and the number of possible configurations.

USB 2.0 Device Descriptor Fields

The USB 2.0 device descriptor comprises the following fields:

• bLength: Size of the descriptor in bytes (typically 18 bytes).
• bDescriptorType: Descriptor type (value 0x01 for device descriptors).
• bcdUSB: USB specification release number (e.g., 0x0200 for USB 2.0).
• bDeviceClass: Class code (assigned by USB-IF).
• bDeviceSubClass: Subclass code (assigned by USB-IF).
• bDeviceProtocol: Protocol code (assigned by USB-IF).
• bMaxPacketSize0: Maximum packet size for endpoint zero (8, 16, 32, or 64 bytes).
• idVendor: Vendor ID assigned by USB-IF.
• idProduct: Product ID assigned by the manufacturer.
• bcdDevice: Device release number in binary-coded decimal.
• iManufacturer: Index of string descriptor describing the manufacturer.
• iProduct: Index of string descriptor describing the product.
• iSerialNumber: Index of string descriptor containing the device's serial number.
• bNumConfigurations: Number of possible configurations.

These fields collectively provide the host with the necessary information to identify and interact with the device appropriately.

USB 3.x Device Descriptor Enhancements

USB 3.x builds upon the USB 2.0 device descriptor by introducing additional fields and modifications to support SuperSpeed functionality:

• bcdUSB: Updated to reflect USB 3.x versions:
  • 0x0300 for USB 3.0
  • 0x0310 for USB 3.1
  • 0x0320 for USB 3.2
• bMaxPacketSize0: Set to 9, indicating a maximum packet size of 512 bytes for endpoint zero in SuperSpeed mode.
• Binary Device Object Store (BOS) Descriptor: Introduced to provide details about the device's extended capabilities, such as SuperSpeed support and power management features.

These enhancements enable the host to recognize and leverage advanced USB 3.x features, including higher data transfer rates and improved power management.

Comparison of USB 2.0 and USB 3.x Device Descriptor Fields

Configuration Descriptors

Configuration descriptors provide detailed information about the device's power requirements and the interfaces available within each configuration. A single USB device can support multiple configurations, each tailored for different operational modes or functionalities.

USB 2.0 Configuration Descriptor Fields

The USB 2.0 configuration descriptor includes the following fields:

• bLength: Size of the descriptor in bytes (typically 9 bytes).
• bDescriptorType: Descriptor type (value 0x02 for configuration descriptors).
• wTotalLength: Total length of data returned for this configuration, including all subordinate descriptors.
• bNumInterfaces: Number of interfaces supported by this configuration.
• bConfigurationValue: Value to use as an argument to the SetConfiguration() request to select this configuration.
• iConfiguration: Index of string descriptor describing this configuration.
• bmAttributes: Configuration characteristics (e.g., self-powered, supports remote wakeup).
• bMaxPower: Maximum power consumption of the device from the bus in 2 mA units (maximum 500 mA for USB 2.0).

USB 3.x Configuration Descriptor Enhancements

USB 3.x introduces several enhancements to the configuration descriptor to accommodate increased power and performance requirements:

• bMaxPower: Expressed in 8 mA units (e.g., a value of 250 indicates 2,000 mA), allowing for higher power delivery.
• bmAttributes: May include additional flags to denote features such as Battery Charging and SuperSpeed support.
• wTotalLength: Adjusted to account for new USB 3.x descriptors, such as BOS and SuperSpeed Endpoint Companion descriptors.

These enhancements ensure that the host can configure the device based on its USB 3.x power and performance characteristics.

USB Interface Descriptors

Interface descriptors define individual interfaces within a configuration. Each interface represents a functional aspect of the device, such as audio input, mass storage, or network connectivity.

USB 2.0 Interface Descriptor Fields

The USB 2.0 interface descriptor includes the following fields:

• bLength: Size of the descriptor in bytes (typically 9 bytes).
• bDescriptorType: Descriptor type (value 0x04 for interface descriptors).
• bInterfaceNumber: Number of the interface.
• bAlternateSetting: Value used to select alternate settings for the interface.
• bNumEndpoints: Number of endpoints used by this interface (excluding endpoint zero).
• bInterfaceClass: Class code (assigned by USB-IF).
• bInterfaceSubClass: Subclass code.
• bInterfaceProtocol: Protocol code.
• iInterface: Index of string descriptor describing this interface.

USB 3.x Interface Descriptor Enhancements

USB 3.x builds upon the interface descriptor with the following enhancements:

• New Class Codes: Support for enhanced functionalities such as Video (UVC 1.5), Audio (UAC 2.0), and Networking (CDC-NCM).
• Additional Endpoints: Support for more endpoints to accommodate higher bandwidth and multiple data streams.
• Alternate Settings: Enhanced use of alternate settings to switch between different operational modes without requiring device re-enumeration.

These enhancements facilitate the integration of advanced functionalities, leveraging USB 3.x's expanded capabilities.

Endpoint Descriptors

Endpoint descriptors provide detailed information about each endpoint used by an interface, including direction, type, and packet size. Endpoints are logical entities within a USB device that facilitate data transfer between the host and the device.

USB 2.0 Endpoint Descriptor Fields

The USB 2.0 endpoint descriptor includes the following fields:

• bLength: Size of the descriptor in bytes (typically 7 bytes).
• bDescriptorType: Descriptor type (value 0x05 for endpoint descriptors).
• bEndpointAddress: Specifies the endpoint number and direction (bit 7 indicates direction: 0 for OUT, 1 for IN).
• bmAttributes: Specifies the transfer type and synchronization type.
• wMaxPacketSize: Maximum packet size this endpoint can handle.
• bInterval: Interval for polling endpoint data transfers.

USB 3.x Endpoint Descriptor Enhancements

USB 3.x introduces key enhancements to endpoint descriptors to support SuperSpeed functionalities:

• wMaxPacketSize: Supports larger packet sizes (up to 1,024 bytes for bulk and control endpoints), increasing data transfer efficiency.
• bmAttributes: Adds new bits to support SuperSpeed-specific features such as burst transactions and streams.
• SuperSpeed Endpoint Companion Descriptor: Provides additional information for SuperSpeed endpoints, including maximum burst size and bytes per interval.
  • bLength: Size of the descriptor in bytes (typically 6 bytes).
  • bDescriptorType: Descriptor type (value 0x30 for companion descriptors).
  • bMaxBurst: Maximum number of packets the endpoint can send or receive as part of a burst.
  • bmAttributes: Describes specific SuperSpeed attributes, such as bulk streams.
  • wBytesPerInterval: Total number of bytes the endpoint can send or receive per service interval (important for isochronous endpoints).

These enhancements enable USB 3.x to handle higher data rates and more complex data transfer scenarios effectively.

Comparison of Endpoint Features

Pipes

A Pipe is a logical connection between the host controller and a device endpoint, facilitating data transfer operations. Pipes are categorized as either message pipes or stream pipes, depending on their function and the nature of the data being transmitted.

USB 2.0 Pipes

Message Pipes: Associated with control endpoints, supporting bidirectional communication and structured data exchange.

Stream Pipes: Linked to bulk, interrupt, or isochronous endpoints, handling unidirectional, unstructured data flow.

Each pipe has attributes such as transfer type (control, bulk, interrupt, or isochronous), data flow direction (IN or OUT), and maximum packet size. Pipes are fundamental for organizing and managing data transfers between the host and the device.

USB 3.x Pipe Enhancements

USB 3.x introduces several refinements to the pipe model to accommodate higher data rates and more complex data transfer requirements:

• Streams within Bulk Pipes: Allows a single bulk endpoint to manage multiple data streams using unique Stream IDs, enhancing throughput for high-demand devices like storage arrays.
• Enhanced Error Handling: Implements improved mechanisms for error detection and recovery, utilizing separate CRCs for headers and data to minimize data loss.
• Optimized Bandwidth Management: The host dynamically allocates bandwidth across pipes, ensuring critical transfers receive priority and optimizing data flow for high-speed devices.
• Burst Transactions: Supports sending multiple packets in rapid succession without waiting for acknowledgments, increasing data transfer efficiency.

These enhancements enable USB 3.x to handle more demanding applications while maintaining robust and reliable data transfers.

Linux Kernel Driver Sample Code

Interfacing with USB devices at the driver level is essential for developers working on Linux systems. Below is an example of a comprehensive Linux kernel driver handling a USB 3.x device, illustrating how to work with descriptors, endpoints, and streams.

#include <linux/module.h>
#include <linux/usb.h>

#define USB_VENDOR_ID  0x1234  // Replace with actual Vendor ID
#define USB_PRODUCT_ID 0x5678  // Replace with actual Product ID

struct usb_device_data {
   struct usb_device *udev;
   struct usb_interface *interface;
   unsigned char bulk_in_endpointAddr;
   unsigned char bulk_out_endpointAddr;
   struct usb_endpoint_descriptor *bulk_in_ep;
   struct usb_endpoint_descriptor *bulk_out_ep;

   // Additional fields for streams can be added here
};

static struct usb_device_id usb_table[] = {
   { USB_DEVICE(USB_VENDOR_ID, USB_PRODUCT_ID) },
   {} /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, usb_table);

/* Probe function called when a matching device is connected */
static int usb_probe(struct usb_interface *interface, const struct usb_device_id *id) {
   struct usb_device_data *dev_data;
   struct usb_host_interface *iface_desc;
   struct usb_endpoint_descriptor *endpoint;
   int i;

   /* Allocate memory for device-specific data */
   dev_data = kzalloc(sizeof(struct usb_device_data), GFP_KERNEL);
   if (!dev_data) {
      printk(KERN_ERR "Cannot allocate memory for device data\n");
      return -ENOMEM;
   }

   /* Get the USB device associated with this interface */
   dev_data->udev = usb_get_dev(interface_to_usbdev(interface));
   dev_data->interface = interface;

   /* Get the current alternate setting for the interface */
   iface_desc = interface->cur_altsetting;
   printk(KERN_INFO "USB interface %d now probed\n", iface_desc->desc.bInterfaceNumber);

   /* Iterate over each endpoint in the interface to find bulk IN and OUT endpoints */
   for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
      endpoint = &iface_desc->endpoint[i].desc;

      if (usb_endpoint_is_bulk_in(endpoint)) {
         dev_data->bulk_in_endpointAddr = endpoint->bEndpointAddress;
         dev_data->bulk_in_ep = endpoint;
         printk(KERN_INFO "Bulk IN endpoint found at 0x%02x\n", endpoint->bEndpointAddress);
      } else if (usb_endpoint_is_bulk_out(endpoint)) {
         dev_data->bulk_out_endpointAddr = endpoint->bEndpointAddress;
         dev_data->bulk_out_ep = endpoint;
         printk(KERN_INFO "Bulk OUT endpoint found at 0x%02x\n", endpoint->bEndpointAddress);
      }
   }

   /* Store the device-specific data in the interface's data pointer */
   usb_set_intfdata(interface, dev_data);
   printk(KERN_INFO "USB 3.x device attached\n");
   return 0;
}

/* Disconnect function called when the device is disconnected */
static void usb_disconnect(struct usb_interface *interface) {
   struct usb_device_data *dev_data;

   /* Retrieve the device-specific data */
   dev_data = usb_get_intfdata(interface);
   usb_set_intfdata(interface, NULL);

   /* Release the USB device and free allocated memory */
   usb_put_dev(dev_data->udev);
   kfree(dev_data);

   printk(KERN_INFO "USB 3.x device disconnected\n");
}

/* Define the USB driver structure */
static struct usb_driver usb_driver = {
   .name = "usb3x_driver",
   .id_table = usb_table,
   .probe = usb_probe,
   .disconnect = usb_disconnect,
};

/* Register the USB driver with the USB subsystem */
module_usb_driver(usb_driver);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Your Name");
MODULE_DESCRIPTION("Comprehensive USB 3.x Device Driver Example");  

• Device Identification: Utilizes the USB_DEVICE macro to specify the Vendor ID and Product ID of the target USB device. Replace 0x1234 and 0x5678 with the actual IDs of the device being targeted.
• Probe Function (usb_probe): Invoked when a device matching the usb_table is connected.
  • Allocates memory for device-specific data.
  • Retrieves and stores endpoint addresses for bulk IN and OUT transfers.
  • Logs information about the connected device and its endpoints.
• Disconnect Function (usb_disconnect): Called when the device is disconnected.
  • Cleans up allocated resources to prevent memory leaks.
  • Logs the disconnection event.
• Driver Registration: Defines the usb_driver structure, associating the driver name, device ID table, and callback functions (probe and disconnect).
• Endpoint Detection: Iterates over the available endpoints in the current interface to identify bulk IN and OUT endpoints.
  • Stores the addresses and descriptors of these endpoints for future data transfers.

This sample code provides a foundation for developing a USB 3.x driver that can handle multiple endpoints and streams, leveraging the advanced capabilities of the USB 3.x protocol. Developers can extend this driver by implementing data transfer operations, handling streams, and integrating additional functionalities as required by the specific USB device.

Binary Device Object Store (BOS) Descriptor

Introduced in USB 3.x, the Binary Device Object Store (BOS) descriptor is a root descriptor that allows a device to inform the host of additional device capabilities beyond the standard descriptors. The BOS descriptor acts as a container for one or more device capability descriptors, providing the host with comprehensive information about the device's advanced features.

BOS Descriptor Structure

The BOS descriptor comprises the following fields:

• bLength: Size of the descriptor in bytes.
• bDescriptorType: Descriptor type (0x0F for BOS descriptors).
• wTotalLength: Total length of the BOS descriptor and all of its sub-descriptors.
• bNumDeviceCaps: Number of separate device capability descriptors contained within the BOS.

Device Capability Descriptors within BOS:

• USB 2.0 Extension Descriptor:
  • bDescriptorType: 0x10
  • bDevCapabilityType: 0x02
  • Fields: Indicates support for features like Link Power Management (LPM).
• SuperSpeed USB Device Capability Descriptor:
  • bDescriptorType: 0x10
  • bDevCapabilityType: 0x03
  • Fields: Describes SuperSpeed capabilities, including supported speeds and attributes.
• Container ID Descriptor:
  • bDescriptorType: 0x10
  • bDevCapabilityType: 0x04
  • Fields: Provides a unique identifier for the device, useful for grouping related functions.
• Platform Capability Descriptor:
  • bDescriptorType: 0x10
  • bDevCapabilityType: 0x05
  • Fields: Used to report platform-specific capabilities, such as those required by operating systems.

Comparison of BOS Descriptor and Device Capability Types

Practical Implementation in Linux Kernel Drivers

Understanding USB descriptors is crucial when developing USB device drivers. In the Linux kernel, the usb_device and usb_interface structures represent the device and its interfaces, respectively. The kernel provides functions to access descriptor information, enabling drivers to interpret and utilize device capabilities effectively.

Reading Device Descriptors

Below is an example of a Linux kernel module that reads and prints the device descriptor information upon device connection:

#include <linux/module.h>
#include <linux/usb.h>

/* Define Vendor ID and Product ID */
#define USB_VENDOR_ID  0x1234  // Replace with actual Vendor ID
#define USB_PRODUCT_ID 0x5678  // Replace with actual Product ID

/* Probe function called when a matching device is connected */
static int usb_probe(struct usb_interface *interface, const struct usb_device_id *id) {
   struct usb_device *dev = interface_to_usbdev(interface);
   struct usb_device_descriptor *desc = &dev->descriptor;

   printk(KERN_INFO "USB Device Descriptor:\n");
   printk(KERN_INFO "  bLength: %u\n", desc->bLength);
   printk(KERN_INFO "  bDescriptorType: %u\n", desc->bDescriptorType);
   printk(KERN_INFO "  bcdUSB: %04x\n", le16_to_cpu(desc->bcdUSB));
   printk(KERN_INFO "  bDeviceClass: %u\n", desc->bDeviceClass);
   printk(KERN_INFO "  bDeviceSubClass: %u\n", desc->bDeviceSubClass);
   printk(KERN_INFO "  bDeviceProtocol: %u\n", desc->bDeviceProtocol);
   printk(KERN_INFO "  bMaxPacketSize0: %u\n", desc->bMaxPacketSize0);
   printk(KERN_INFO "  idVendor: %04x\n", le16_to_cpu(desc->idVendor));
   printk(KERN_INFO "  idProduct: %04x\n", le16_to_cpu(desc->idProduct));
   printk(KERN_INFO "  bcdDevice: %04x\n", le16_to_cpu(desc->bcdDevice));
   printk(KERN_INFO "  iManufacturer: %u\n", desc->iManufacturer);
   printk(KERN_INFO "  iProduct: %u\n", desc->iProduct);
   printk(KERN_INFO "  iSerialNumber: %u\n", desc->iSerialNumber);
   printk(KERN_INFO "  bNumConfigurations: %u\n", desc->bNumConfigurations);

   return 0;
}

/* Disconnect function called when the device is disconnected */
static void usb_disconnect(struct usb_interface *interface) {
   printk(KERN_INFO "USB device disconnected\n");
}

/* Define the USB device ID table */
static struct usb_device_id usb_table[] = {
   { USB_DEVICE(USB_VENDOR_ID, USB_PRODUCT_ID) },
   {} /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, usb_table);

/* Define the USB driver structure */
static struct usb_driver usb_driver = {
   .name = "usb_descriptor_driver",
   .id_table = usb_table,
   .probe = usb_probe,
   .disconnect = usb_disconnect,
};

/* Register the USB driver with the USB subsystem */
module_usb_driver(usb_driver);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Author Name");
MODULE_DESCRIPTION("USB Descriptor Reader Driver");  

• Device Identification: Utilizes the USB_DEVICE macro to specify the Vendor ID and Product ID of the target USB device. Replace 0x1234 and 0x5678 with the actual IDs of the device being targeted.
• Probe Function (usb_probe): Invoked when a device matching the usb_table is connected.
  • Accesses the device descriptor and prints its fields using printk for logging purposes.
• Disconnect Function (usb_disconnect): Called when the device is disconnected.
  • Logs the disconnection event.
• Driver Registration: Defines the usb_driver structure, associating the driver name, device ID table, and callback functions (probe and disconnect).
• Device Descriptor Access: The probe function retrieves the device descriptor and logs its fields, providing insight into the device's characteristics.

This driver provides a basic framework for reading and interpreting USB device descriptors, serving as a foundation for more complex driver development tasks.

Accessing BOS Descriptors

To access the BOS descriptor, the driver can utilize the usb_get_bos_descriptor function. Below is an example of how to retrieve and print BOS descriptor information:

#include <linux/module.h>
#include <linux/usb.h>

/* Define Vendor ID and Product ID */
#define USB_VENDOR_ID  0x1234  // Replace with actual Vendor ID
#define USB_PRODUCT_ID 0x5678  // Replace with actual Product ID

/* Probe function called when a matching device is connected */
static int usb_probe(struct usb_interface *interface, const struct usb_device_id *id) {
   struct usb_device *dev = interface_to_usbdev(interface);
   struct usb_bos_descriptor *bos;
   int retval;

   if (dev->bos) {
      bos = dev->bos;
      printk(KERN_INFO "BOS Descriptor:\n");
      printk(KERN_INFO "  wTotalLength: %u\n", le16_to_cpu(bos->wTotalLength));
      printk(KERN_INFO "  bNumDeviceCaps: %u\n", bos->bNumDeviceCaps);
   } else {
      retval = usb_get_bos_descriptor(dev);
      if (retval) {
         printk(KERN_ERR "Failed to get BOS descriptor: %d\n", retval);
         return retval;
      }

      bos = dev->bos;
      printk(KERN_INFO "BOS Descriptor:\n");
      printk(KERN_INFO "  wTotalLength: %u\n", le16_to_cpu(bos->wTotalLength));
      printk(KERN_INFO "  bNumDeviceCaps: %u\n", bos->bNumDeviceCaps);
   }

   return 0;
}

/* Disconnect function called when the device is disconnected */
static void usb_disconnect(struct usb_interface *interface) {
   printk(KERN_INFO "USB device disconnected\n");
}

/* Define the USB device ID table */
static struct usb_device_id usb_table[] = {
   { USB_DEVICE(USB_VENDOR_ID, USB_PRODUCT_ID) },
   {} /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, usb_table);

/* Define the USB driver structure */
static struct usb_driver usb_driver = {
   .name = "usb_bos_driver",
   .id_table = usb_table,
   .probe = usb_probe,
   .disconnect = usb_disconnect,
};

/* Register the USB driver with the USB subsystem */
module_usb_driver(usb_driver);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Author Name");
MODULE_DESCRIPTION("USB BOS Descriptor Reader Driver");  

• Probe Function (usb_probe):
  • Checks if the BOS descriptor is already present (dev->bos).
  • If present, it prints the BOS descriptor's wTotalLength and bNumDeviceCaps.
  • If not present, it calls usb_get_bos_descriptor to retrieve the BOS descriptor.
  • Handles errors if the BOS descriptor retrieval fails.
• Disconnect Function (usb_disconnect): Called when the device is disconnected.
  • Logs the disconnection event.
• Driver Registration: Similar to the previous example, the driver is registered with the USB subsystem.
• BOS Descriptor Access: The probe function retrieves the BOS descriptor and logs its fields, providing insight into the device's extended capabilities.

This example demonstrates how to access and interpret the BOS descriptor, enabling the driver to recognize and utilize advanced device capabilities introduced in USB 3.x.

Summary of USB Descriptor Enhancements

Table: USB Descriptor Enhancements from USB 2.0 to USB 3.x

Conclusion

USB descriptors are integral to the seamless operation of USB devices, facilitating effective communication between the device and the host by conveying essential information about the device's capabilities and requirements. USB 3.x builds upon the foundational descriptor framework established by USB 2.0, introducing new descriptors and enhancing existing ones to support higher data transfer rates, improved power management, and advanced functionalities such as bulk streams and burst transactions.

The introduction of the BOS descriptor and SuperSpeed Endpoint Companion descriptors in USB 3.x allows for a more detailed and comprehensive description of device capabilities, enabling the host to optimize interactions based on the device's enhanced features. Additionally, the expansion of endpoint descriptors and the refinement of configuration and interface descriptors ensure that USB 3.x devices can meet the demands of modern high-performance applications while maintaining backward compatibility with earlier USB versions.

For developers, engineers, and users, a thorough understanding of USB descriptors is essential for leveraging the full potential of USB technology, ensuring compatibility, optimizing performance, and facilitating the development of robust and efficient USB device drivers.

The Setup Packet

In the USB protocol, control transfers are pivotal for configuring devices, retrieving essential information, and managing device states. These transfers always commence with a Setup Packet, which serves as the foundation for communication between the host and the device. The Setup Packet is especially critical during the enumeration process, where the host identifies and configures the device by handling various standard requests necessary to obtain descriptors and manage device functionalities.

Overview of the Setup Packet

The Setup Packet is an 8-byte data structure that initiates control transfers. It encapsulates all the necessary information for the host to perform standardized operations such as configuring the device, requesting descriptors, and managing device features. Understanding the structure and purpose of the Setup Packet is essential for developers working on USB device drivers and ensuring seamless communication between the host and USB devices.

USB 2.0 Setup Packet

Structure of the Setup Packet

In USB 2.0, the Setup Packet is a fixed 8-byte structure sent by the host to the device’s default control endpoint (Endpoint 0). It comprises the following fields:

Figure 1: USB 2.0 Setup Packet Structure

| bmRequestType | bRequest | wValue | wIndex | wLength |
|      1 byte   |  1 byte  | 2 bytes| 2 bytes|  2 bytes|  

This structure enables the host to issue commands to the device and request information necessary for configuration and operation. The bmRequestType field is particularly important as it determines the direction of data flow, the type of request, and the intended recipient.

Breakdown of bmRequestType Field

The bmRequestType field is an 8-bit value divided into three sections:

• Bit 7: Data Transfer Direction
  • 0: Host-to-device
  • 1: Device-to-host
• Bits 6-5: Type
  • 00: Standard
  • 01: Class
  • 10: Vendor
  • 11: Reserved
• Bits 4-0: Recipient
  • 00000: Device
  • 00001: Interface
  • 00010: Endpoint
  • 00011: Other
  • 00100-11111: Reserved

This breakdown allows for a versatile range of requests, enabling the host to control and query the device effectively.

USB 3.x Setup Packet

USB 3.x retains the same 8-byte Setup Packet structure as USB 2.0 to maintain backward compatibility with earlier devices and hosts. This consistency simplifies the process of interpreting and handling requests across different USB versions.

Although the Setup Packet structure remains unchanged, USB 3.x introduces additional capabilities that enable the handling of new class-specific or vendor-specific requests. These extensions support advanced features such as SuperSpeed data transfers, more efficient power management, and expanded device functionalities. Therefore, while the Setup Packet structure stays constant, its scope is broadened to encompass the enhanced capabilities of USB 3.x.

Table 1: Comparison of USB 2.0 and USB 3.x Setup Packet

    USB 2.0 Setup Packet Structure
    │
    ├── Total Size
    │   └── 8 bytes
    │
    ├── Fields
    │   ├── bmRequestType (1 byte)
    │   ├── bRequest (1 byte)
    │   ├── wValue (2 bytes)
    │   ├── wIndex (2 bytes)
    │   └── wLength (2 bytes)
    │
    └── Visualization
        ├── | bmRequestType | bRequest | wValue | wIndex | wLength |
        └── |      1 byte   |  1 byte  | 2 bytes| 2 bytes|  2 bytes|

    bmRequestType Field Breakdown
    │
    ├── Bit 7: Data Transfer Direction
    │   ├── 0: Host-to-device
    │   └── 1: Device-to-host
    │
    ├── Bits 6-5: Type
    │   ├── 00: Standard
    │   ├── 01: Class
    │   ├── 10: Vendor
    │   └── 11: Reserved
    │
    └── Bits 4-0: Recipient
        ├── 00000: Device
        ├── 00001: Interface
        ├── 00010: Endpoint
        ├── 00011: Other
        └── 00100-11111: Reserved

    USB 3.x Setup Packet Structure
    │
    ├── Total Size
    │   └── 8 bytes (Same as USB 2.0)
    │
    ├── Fields
    │   ├── bmRequestType (1 byte)
    │   ├── bRequest (1 byte)
    │   ├── wValue (2 bytes)
    │   ├── wIndex (2 bytes)
    │   └── wLength (2 bytes)
    │
    ├── Consistency
    │   └── Structure remains unchanged from USB 2.0 for backward compatibility
    │
    └── Enhancements
        ├── Supports new class-specific or vendor-specific requests
        ├── Enables handling of SuperSpeed data transfers
        ├── Facilitates more efficient power management
        └── Accommodates expanded device functionalities 

Standard Requests

Standard requests are predefined commands in the USB specification used by the host to control devices, especially during setup and regular operation. They are essential for device configuration, status retrieval, and managing features across all USB devices.

USB 2.0 Standard Requests

In USB 2.0, standard requests include:

• GET_STATUS: Retrieves the current status of the device, interface, or endpoint.
• CLEAR_FEATURE: Disables a specific feature on the device, interface, or endpoint.
• SET_FEATURE: Enables a specific feature, such as remote wakeup or endpoint halt.
• SET_ADDRESS: Assigns a unique address to the device during the enumeration process.
• GET_DESCRIPTOR: Requests a specific descriptor (e.g., Device, Configuration, String, Interface, or Endpoint).
• SET_DESCRIPTOR: Optionally allows the host to update a descriptor on the device (rarely used).
• GET_CONFIGURATION: Retrieves the current configuration value of the device.
• SET_CONFIGURATION: Sets the device’s configuration, transitioning it to a configured state.
• GET_INTERFACE: Retrieves the current alternate setting for a specified interface.
• SET_INTERFACE: Selects an alternate setting for an interface.
• SYNCH_FRAME: Synchronizes data transfers for isochronous endpoints.

USB 3.x Standard Requests

USB 3.x continues to support all standard requests from USB 2.0, ensuring interoperability and backward compatibility. However, it introduces extensions to support its advanced features:

• GET_STATUS: May return additional status flags for USB 3.x-specific features such as Link State or U1/U2 power states.
• GET_DESCRIPTOR: Includes new descriptors such as the Binary Device Object Store (BOS) and Device Capability descriptors.
• SET_FEATURE and CLEAR_FEATURE: Handle USB 3.x-specific functions, including Link Power Management (LPM) and enhanced power-saving modes.

Table 2: Extensions in USB 3.x Standard Requests

Standard Device Requests

USB 2.0 Standard Device Requests

The following standard device requests are available in USB 2.0:

• GET_STATUS
• CLEAR_FEATURE
• SET_FEATURE
• SET_ADDRESS
• GET_DESCRIPTOR
• SET_DESCRIPTOR
• GET_CONFIGURATION
• SET_CONFIGURATION

USB 3.x Standard Device Requests

USB 3.x retains these requests but extends their functionality:

• GET_STATUS: May include additional bits for features such as function suspend or U1/U2 power state support.
• GET_DESCRIPTOR: Can request USB 3.x-specific descriptors, including the BOS and Device Capability descriptors.
• SET_FEATURE and CLEAR_FEATURE: Manage USB 3.x-specific features, such as Link Power Management and function suspension.

Standard Interface Requests

USB 2.0 Standard Interface Requests

The standard interface requests in USB 2.0 include:

• GET_STATUS
• CLEAR_FEATURE
• SET_FEATURE
• GET_INTERFACE
• SET_INTERFACE

USB 3.x Standard Interface Requests

USB 3.x supports these interface requests and introduces additional capabilities:

• Power Management: Interface-specific power controls for better power management.
• Alternate Settings: Enhanced use of alternate settings utilizing USB 3.x features like increased bandwidth.

Standard Endpoint Requests

USB 2.0 Standard Endpoint Requests

The standard endpoint requests in USB 2.0 include:

• GET_STATUS
• CLEAR_FEATURE
• SET_FEATURE

USB 3.x Standard Endpoint Requests

USB 3.x enhances these requests by adding support for SuperSpeed features:

• Extended GET_STATUS: Provides additional status information, such as endpoint-specific error conditions.
• Bulk Stream Management: Controls for managing multiple streams in bulk endpoints.
• Error Handling Enhancements: Improved mechanisms for detecting and recovering from errors.

Linux Kernel Driver Implementation

Understanding and handling Setup Packets is essential for developing USB device drivers. The Linux kernel provides mechanisms to process control requests sent to the device.

Example: Handling Control Requests in a USB Driver

Below is an example of a Linux kernel module that handles control requests directed to a USB device:

#include <linux/module.h>
#include <linux/usb/composite.h>

/* Function to handle setup requests */
static int my_usb_function_setup(struct usb_function *f, const struct usb_ctrlrequest *ctrl) {
   struct usb_composite_dev *cdev = f->config->cdev;
   u16 wValue = le16_to_cpu(ctrl->wValue);
   u16 wIndex = le16_to_cpu(ctrl->wIndex);
   u16 wLength = le16_to_cpu(ctrl->wLength);
   int ret = -EOPNOTSUPP;

   switch (ctrl->bRequest) {
      case USB_REQ_GET_DESCRIPTOR:
         if ((ctrl->bmRequestType & USB_DIR_IN) && (wValue >> 8) == USB_DT_DEVICE) {
            /* Handle GET_DESCRIPTOR request */
            ret = usb_ep0_queue(cdev->gadget, cdev->req, GFP_ATOMIC);
         }
         break;
      case USB_REQ_SET_CONFIGURATION:
         if (!(ctrl->bmRequestType & USB_DIR_IN)) {
            /* Handle SET_CONFIGURATION request */
            ret = 0;
         }
         break;
      default:
         /* Stall for unsupported requests */
         ret = -EOPNOTSUPP;
   }

   return ret;
}

/* Define the USB function structure */
static struct usb_function my_usb_function = {
   .name       = "my_usb_function",
   .setup      = my_usb_function_setup,
   /* Other function callbacks can be added here */
};

/* Initialize the USB gadget */
static int __init my_usb_init(void){
   /* USB gadget initialization code goes here */
   return 0;
}

/* Cleanup the USB gadget */
static void __exit my_usb_exit(void) {
   /* Cleanup code goes here */
}

module_init(my_usb_init);
module_exit(my_usb_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Author Name");
MODULE_DESCRIPTION("USB Setup Packet Handling Example");  

• usb_function_setup: This function handles setup requests directed to the USB function. It parses the usb_ctrlrequest structure, interprets the request, and takes appropriate actions based on the request type.
  • GET_DESCRIPTOR: Checks if the request is for a device descriptor and queues a response if appropriate.
  • SET_CONFIGURATION: Handles configuration requests by setting the device's configuration.
  • Default Case: Returns an error (-EOPNOTSUPP) for unsupported requests, causing the device to stall.
• usb_function Structure: Defines the USB function, associating the setup callback with the my_usb_function_setup function.
• Module Initialization and Cleanup: Registers and deregisters the USB function with the USB subsystem.

This driver provides a basic framework for reading and interpreting USB device descriptors, serving as a foundation for more complex driver development tasks.

Accessing Setup Packet Fields

Within the my_usb_function_setup function, the fields of the Setup Packet can be accessed using the usb_ctrlrequest structure:

• ctrl->bmRequestType: Accesses the bmRequestType field.
• ctrl->bRequest: Accesses the bRequest field.
• le16_to_cpu(ctrl->wValue): Converts wValue from little-endian to CPU byte order.
• le16_to_cpu(ctrl->wIndex): Converts wIndex from little-endian to CPU byte order.
• le16_to_cpu(ctrl->wLength):: Converts wLength from little-endian to CPU byte order.

This allows the driver to interpret and respond to various control requests effectively.

Summary of Standard Requests

Table 3: Standard Device Requests Overview

Note: The values for bmRequestType indicate the direction (bit 7), type (bits 6-5), and recipient (bits 4-0).

Conclusion

The Setup Packet and standard requests are fundamental to the USB protocol, governing device enumeration, configuration, and control. USB 3.x builds upon the established framework of USB 2.0 by retaining the Setup Packet structure while extending the capabilities of standard requests to support advanced features such as SuperSpeed data transfers, improved power management, and bulk stream handling.

These enhancements enable USB 3.x devices to offer higher performance, greater flexibility, and more efficient power usage while ensuring backward compatibility with earlier USB versions. Understanding the Setup Packet and standard requests is essential for developers working with USB devices, as they form the basis for device communication and driver development.

Glossary

• bmRequestType (Bit Mask Request Type): An 8-bit field in the Setup Packet that specifies the characteristics of the request, including direction, type, and recipient.
• BOS (Binary Device Object Store): A descriptor in USB 3.x that contains information about additional device capabilities.
• Bulk Transfer: A type of USB transfer used for large, non-time-sensitive data transfers.
• CRC (Cyclic Redundancy Check): An error-detecting code used to detect accidental changes to raw data.
• Control Transfer: A type of USB transfer used for configuration, command, and status operations.
• DMA (Direct Memory Access): A feature that allows hardware subsystems to access main system memory independently of the CPU.
• Descriptor: A data structure that provides information about the device’s capabilities, configurations, interfaces, and endpoints.
• Endpoint: A logical data source or sink in a USB device, identified by a unique endpoint number.
• Endpoint 0: The default control endpoint used for enumeration and standard control requests.
• Enumeration Process: The process by which the host identifies and configures a USB device upon connection.
• Gbps (Gigabits per second): A unit of data transfer rate equal to one billion bits per second.
• IN Endpoint: Data flows from the device to the host.
• Interrupt Transfer: A type of USB transfer used for small, time-sensitive data transfers.
• Isochronous Transfer: A type of USB transfer used for real-time data streams where timing is critical.
• ITP (Isochronous Timestamp Packet): Packets that provide precise timing for isochronous transfers in USB 3.x.
• Latency Tolerance Messaging (LTM): A mechanism that allows devices to communicate their tolerance to latency, aiding in power management.
• LMP (Link Management Packet): Packets used in USB 3.x for managing link-level operations.
• LTSSM (Link Training and Status State Machine): A protocol used in USB 3.x for managing link initialization and speed negotiation.
• Mbps (Megabits per second): A unit of data transfer rate equal to one million bits per second.
• Microframe: A subdivision of a USB frame in USB 3.x, lasting 125 microseconds.
• NRZI (Non-Return to Zero Inverted): A method of mapping a binary signal to a physical signal for transmission.
• OUT Endpoint: Data flows from the host to the device.
• Setup Packet: An 8-byte data structure that initiates control transfers between the host and USB device.
• SOF (Start-of-Frame): A packet sent by the host at the beginning of each USB frame to synchronize data transfers.
• Stream ID: An identifier used in USB 3.x to manage multiple data streams within a single bulk endpoint.
• Streams: Multiple concurrent data flows within a single bulk endpoint, identified by unique Stream IDs.
• SuperSpeed Endpoint Companion Descriptor: Provides additional information for SuperSpeed endpoints in USB 3.x.
• TP (Transaction Packet): Packets in USB 3.x that facilitate data transfers.
• U1, U2, U3 States: Power states introduced in USB 3.x to manage device power consumption more effectively.
• UASP (USB Attached SCSI Protocol): A protocol that enhances USB storage performance by enabling simultaneous command processing.
• URB (USB Request Block): A structure used by the Linux USB subsystem to represent USB requests.
• USB 3.x: A series of USB specifications that offer higher data transfer rates, improved power management, and enhanced functionalities compared to USB 2.0.
• USB Implementers Forum (USB-IF): The organization responsible for developing and maintaining USB specifications.
• xHCI (eXtensible Host Controller Interface): A standard for USB host controller drivers.
• wIndex: A 16-bit field typically used to specify an interface or endpoint number.
• wLength: A 16-bit field that specifies the number of bytes to transfer during the data stage of the control transfer.
• wRequest (Request): An 8-bit field that identifies the specific request being made.
• wValue: A 16-bit field that provides additional information about the request, such as descriptor type and index.

References

• Beyond Logic. (n.d.). USB in a nutshell: Beyond logic USB guide. Retrieved from https://www.beyondlogic.org/usbnutshell/usb1.shtml
• Linux Kernel Documentation. (n.d.). Linux kernel documentation for USB: USB API. Retrieved from https://www.kernel.org/doc/html/latest/driver-api/usb/index.html
• Linux Kernel Documentation. (n.d.). Linux kernel USB gadget API. Retrieved from https://www.kernel.org/doc/html/latest/driver-api/usb/gadget.html
• Microsoft. (n.d.). USB documentation. Retrieved from https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/
• USB-IF. (n.d.). Universal Serial Bus 3.2 specification. Retrieved from https://www.usb.org/documents
• USB-IF. (n.d.). USB device class codes. Retrieved from https://www.usb.org/defined-class-codes
• USB-IF. (n.d.). USB power delivery specifications. Retrieved from https://www.usb.org/usb-charger-pd
• USB Made Simple. (n.d.). USB control transfer details. Retrieved from https://www.usbmadesimple.co.uk/ums_5.htm