usb: device_next: support BOS descriptor with vendor request code #76326

jfischer-no · 2024-07-26T12:07:48Z

Support BOS descriptor with vendor request code and add WebUSB sample for the new USB device stack.

Add a function similar to sample_usbd_init_device(), but one that does not initialize the device. It allows the application to set additional features, such as additional descriptors. Signed-off-by: Johann Fischer <[email protected]>

tmon-nordic · 2024-07-29T07:21:30Z

subsys/usb/device_next/usbd_ch9.c

Why abuse the descriptors list? I think it would be better to just have a separate list for the vendor requests. The vendor requests should not be limited to BOS-only, but generally any vendor (here: application developer) should be able to provide their own vendor commands in application.

Why abuse the descriptors list?

It is a descriptor and it does not abusing anything.

I think it would be better to just have a separate list for the vendor requests. The vendor requests should not be limited to BOS-only, but generally any vendor (here: application developer) should be able to provide their own vendor commands in application.

There are no requirements in the specification to allow arbitrary vendor request with recipient device. Using the BOS platform capability is the most portable.

How is this a descriptor? This is not descriptor in any way, just a way for application to register vendor commands. USB specification doesn't require the devices to implement any optional functionality (vendor commands are optional functionality). In this context the specification states "A device vendor may also define requests supported by the device.".

What do you mean by "most portable"? What does portability have to do with a stack functionality to allow application developer to support vendor commands?

Please familiarize yourself with how MSOS2 and WebUSB use the BOS descriptor, I am pretty sure you will understand it.

tmon-nordic · 2024-07-29T07:24:16Z

samples/subsys/usb/webusb/src/msosv2.h

Why this is defined in a header?

Why not? Or what is the problem? This is limited to a specific part and can be used as a template.

Everything compilation unit that includes this header will have the variables in the corresponding object file.

There is only that include it. So where is the problem?

tmon-nordic · 2024-07-29T07:25:20Z

samples/subsys/usb/webusb/src/webusb.h

Why this is defined in a header?

tmon-nordic · 2024-07-29T07:28:23Z

samples/subsys/usb/webusb/src/msosv2.h

Would it be possible to somehow take the advantage of the new stack to enable automatic struct msosv2_function_subset_header insertion when there is more than 1 interface?

The old stack did have #66449 as a solution, but that's fragile approach.

I do not think we can handle it. IMO it is better to write a comprehensive documentation about it, with some examples. I think the average user has no idea where and how to use MSOSv2 descriptors.

Comprehensive documentation is not a real solution but a way to avoid having to come up with a real solution. While the average user might not have idea about individual MSOSv2 descriptors, it would be good to provide "just-working" experience (if possible).

henrikbrixandersen

I would prefer a generic way to register vendor requests targeting the device (not a class nor an interface) from the application code. This could easily be used for handling MSOSv2 vendor requests, but wouldn't be limited to that (not all vendor requests would require a BOS).

carlescufi · 2024-10-23T17:54:00Z

@tmon-nordic @henrikbrixandersen can you please take another look?

tmon-nordic

The new bRequest registration seems fine, just few things to fix.

include/zephyr/usb/usbd.h

tmon-nordic · 2024-10-24T12:55:20Z

include/zephyr/usb/usbd.h

I would prefer some prefix on the node, e.g.

Suggested change

