USB suspend/resume on board startup

[pdunaj]

Describe the bug
When I start the PCA10059 with USB enabled I see that driver is suspending USB only to resume it immediately. We were asserting various states so we caught this one. I am not sure if this is a bug but it looks like one as I see no reason why suspend should be triggered after board powering up. In the past version of the driver this was not occurring.

To Reproduce
Steps to reproduce the behavior:
Use PCA10059 start it and check state changes it is triggering.

Expected behavior
Suspend is not triggered when not needed.

Impact
Annoyance

Screenshots or console output

[00000005] <inf> event_manager: e: module_state_event module:main state:READY
[00000026] <inf> event_manager: e: module_state_event module:board state:READY
[00000028] <inf> event_manager: e: module_state_event module:usb_state state:READY
[00000144] <wrn> bt_hci_core: No ID address. Expecting one to come from storage.
[00000145] <inf> ble_state: Bluetooth initialized
[00000149] <inf> event_manager: e: module_state_event module:ble_state state:READY
[00000152] <inf> event_manager: e: usb_state_event id:0x200000b1 state:POWERED
[00000155] <inf> event_manager: e: module_state_event module:ble_scan state:READY
[00000160] <inf> config: Settings loaded
[00000163] <inf> event_manager: e: module_state_event module:hid_forward state:READY
[00000165] <inf> event_manager: e: module_state_event module:config state:READY
[00000168] <inf> event_manager: e: module_state_event module:ble_bond state:READY
[00000197] <inf> ble_scan: Scan started
[00000202] <wrn> usb_state: USB_DC_CONNECTED when USB is not disconnected
[00000304] <wrn> usb_state: USB suspend
[00000307] <inf> event_manager: e: usb_state_event id:0x200000b1 state:SUSPENDED
[00004221] <wrn> usb_state: USB resume
[00004225] <inf> event_manager: e: usb_state_event id:0x200000b1 state:POWERED

Environment (please complete the following information):
ncs zephyr 7453262 (from d9876be)

Additional context
N/A

[laperie]

Setting priortiy:low based on impact evaluation

[carlescufi]

@pawelzadrozniak is this a real bug or is this transition expected?

[pawelzadrozniak]

Looks like suspend/resume event is allowed behavior by USB spec, however I'll take a look at the driver.
I have recently moved event processing to system workqueue and I suppose it's caused by a delay, as I was in case of resume/reset after cable detachment.

[pawelzadrozniak]

I have checked it again - it was not showing up before, because those events were not forwarded properly.
USBD peripheral generates this events after connecting the cable - maybe because of delay between inserting the cable and the moment when bus becomes active.

[carlescufi]

@pawelzadrozniak I see. So is this considered a bug that needs fixing, or just an expected sequence of events?

[pawelzadrozniak]

@carlescufi IMO it's expected.

[carlescufi]

@pdunaj can you close this one if you are OK with @pawelzadrozniak 's explanation?

[pdunaj]

We discussed that with @pawelzadrozniak few days ago.
Before closing this issue I would prefer to wait for the PR fixing other USBD to be merged. I would like to check how USB will behave. I will talk with Pawel again and see the part of specification he mentioned. Once cleared I will closed the bug.

[pdunaj]

I checked the part of documentation pointed by @pawelzadrozniak and this behavior is indeed possible to enter suspend from powered. I am closing the bug.