Commit graph

11 commits

Author SHA1 Message Date
Tomasz Moń
8d344cc9d8 usb: device_next: Rename usbd_contex to usbd_context
Add the missing "t" to struct usbd_contex. No functional changes.

Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
2024-06-03 06:43:20 -07:00
Johann Fischer
2bc55f17ec usb: device_next: rename usbd_class_node to usb_class_data
Since only usbd_class_node contains the class instance data, rename it
to usbd_class_data.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
2024-04-22 06:51:22 -07:00
Johann Fischer
9acd1e877d usb: device_next: temporarily remove struct usbd_class_data
With the latest change, there are two structures that actually contain
class instance related data. Merge them into usbd_class_dnode, because
there is already a handy macro that can be used in class instances.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
2024-04-22 06:51:22 -07:00
Tomasz Moń
5144d0f65f usb: device_next: Introduce speed specific configurations
USB High-Speed devices must be able to operate at both High-Speed and
Full-Speed. The USB specification allows the device to have different
configurations depending on connection speed. Modify the API to reflect
USB Specification requirements on what can (e.g. configurations) and
what cannot (e.g. VID, PID) be speed dependent.

While the class configurations for different speeds are completely
independent, the actual class instances are shared between operating
speeds (because only one speed can be active at a time). Classes are
free to provide different number of interfaces and/or endpoints for
different speeds. The endpoints are assigned for all operating speeds
during initialization.

Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
2024-04-22 06:51:22 -07:00
Johann Fischer
42f7e1b97f usb: device_next: make HS support compliant with the USB2.0 specification
For specification-compliant high-speed support, we need to support
device quilifiers and other-speed-configuration descriptor requests. We
also need to store different configurations of the class/function
descriptors, which typically only affect the endpoint descriptors. With
this change, the stack expects class/function descriptors to be passed
as an array of struct usb_desc_header pointers to e.g. interface,
interface-specific, and endpoint descriptors, with the last element of
the array pointing to a nil descriptor. And also passed for a specific
speed, for now we support full and high speed configurations.

During instantiation, the class/function implementation must choose the
correct configuration in the full-speed and high-speed descriptor sets
for values such as maximum packet size and bInterval values of interrupt
and isochronous endpoints.

During initialization, the stack reads the highest speed supported by
the controller and uses it to get the appropriate descriptors set
from the instance. If the controller supports only full speed, the stack
configures the class/function descriptor for full speed only, if the
controller supports high speed, the stack configures the descriptors for
high speed only, and a class/function must update the full speed
descriptor during the init callback processing.

During device operation, the class/function implementation must check
the actual speed of the device and use the correct configuration, such
as the endpoint address or maximum packet size.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
2024-04-22 06:51:22 -07:00
Johann Fischer
fde4530055 usb: device_next: add helpers to get private data and device context
The class implementations should not access the members of the struct
usbd_class_node directly.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
2024-04-22 06:51:22 -07:00
Gerard Marull-Paretas
dacb3dbfeb iterable_sections: move to specific header
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2023-05-22 10:42:30 +02:00
Tomasz Moń
3532c2563a usb: device_next: accept padded Mass Storage CDBs
Universal Serial Bus Mass Storage Specification For Bootability requires
that device shall accept Bulk-Only-Transport bCBWCBLength of 12 for all
commands documented in the specification. Allow padding for commands
documented in Bootability specification, but leave others intact.

This fixes Request Sense on Windows 11 which previously failed due to
bCBWCBLength being 12 instead of 6.

Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
2023-05-17 11:45:45 +02:00
Tomasz Moń
4c97dd546a usb: device_next: msc: STALL OUT when waiting for reset
Mass Storage Class allows device to either silently discard OUT endpoint
data after receiving invalid CBW or to STALL the OUT endpoint (and keep
it STALLed regardless of host clearing halt) until Reset Recovery.

Switch from silently discarding to STALL in order to allow host realize
that device waits for Reset Recovery without transferring complete OUT
data.

Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
2023-03-07 15:48:40 +01:00
Tomasz Moń
7527b38ff5 usb: device_next: fail Mass Storage requests with invalid length
Fail Mass Storage control requests if wLength is incorrect.

Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
2023-03-01 12:02:29 +01:00
Tomasz Moń
509c033c1d usb: device_next: new USB Mass Storage implementation
Introduce new USB Mass Storage Bulk-Only Transport implementation
written from scratch. Main goal behind new implementation was to
separate USB and SCSI parts as clearly as possible.

Limited set of SCSI disk commands is implemented in separate source code
file that is internal to USB device stack. While it should be possible
to use the SCSI implementation by other components there is currently no
other user besides USB MSC and therefore SCSI header is kept private.

Signed-off-by: Tomasz Moń <tomasz.mon@nordicsemi.no>
2023-02-24 15:19:20 +01:00