Planned USB host support work

[jfischer-no]

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 controller foobar ()

Stack

The stack is in an experimental, early-development state. Ongoing work:

• Class (Driver) API (@josuah USB Host: integrate class API [2: helpers] #94590)

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 (WIP @jfischer-no)
  • USB Video class driver (WIP Planned USB host video implementation #93517 @AidenHu @josuah)
  • Audio Class 2 driver
  • HID class support
  • USB DFU class support
  • USB MSC class driver (WIP Planned USB host support work #95661 (comment) @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 @MarkWangChinese)
  • 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 hub class enablement #99735 @AidenHu @MarkWangChinese)

[AidenHu]

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]

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]

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 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]

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]

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:

• USB Host: integrate class API [2: helpers] #94590

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:

• USB Host: integrate class API [3: UVC] #94591

This commit is providing the basic tests:

• 472e538

This is not an official recommendation from the USB maintainer, but hope this facilitates progress on both end.

[MarkWangChinese]

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:

• USB Host: integrate class API [2: helpers] #94590

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:

• USB Host: integrate class API [3: UVC] #94591

This commit is providing the basic tests:

• 472e538

This is not an official recommendation from the USB maintainer, but hope this facilitates progress on both end.

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.