Commit graph

5 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
693191467d usb: device_next: add USB device context to message delivery callback
Add USB device context argument to message delivery callback.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
2024-05-15 17:29:24 +01:00
Johann Fischer
22d574cb3c usb: device_next: tweak USB device notification support
Since no threads are waiting for the FIFO and we do not need any k_fifo
features, we can just use slist.

Some notifications (caused by interrupts), especially "VBUS ready", can
be triggered very quickly right after UDC initialization if the USB
controller is already connected. Depending on the global thread
configuration, messsage publishing work can be executed before the
context is marked as initialized. Use delayed work to reschedule
publishing when the context is not initialized.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
2024-05-15 17:29:24 +01:00
Johann Fischer
567827add8 usb: device_next: use USB notification in CDC ACM implementation
Add message types for line coding and contol line state updates.
Add a publish message function that takes a pointer to a device
structure as payload, and use USB notification in the CDC ACM
implementation.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
2024-03-22 10:10:42 +01:00
Johann Fischer
3aef852fc0 usb: device_next: implementation of USB device support notification
The implementation uses the system workqueue and a callback provided
and registered by the application. The application callback is called in
the context of the workqueue. Notification messages are stored in a
queue and delivered to the callback in sequence.

We cannot call application callback directly from the USB device stack
thread because the behavior of arbitrary code provided by the
application is unpredictable, and we do not want it to be executed in
the same context where all events from the device controller are
handled.

Nor can we use the ZBUS subsystem directly. ZBUS offloads responsibility
for defined behavior to the observers and application, and does not
provide any way for the publisher to enforce defined behavior and
execution context.
ZBUS listener would be called from the USB thread context and is not
acceptable. ZBUS subscriber does not provide delivery guarantee and
cached message can be overwritten. ZBUS message subscriber has
cumbersome global configuration and buffers that are too complicated to
handle from USB configuration, and even if we would use it, defined
behavior is not possible because of how listener and subscriber are
handled.

Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
2024-03-22 10:10:42 +01:00