static struct usbd_vreq_node name = { \

static struct usbd_vreq_node usbd_vreq_node_##name = { \

Then the user does not know the real structure name. This makes sense for more abstract macros, but not here.

subsys/usb/device_next/usbd_ch9.c

subsys/usb/device_next/usbd_device.h

tmon-nordic · 2024-10-24T13:06:21Z

samples/subsys/usb/webusb-next/src/msosv2.h

If not implement it right now, at least add a TODO: Add subset header when there is more than one interface.

See #66449 for more information.

I have aligned it with the descriptor in the legacy sample and added a comment.

Allow the user to register a vendor request node identified by the vendor code (bRequest) and containing two callbacks to handle the vendor request. The device stack uses the vendor request node to call the vendor request callbacks when it receives a request of type Vendor, recipient Device, and bRequest value equal to the vendor code. Signed-off-by: Johann Fischer <[email protected]>

Platform capability descriptors such as MSOSv2 or WebUSB BOS have a vendor request code that is used by the host to perform vendor-specific requests. Add a convenient way to define and register a platform capability descriptor with a vendor request node. Signed-off-by: Johann Fischer <[email protected]>

Add a WebUSB sample that uses the new USB device support. Signed-off-by: Johann Fischer <[email protected]>

carlescufi · 2024-11-06T11:09:36Z

@henrikbrixandersen PTAL

jfischer-no added area: USB Universal Serial Bus Experimental Experimental features not enabled by default labels Jul 26, 2024

jfischer-no added this to the v4.0.0 milestone Jul 26, 2024

jfischer-no requested review from carlescufi, henrikbrixandersen and tmon-nordic July 26, 2024 12:07

jfischer-no self-assigned this Jul 26, 2024

zephyrbot added the area: Samples Samples label Jul 26, 2024

zephyrbot requested review from kartben and nashif July 26, 2024 12:08

tmon-nordic requested changes Jul 29, 2024

View reviewed changes

henrikbrixandersen reviewed Aug 13, 2024

View reviewed changes

carlescufi mentioned this pull request Sep 24, 2024

Planned USB device/host support rework/enhancements #42066

Closed

57 tasks

github-actions bot added the Stale label Oct 13, 2024

henrikbrixandersen removed the Stale label Oct 13, 2024

zephyrproject-rtos deleted a comment from github-actions bot Oct 17, 2024

jfischer-no force-pushed the pr-device_next-sample-webusb branch 3 times, most recently from 5291081 to 6f692c4 Compare October 21, 2024 10:51

carlescufi requested review from henrikbrixandersen and tmon-nordic October 23, 2024 17:53

tmon-nordic requested changes Oct 24, 2024

View reviewed changes

jfischer-no added 2 commits October 25, 2024 16:00

jfischer-no force-pushed the pr-device_next-sample-webusb branch from 6f692c4 to eb96943 Compare October 25, 2024 16:24

jfischer-no modified the milestones: v4.0.0, 4.1 Oct 25, 2024

jfischer-no added this to the v4.1.0 milestone Oct 25, 2024

samples: usb: add new WebUSB sample

210cda7

Add a WebUSB sample that uses the new USB device support. Signed-off-by: Johann Fischer <[email protected]>

jfischer-no force-pushed the pr-device_next-sample-webusb branch from eb96943 to 210cda7 Compare October 25, 2024 16:39

tmon-nordic approved these changes Oct 28, 2024

View reviewed changes

henrikbrixandersen approved these changes Nov 19, 2024

View reviewed changes

henrikbrixandersen linked an issue Nov 19, 2024 that may be closed by this pull request

usb: device_next: unable to handle vendor requests in address state #76224

Closed

henrikbrixandersen mentioned this pull request Nov 19, 2024

Create a WebUSB subsys driver #12527

Closed

4 tasks

nashif merged commit 1687e19 into zephyrproject-rtos:main Nov 19, 2024
23 checks passed

	static struct usbd_vreq_node name = { \
	static struct usbd_vreq_node usbd_vreq_node_##name = { \

usb: device_next: support BOS descriptor with vendor request code #76326

usb: device_next: support BOS descriptor with vendor request code #76326

Uh oh!

Conversation

jfischer-no commented Jul 26, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

henrikbrixandersen left a comment

Choose a reason for hiding this comment

Uh oh!

carlescufi commented Oct 23, 2024

Uh oh!

tmon-nordic left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carlescufi commented Nov 6, 2024

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants