nrf52: usb: better check state on IN resume

[bradjc]

While running a modified printf_long test app that prints a long string in a loop on nano33ble, I got an assertion failure:

Kernel panic at chips/nrf52/src/usbd.rs:1749:
	"assertion failed: `(left == right)`
  left: `Some(InData)`,
 right: `Some(Init)`"
	Kernel version release-1.5-500-g9c520bd6b

This happens because the resume_in function was only checking the state of the DMA, but not of the IN endpoint, which might be finished with DMA but the entire transfer hasn't finished. I think this wasn't occurring before because with short IN transfers, the end of the DMA and the end of the transfer occur very close to each other and the endpoint wasn't in the InData state very long. However, with a longer transfer the InData state is longer and thus this assertion could fail.

The fix is just to check both states, and enqueue the resume in request if either is true.

Testing Strategy

This pull request was tested by running printf_long in a loop on nano33ble. It actually works!

TODO or Help Wanted

You can see my comment about the driver calling packet_in() as a direct result of the client calling endpoint_resume_in(). That should be fixed at some point, or the USB HIL should be changed so that there are no longer upcalls asking for data.

Documentation Updated

• Updated the relevant files in /docs, or no updates are required.

Formatting

• Ran make prepush.

[brghena]

Good fix.

As for the TODO, lots of areas of the USB stack are pretty crufty and in need of a rewrite. Documenting problem areas when we find them is at least helpful towards that future goal.

[ppannuto]

bors r+

[bors]

Build succeeded:

• ci-tests (macos-latest)
• ci-format (ubuntu-latest)
• ci-build (macos-latest)
• ci-build (ubuntu-latest)
• ci-tests (ubuntu-latest)
• ci-qemu
• ci-format (macos-latest)