[topic-usb] USB stack rework. ToDo list.

[eobalski]

Introduction

This issue is created to list all things that should be reworked in topic-usb before its merged into master.

Problem description

USB device stack requires rework to address feature requests that we currently have. Some of them:

• usb: api: Cleanup of current inclusion path for USB #20236 usb: api: Cleanup of current inclusion path for USB
• usb: investigate if Network Buffer can be used in USB device stack and USB drivers #19713 usb: investigate if Network Buffer can be used in USB device stack and USB drivers
• USB GET_INTERFACE response always 0, even when an alternate setting is used #24200 USB GET_INTERFACE response always 0, even when an alternate setting is used
• USB: enable/disable a class driver at runtime  #25604 USB: enable/disable a class driver at runtime
• usb: allow the instances of a USB class to be enabled and disabled at runtime #29135 usb: allow the instances of a USB class to be enabled and disabled at runtime

ToDo list:

• Extend the possibility to have more than one alternate setting for interface. (follow up of [topic-usb]First step to rework USB core. #26733)
  This point requires updates to struct usb_if_descriptor. @emob-nordic
• Make all drivers use bitfields introduced in [topic-usb]usb: remove obsolete request handlers array  #26854. Remove direction, type and recipient getter macros. @jfischer-phytec-iot
• USB Framework (Chapter 9) defines and structures rework/cleanup [topic-usb] usb: add Chapter 9 header #27045
• Introduce USB device state tracing in USB device core so that classes would copy/paste same code in status_callback like usb: hid: Allow to send data only if CONFIGURED #27119 (HID) and usb: cdc: Do not duplicate USB transfer slots for OUT transfers #27025 (CDC) do.
• Use net_bufs and common usb_transfer mechanism across the stack (Addressing issues: usb: investigate if Network Buffer can be used in USB device stack and USB drivers #19713 usb: audio: high CPU load when running headphones_microphone sample #26857)

[koffes]

Geetings! Has a timeline been set for this task?

[eobalski]

@koffes The work has started but We cannot say the exact timing.

[koffes]

What is the status of this issue?

[jfischer-no]

What is the status of this issue?

Is almost ready.

[jfischer-no]

This issue should probably be closed because it mixes points that have already been fixed in current USB device support and design issues that can only be fixed with the new implementation of USB device controller API and USB device stack.

[jfischer-no]

Close in favor of #42066