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

[henrikbrixandersen]

Describe the bug The design of the USB device_next stack prevents the use of MSOSv2 descriptors.

The device-to-host vendor request targeting the device for the bMS_VendorCode is sent in the address state, which causes usbd_config_get_current() (called from usbd_class_get_by_req() to determine which class implementation to forward the vendor request to) to return NULL, as no configuration has been set yet.

Expected behavior Vendor requests targeting the device should be allowed in the address state.

Another possible solution could be to add a dedicated, application-level usbd callback for handling requests targeting the device. This would likely allow for a nicer application architecture.

Impact Unable to use MSOSv2 descriptors with USB device_next.

Environment (please complete the following information):

• OS: Any
• Toolchain: Any
• Commit SHA: v3.7.0-rc3

Additional context Discord thread on this topic: https://discord.com/channels/720317445772017664/733037537982939236/1265216134970478685

[jfischer-no]

Vendor requests targeting the device should be allowed in the address state.

I only know this statement from the specification: "USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured." So I do not think there are any requirements to classify it as a bug. Obviously, values in the vendor request table (per class data) may only be used in configured state.

Unable to use MSOSv2 descriptors with USB device_next.

MSOSv2 is a bit tricky. I have a draft to support it and will finish it soon along with porting the WebUSB sample.

If there are no objections in a few days, I will close it.

[henrikbrixandersen]

Vendor requests targeting the device should be allowed in the address state.

I only know this statement from the specification: "USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured." So I do not think there are any requirements to classify it as a bug. Obviously, values in the vendor request table (per class data) may only be used in configured state.

But you do agree that Windows USB enumeration sends a vendor request targeting the device using bMS_VendorCode while the device is still in address state?

Unable to use MSOSv2 descriptors with USB device_next.

MSOSv2 is a bit tricky. I have a draft to support it and will finish it soon along with porting the WebUSB sample.

I will be looking forward to that. Is the draft available yet?

If there are no objections in a few days, I will close it.

Please do not close it. What I describe here is possible with the current USB device stack, but not possible with the device_next stack. Not being able to support MSOSv2 descriptors in device_next is not acceptable if this is to replace the existing stack in v4.0.0.

If you are already working on supporting this feature, you can link it to close this issue report.

[tmon-nordic]

Vendor requests targeting the device should be allowed in the address state.

I only know this statement from the specification: "USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured." So I do not think there are any requirements to classify it as a bug. Obviously, values in the vendor request table (per class data) may only be used in configured state.

There is also:

The USB Specification defines a series of standard requests that all devices must support. These are enumerated in Table 9-3. In addition, a device class may define additional requests. A device vendor may also define requests supported by the device.

My understanding is that "must respond to standard device requests" refers only to the absolute requirements, while "device vendor may also define requests supported by the device" is an option for vendor (MSOSv2 does rely on this). If the vendor does define device requests, then it should be allowed to respond to the vendor device requests at least when not configured (but I see no real reason of not supporting them in the not addressed state - it is up to vendor to define at what state the request is valid after all) because these are bound to device, not interface nor class.

[jfischer-no]

Vendor requests targeting the device should be allowed in the address state.

I only know this statement from the specification: "USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured." So I do not think there are any requirements to classify it as a bug. Obviously, values in the vendor request table (per class data) may only be used in configured state.

But you do agree that Windows USB enumeration sends a vendor request targeting the device using bMS_VendorCode while the device is still in address state?

This is irrelevant, it is not a bug according to the specification.

Unable to use MSOSv2 descriptors with USB device_next.

MSOSv2 is a bit tricky. I have a draft to support it and will finish it soon along with porting the WebUSB sample.

I will be looking forward to that. Is the draft available yet?

No.

If there are no objections in a few days, I will close it.

Please do not close it. What I describe here is possible with the current USB device stack, but not possible with the device_next stack. Not being able to support MSOSv2 descriptors in device_next is not acceptable if this is to replace the existing stack in v4.0.0.

If you are already working on supporting this feature, you can link it to close this issue report.

Then please change it to "enhancement".