Repository navigation
Planned USB host support work #95661
Description
Important
This is a meta issue for maintainers and developers of relevant subsystems to track progress on USB support. Please do not ask general questions or make comments about USB support here. Please do not start a metaphysical discussion about the reasons for the existence of the host stack.
Problem Description
Follow up on #42066, focusing on host support. For the USB device support see #95649.
Support for USB hosts in Zephyr is ramping up, but it will take some time to reach the same level as support for devices. It is not ready for productive use. We cannot say when it will be ready, nor can we specify an exact date for the implementation of feature XYZ. Please note that all APIs are experimental and may change at any time. Bear this in mind when working on new drivers or class drivers.
There are basic tests for both USB device and host support, which run in CI on the PR basis. We also have experimental USB/IP support, which is primarily used for exporting USB devices. There should not be any regressions, as these would also affect users of the USB device stack.
Drivers
If you start working on the new driver, please use MAX3421E or virtual driver as a reference point and template for the new driver. Please follow the coding style guidelines and keep the style consistent with the USB drivers/subsystem code. Please note that clangformat does not format code according to the coding style guidelines, so you will need to fix it afterwards.
- New driver for Synopsys DWC2 DWC2 USB Host controller (UHC) #102931
- MCUX add hub topology fields and getters drivers: usb: uhc: add hub topology fields and getters #102838
- drivers: usb: add generic ohci host driver #107065
Stack
The stack is in an experimental, early-development state. Ongoing work:
- Class (Driver) API (@josuah USB Host: integrate class API [2: helpers] #94590)
- Support for multiple controllers (@josuah USB class: support multiple USB host controllers #100703)
- usb: host: refine connect/disconnect handling #103580
USB Class/Function driver
There is no support for any classes or functions in the Zephyr tree. However, there is ongoing work and draft PRs on some functions. There are also no examples available yet that can be used as templates. The plan is to first add a basic test function as a counterpart to the device's loopback function, which could then be used for testing and as a template for the new class driver implementations. If you want to start work on the new class/function driver, this is the right issue to discuss. Please follow the coding style guidelines and keep the style consistent with the USB drivers/subsystem code. Please note that clangformat does not format code according to the coding style guidelines, so you will need to fix it afterwards.
- Implementation of USB classes support
- testusb function support as loopback counterpart
- CDC ACM Class support (usb: host: add CDC ACM class driver #111282 @jfischer-no)
- USB Video class driver (WIP Planned USB host video implementation #93517 @AidenHu @josuah)
- Audio Class 2 driver (WIP usb host uac2 enablement #110052 @AidenHu)
- HID class support (WIP usb: host: hid_boot: Implement USB host HID Boot class #119770 @fkokosinski)
- USB DFU class support (WIP usb: host: Add DFU host driver and support for DFU/DRURT class #119550 @thenguyenyf)
- USB MSC class driver (Usb host msc enablement #116049 @AidenHu)
- Bluetooth HCI function driver
- CDC ECM function driver (WIP subsys: usb: host: Add USB Host CDC ECM Class Support for Ethernet #99097 @santhosh-c-c subsys: usb: host: support for usb host cdc-ecm class #100289 @MarkWangChinese @D-Veda)
- CDC NCM function driver (WIP @santhosh-c-c)
- USB Serial (custom, WIP subsys: usb: host: Add USB Host Vendor specific serial class support #99173 @Girinandha-M)
- HUB function support (WIP usb: host: class: support for usb host hub class #99735 @AidenHu @MarkWangChinese)
- USB Billboard support (WIP usb: host: Add USB host Billboard support #119506 @thenguyenyf)
Activity
AidenHu commentedon Oct 10, 2025
Hi @jfischer-no,
As you know, we have already created the draft PR for the Host Video class. We are now planning to implement the USB Host MSC class, which will be integrated with the disk subsystem. I would like to confirm whether this implementation is within the scope of our current tasks, and whether we can proceed with it. Additionally, do you have any suggestions or recommendations regarding this approach?
AidenHu commentedon Oct 14, 2025
Hi @jfischer-no
I’ve started working on the Host MSC class. If no one else is currently working on it, I’ll go ahead and add my name to to the item listed above.
jfischer-no commentedon Oct 14, 2025
@AidenHu Yes, it would be nice to have an MSC driver on the host side. But perhaps there has been some misunderstanding. Your UVC host PR is still a draft, and I think your code is far from being accepted. I suggest you start by reading https://docs.kernel.org/process/coding-style.html and https://docs.zephyrproject.org/latest/contribute/style/code.html. Then, take a close look at the USB code in the project. Read #95661 (comment) again, and consider making a few small contributions. Then, a more complex task like UVC host driver might be more appropriate. Please understand that a commit with over +6000 lines, where almost every line needs a review comment, is a DoS on the reviewer. Thanks.
MarkWangChinese commentedon Nov 5, 2025
Hi @jfischer-no NXP has customer requirement for the USB Host ECM and USB Host HUB, so we have started to implement them. If it is OK for you, I will edit the corresponding feature items as WIP. Please provide your comments, thanks.
josuah commentedon Nov 5, 2025
Hello @MarkWangChinese,
While this PR below is not merged yet, I hope this helps you get a more stable basis for all the classes you wish to merge to Zephyr:
This way, even if the PR above needs to be modified, all of your contributed classes will have a same API, that is hopefully going to be very close to what is merged after the end of the review.
Furthermore, to facilitate the integration, it is possible to provide unit tests that use the device implementation and the host implementation of a class and test them against each other on CI. This PR shows an example of this:
This commit is providing the basic tests:
This is not an official recommendation from the USB maintainer, but hope this facilitates progress on both end.
MarkWangChinese commentedon Nov 7, 2025
Thanks @josuah Our side will check your class implementation and tests, and try to implement other classes in the same way. If any comments, I will add in the pr.
josuah commentedon Nov 16, 2025
Updated first message with the announcement from above:
Updated first message with two recent WIP pull requests:
@MarkWangChinese it seems like there are two parallel efforts for USB ECM?
santhosh-c-c commentedon Nov 19, 2025
Hello @jfischer-no , @josuah
I have started working on the CDC NCM support, I request you to update the corresponding items in the planned USBH work list to WIP. So that duplicated efforts can be avoided.
josuah commentedon Nov 21, 2025
I added your name for CDC-NCM in the list! Feel free to open a draft pull request as early as needed as support for discussion if that help.
If you wish an "aggregation" pull request, there is this which contains your fixup commit (which I have moved from
API2toAPI4), and others that are introducing some not-yet-merged/reviewed features.8 remaining items
mgalda82 commentedon Mar 30, 2026
Hello we (NXP) have a customer waiting for the USB Host Audio implementation, but to be honest I am not sure if there is any activity planned already or some job done. Could you please keep me updated soon about this. Because we need to inform the customer and accept the adequate actions.
Thanks, Michael
josuah commentedon Mar 30, 2026
@santhosh-c-c:
When there are two similar PRs for the same feature, it might allow things to be merged faster to merge them in one. One way to do it is to look at all the modifications you did on top of NXP's PR and suggest them to NXP: start reviewing NXP PR.
If @D-Veda is not having the bandwidth to integrate the changes, this means that you can integrate what was done on NXP PR and your PR becomes the active one.
Hopefully this solves the "two PR for same feature" problem, and keeps both PRs moving forward.
It can also happen the other way around ofc...
MarkWangChinese commentedon Apr 1, 2026
The NXP PR already integrates the features of @santhosh-c-c's pr and has more features. @santhosh-c-c is added as co-author and Linumiz copyright is added too in NXP pr. May we move the review forward based on the NXP PR? BTW, @D-Veda has bandwidth to work on the pr's comments.
MarkWangChinese commentedon Apr 10, 2026
@AidenHu start to work on enabling the host audio2.0, so I add @AidenHu name to the task item. @jfischer-no
santhosh-c-c commentedon Apr 18, 2026
I propose we stick to the original plan, using #99097 as the base PR, followed by #100289 for the feature enhancements.
I am happy to address any remaining comments on #99097 to get it ready to merge. Once that is done, #100289 can just rebase on top of it.
@jfischer-no @josuah @MarkWangChinese let me know what you think.
josuah commentedon Apr 24, 2026
@santhosh-c-c I replied in #99097 directly.
josuah commentedon Jun 7, 2026
Looking at #105287 (comment), @roma-jam did you start working on MSC? That's great. Is this something in collaboration with @AidenHu (see above)?
roma-jam commentedon Jun 7, 2026
Hi @josuah,
No, it is not.
I didn‘t find any opened MSC host class related PRs.
Sorry if I am missing something.
From my side there is just a support for Bulk transfers in
uhc_dwc2plus local tests for MSC class with class specific requests withoutusbhlayer at all.josuah commentedon Jun 24, 2026
Edited first message from this comment #110420 (comment)
fkokosinski commentedon Jul 2, 2026
Hi @joshuah -
I was wondering if implementing MSC support is up for grabs. I see some past activity from @AidenHu, but by the looks of it it’s not being actively worked on. I see some activity MSC-related activity from @roma-jam w/r to DWC2 support (#102967), though, but it looks like it was more focused on testing the host controller driver rather than implementing the class support.
If my assessment is correct, we’d like to start working on adding mass storage class support to Zephyr USB host support.
roma-jam commentedon Jul 2, 2026
Hi @fkokosinski,
your summary is right.
It is better to wait @AidenHu to reply, because they already started enabling host msc class but didn‘t publish anything yet (according to the last state from 08.06.26).
AidenHu commentedon Jul 3, 2026
Hi @fkokosinski, @roma-jam and @josuah
Thank you for focusing on host MSC. Actually I have started enabling this class, and the earliest I expect to submit a PR is early August.
maass-hamburg commentedon Sep 23, 2026
For usb host controllers with multiple ports, do we want them to emulate a usb hub as the root hub, like linux, windows, freebsd and uboot do? or do something else?
I added usb hub emulation to my usb ohci controller:
#107065
maass-hamburg commentedon Sep 23, 2026
For using the devicetree for the usb devices that are connected to a usb host controller, there is president in the linux kernel: https://github.com/torvalds/linux/blob/fe2ec83746e501645709761605c2464a44fd2929/Documentation/devicetree/bindings/usb/usb-device.yaml and http://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
But in Linux they usually use it for hard wired usb devices. And I think we should at least support it for fixed usb devices like linux does. But that requires the possibility to bind a specific class instance to a specific port of the usb host controller or a usb hub.
thenguyenyf commentedon Sep 29, 2026
Hello. I'd want to inform that we have sent out the support for USBH DFU and Billboard class driver
For the USBH HID support, we have sent out a PR that adding both HID boot and HID report protocol. However, an existing PR for HID boot has been sent out by @fkokosinski. We are discussing how the review process and feature alignment for both PRs could move forward. Sorry for the delayed information, which could result in duplication of development efforts.
We have also started developing a vendor-specific class driver. It is ready locally, and the pull requests will be sent out shortly.
@jfischer-no , @josuah . If there is no issue with you, I'd like to update these items into planned list.