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: Port usb_dc_smartbond to UDC API #74662
    • 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
    • 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)
  • 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 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 EEM, RNDIS should be considered to be replaced by CDC NCM

• 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

Timeline for transitioning to USB device "next" support

• Port remaining drivers to "next" (stragglers may be left behind if no maintainers step up)
• Complete UHC USBIP implementation
• Remove experimental label from device next
• Remove samples that work only with the legacy stack
• Evaluate the test coverage of the next stack
• Deprecate the current USB between 3.7.0 and 4.0.0
• Make device next the default in 4.0.0
• Remove the current USB stack in 4.2.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.

[jgl-meta]

@jfischer-no What is the status of this? Is this on track to be finished before release 3.4?

[jfischer-no]

@jfischer-no What is the status of this? Is this on track to be finished before release 3.4?

Obviously only what is explicitly marked for the v3.4.0 #42066 (comment)

[tmon-nordic]

Porting all classes is marked for 3.4.0, but considering feature freeze date (2023/05/26) is just in few weeks it might not be possible.

[faloj]

Some components support both device and host mode. This partition between uhc and udc may lead to code duplication for those components. What do you think of a third folder along with "uhc" and "udc" to hold shuch code ? (something like "common" or "core" maybe ?)

[dleach02]

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

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?

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

[dleach02]

Okay @jfischer-no. My primary interest is USB host mode. Trying to figure out the pathway to getting this up and running on one of our platforms, maybe the RT5xxx.

[hswang914]

Hi, I saw the phrase "Introduction of USB device controller API." Does it mean that there is a resource available for me to study and understand the new USB device driver, such as a basic usage guide or a comparison with the old one? Thanks!

[MarkWangChinese]

Hi @jfischer-no I am working on this task.

• usb_dc_mcux -> udc_mcux

[MarkWangChinese]

Hi @jfischer-no I (from NXP) want to contribute the USB host stack because NXP has interest for Zephyr USB host. What can I help for developing the Zephyr USB host stack? If you already have the overall thought about the host stack, I can help to do the implementation. In short, I want to contribute USB Host stack and accelerate its implementation. Thanks. Our team is the owner of the NXP SDK USB stack, so we have a lot of experience on USB2.0.

[jfischer-no]

Hi @jfischer-no I (from NXP) want to contribute the USB host stack because NXP has interest for Zephyr USB host. What can I help for developing the Zephyr USB host stack? If you already have the overall thought about the host stack, I can help to do the implementation. In short, I want to contribute USB Host stack and accelerate its implementation. Thanks. Our team is the owner of the NXP SDK USB stack, so we have a lot of experience on USB2.0.

Nice ❤️ . However, here is no independent USB host stack, it is part of the USB support, see my comment #42066 (comment). Thanks for the upcoming contribution to Zephyr's USB support, especially on ASAP porting NXP USB device driver to new UDC API where each NXP controller type has its own driver and not as clumsy as the existing usb_dc_mcux.

[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?

[josuah]

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

If it is about help for troubleshooting, feel free to join the Discord server, the Mailing lists, the Discussions section, or open a new issue if you encountered what appears to be a bug.
[EDIT: what I mean is I am up to discuss about USB/IP support (or did you mean CDC ECM?) but wish to avoid bloating this thread]

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