Planned USB device/host support rework/enhancements

[jfischer-no]

This is a meta issue for maintainers and developers of relevant subsystems to track progress on new USB support.

Introduction

Currently we have only USB device support in Zephyr OS. Existing USB device support has many disadvantages and issues, like missing support for multiple driver instances, no endpoint (request) buffers management, missing class instances management and possibility to configure/enable class instance at runtime, not a good notification channel to the user/application, messy callback architecture, no API to set/reconfigure idVendor/iSerialNumber/bcdDevice at runtime, confusing usb_dc_ep_read()/usb_dc_ep_write() API, and more.

There is no USB host support in the project. It is asked again and again for it and there was effort like #30361, but that is far from suitable. USB device stack would also benefit from the host support and allow self-contained tests with emulated device and host controllers, and better support for USBIP.

Since many problems with the USB device support are due to the way it is designed (imported in Zephyr OS), we would like to redesign USB device support. That means USB device controller driver API and USB device stack will be rewritten in parallel and independent to existing implementation. Due to the need for testing/validation, USB host controller driver API and some parts of higher level will also be implemented.

Rough plan

• New USB device support (PR usb: add new (experimental) USB device support #38679)

  • Introduction of USB device controller API
  • virtual device controller driver implementation
  • Porting more device controller drivers to new API (There is UDC driver skeleton PR drivers: udc: add USB device controller driver skeleton  #57615, please use it as a starting point for a new UDC driver)
    • usb_dc_nrfx -> udc_nrf
    • usb_dc_kinetis -> udc_kinetis
    • usb_dc_it82xx2 -> udc_it82xx2
    • usb_dc_numaker -> udc_numaker: drivers: usb: Port usb_dc_numaker to UDC API #74660
    • usb_dc_smartbond -> udc_smartbond: drivers: usb: udc: add Smartbond UDC driver #79184
    • usb_dc_dw -> udc_dwc2
    • usb_dc_stm32 -> udc_stm32
    • usb_dc_mcux -> udc_mcux
    • usb_dc_rpi_pico -> udc_rpi_pico: drivers: usb: Port usb_dc_rpi_pico to UDC API #74666
    • usb_dc_sam_usbhs -> udc_sam_usbhs: drivers: usb: Port usb_dc_sam_usbhs to UDC API #74663
    • usb_dc_sam0 -> udc_sam0: drivers: usb: Port usb_dc_sam0 to UDC API #74667 (@jfischer-no WIP)
    • usb_dc_sam_usbc -> udc_sam_usbc: drivers: usb: Port usb_dc_sam_usbc to UDC API #74665
    • usb_dc_native_posix -> 🗑️ driver will be dropped (see USBIP support based on host support)
  • New USB device stack implementation
  • New USB notification mechanism (USB: notifications overhaul #51034, PR usb: device_next: implementation of USB device support notification #68256)
  • MS Descriptor support (PR usb: device_next: support BOS descriptor with vendor request code #76326)
  • Porting USB device classes to new USB device support
    • CDC ACM class support (PR usb: add new (experimental) USB device support #38679)
    • Audio class support (WIP @tmon-nordic Initial PR dt-bindings: usb: initial USB Audio Class 2 support #65972, usb: device_next: new USB Audio 2 implementation #67614)
    • HID class support (WIP @jfischer-no PR usb: device_next: add initial HID device support #65801)
    • USB DFU class support (Cannot be ported due to license, will be a new implementation (usb: device_next: implement USB DFU class for the new device support #79794))
    • USB MSC class support (PR usb: device_next: new USB Mass Storage implementation #54776)
    • Bluetooth HCI interface drivers (usb: device_next: add BT HCI USB transport layer  #53870)
    • CDC ECM (usb: device_next: add CDC ECM class implementation  #54448)
    • CDC NCM (usb: device_next: USB CDC NCM class implementation #79508)

• USB host support (PR usb: add USB host controller API, support for virtual controller, and experimental host support #50985)

  • Introduction of USB host controller API
  • MAX3421E driver implementation
  • virtual host controller driver implementation
  • Add more host controller drivers to new API (planned: dwc2)
  • Introduction of USB host stack implementation (WIP @jfischer-no)
  • UHC USBIP implementation (usb: usbip: add initial support for USBIP server #74141 WIP @jfischer-no)
  • Implementation of USB classes support
    • CDC ACM class support
    • Audio class support
    • HID class support
    • USB DFU class support
    • USB MSC class support
    • Bluetooth HCI interface drivers

Choice of support of the legacy stack

a) Remove the legacy stack entirely after 4.0.0 (hard switch)
b) Keep the stack, but remove tests and samples
c) Keep the stack, keep tests and some samples, but deprecated and not building in CI
d) Keep the stack, keep tests and some samples, but deprecated. Have a special build in CI that does not fail with deprecation

Agreement to go with d), with samples for the legacy stack placed under a legacy/ folder.

Timeline for transitioning to USB device "next" support

• Remove experimental label from device next: usb: device_next: Remove experimental status #79921
• Port remaining drivers to "next" (stragglers may be left behind if no maintainers step up)
• Complete UHC USBIP implementation
• MS Descriptor support
• USB DFU Class
• Legacy-only samples: add support for new stack or move them to a legacy folder
• Default to device_next in samples that work with both
• Evaluate the test coverage of the next stack
• Evaluate the impact of usb: device: next: increased RAM and flash footprint with "device_next" USB stack #83309
• Move the legacy samples under a folder (samples: usb: move legacy USB code to legacy directory and cleanup samples #80985)
• Set up the CI build of samples and tests using the legacy stack with disabled deprecation (requires Provide consistent deprecated behavior and reduce downstream breakage #49708)
• Deprecate the current USB stack between 4.0.0 and 4.1.0
• Make device next the default in 4.1.0
• Remove the current USB stack in 4.3.0

Main "switch":

zephyr/subsys/usb/device_next/Kconfig

Line 5 in 745ace8

menuconfig USB_DEVICE_STACK_NEXT

[koffes]

This is good news. I would like to link to this issue: #26857, and hopefully the high CPU load will be resolved here as well. FYI @alexsven
Also, any plans for async USB audio support?

[qipengzha]

For driver support, will you plan to enable Synopsys DWC USB2.0 OTG controller ? thx

[dleach02]

Do we need a separate tracking ticket for USB Host?

[jfischer-no]

Do we need a separate tracking ticket for USB Host?

No, not at this time. My plan is that host controller driver API immediately follows device controller API (+ device stack), details of host support come afterwards.

[dleach02]

@jfischer-no Is there any of this that can be parallelized if additional resources are made available?

Also, what forum are we to use to have some open discussions about the API changes and requirements?

[jfischer-no]

@jfischer-no Is there any of this that can be parallelized if additional resources are made available?

Not yet.

[jfischer-no]

Plan updated.

[lenghonglin]

hello, i use usb audio these , and the usb audio leak some feature unit, like volume . It there have some plan to do this?

[fabiobaltieri]

@jfischer-no do you think we should push this to the v3.3 milestone? (it's currently tagged for v3.2)

[troica65]

Hi, any estimate for when host support will be available ?

[hongshui3000]

+1

[jfischer-no]

hello, i use usb audio these , and the usb audio leak some feature unit, like volume . It there have some plan to do this?

Yes, but it is not directly relevant to this topic.

Hi, any estimate for when host support will be available ?

ASAP!

[jfischer-no]

Virtual controller and host support has been separated from #38679 and moved to #50985. Updated the list of drivers and class implementations to be ported.

[raveslave]

@MaureenHelm any interest from NXP to support the mcux usb host (and device) drivers for LPC and i.MXRT in zephyr?

[koffes]

Wrt. Audio. Could someone please enlighten me on the status/plans for async USB support? We need the SoC to poll the PC host for new Audio data.

[jfischer-no]

Wrt. Audio. Could someone please enlighten me on the status/plans for async USB support? We need the SoC to poll the PC host for new Audio data.

I commented to a similar question above. It would be nice if you open a well-described enhancement issue or discussion, but it does not belong here!

@MaureenHelm any interest from NXP to support the mcux usb host (and device) drivers for LPC and i.MXRT in zephyr?

It appeared to me in a dream that progress on NXP USB controller support is inversely proportional to how often you ask the same question in different topics.

[MaureenHelm]

@MaureenHelm any interest from NXP to support the mcux usb host (and device) drivers for LPC and i.MXRT in zephyr?

I don't work at NXP anymore. Please contact @dleach02 for NXP-related questions.

[dleach02]

@jfischer-no,

Yes, there is interest from NXP and USB host support.
@jfischer-no, what is the right forum to discuss this? Is it here in this ticket?

@dleach02 Please not here, maybe discussions, but once you have started implementing a UHC driver, please add a note to the description or ask me for an update. However, the priority is and should be to get the new device support to a state where we can start calling the current stack legacy. This means there should be alternatives to all the class implementations we have for the current stack, and a few more drivers.

If I look at the list of items for moving over to the new UDC it looks like mostly porting vendor's USB drivers. I think it makes sense to work in parallel on the host layer instead of serializing this effort. If we are blocked by other vendors conversions we may never get to the host work.

We have needs for host support and the resources available to assist in this effort. Just need some guidance on how you want this done.

[josuah]

I got started with UVC.

For now a continuation of the Video driver interface. #72311

The recent UAC2 seems like a good reference for how to implement it. #70029

[ddavidebor]

is the USB-ip supposed to work with native_sim and the device_next stack?

[henrikbrixandersen]

is the USB-ip supposed to work with native_sim and the device_next stack?

Please see #74141

[tannewt]

Why not use TinyUSB instead of making a new stack? It has device and host support already. It has an OS abstraction layer as well. License is MIT.

Both Espressif and Raspberry Pi use it in their SDKs already.

[josuah]

Why not use TinyUSB instead of making a new stack? It has device and host support already. It has an OS abstraction layer as well. License is MIT.

Wonderful work from Ha Thach! Very simple callback-based API that is convenient to debug... Just follow the calls.
Many classes implemented as well. UVC contributed by someone working at Toshiba even!

I am not from Nordic and do not know the original rationale for a from-scratch implementation for Zephyr, but here are some clues that I am trying to guess:

• allow to have a Zephyr driver API without too much abstraction in-between
• leverage existing Zephyr code snippets (i.e. net_buf, events, work queues, threads...)
• leverage existing Zephyr subsystems (i.e. CDC_NCM implementation is mostly glue)
• at this stage, the existing amount of effort already put into it

Just my wild guesses!

Related

• zephyr port hathach/tinyusb#458

[josuah]

Some progress on UVC: #63421 (comment)

[mmahadevan108]

@jfischer-no , we have moved this to be in the 4.0 Release Plan for the conversion of the USB Device.
Do you want to create a separate issue for the remaining tasks related to USB Host?

[mmahadevan108]

@jfischer-no, can you please share some insight on what the plans are for the remaining tasks related to USB Host. Should we create a separate RFC for this so we can track it for future Zephyr releases.

[jfischer-no]

@jfischer-no, can you please share some insight on what the plans are for the remaining tasks related to USB Host. Should we create a separate RFC for this so we can track it for future Zephyr releases.

No.

As mentioned the beginning:
"This is a meta issue for maintainers and developers of relevant subsystems to track progress on new USB support."
This is not a release specific issue. There are parts of device support that depend on parts in host support. Please keep this topic free of irrelevant discussions, (also free of irrelevant concerns and wishes).

[mmahadevan108]

@jfischer-no, we have moved this meta issue to be fixed in 4.0. How should we track the items that are not addressed in 4.0 release?