USBD event and composite-device handling

[pawelzadrozniak]

Issues to be addressed:

• The USB (power) events should be notified to the application by the core USB stack, not the particular classes. This means they are handled in common code and not by each particular class. This means a new type of event that is common to all classes, and we need a new core USB callback to the application that is not tied to any class, but common to all of them.

• Composite and non-composite code paths are currently separate implementations. These should be merged into a single one that handles both cases, by making the code composite-enabled. PRs USB: Automatically define COUNT number of USB Devices #13310 and USB: first step at unifying legacy and composite #11041 are starting points in that direction.

In-depth description:

USB device stack - power state tracking.
In a real life application with USB device stack, we need to keep track of power state. if the cable is connected or not and if the bus is suspended or active. I see it as a fundamental feature, so it could be embedded in USBD to simplify application.

Currently, USBD acts as a proxy passing driver events to the class implementation and the only way knowing the bus state in application is to use class callback - classes forward the event from driver. To make things worse, we will get multiplied events (i.e. "suspended") when using a multiple classes/instances (composite device).
Power / bus events are related to the stack itself and IMO should not be coming from class.

This is how see it:
A main dispatcher in usb_device.c (just like the one for composite device) which will forward driver events to every class instance + application callback (only necessary events, like cable connect/disconnect, etc.).
Classes would pass only related events in a callback, i.e. HID events.
In such case - do we still need to split implementation info composite and non-composite device?
I would prefer to avoid #ifdef CONFIG_COMPOSITE_DEVICE everywhere.

Please let me know what you think.

[jfischer-no]

In such case - do we still need to split implementation info composite and non-composite device?
I would prefer to avoid #ifdef CONFIG_COMPOSITE_DEVICE everywhere.

No, this should go away.
I started working on it, but I do not have time to finish it. @aurel32 has opened a PR that goes in this direction #11041

[eobalski]

Closed by #20375