drivers: uhc: uhc_mcux_common: add direction handling for non-setup packet

[yimjiajun]

to ensure proper processing by the SDK, logic has been enhanced to correctly determine the direction of non-setup USB transfers using the endpoint direction. This guarantees that USB_IN and USB_OUT directions are handled accurately, especially for bulk and other non-setup request packets.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[mmahadevan108]

@yimjiajun , were you seeing any failures?

[yimjiajun]

yes, when sending to an endpoint other than 0 and not using standard request packet, the first byte is no longer bmRequestType. Therefore, the direction bit is not predictable in the same way. For example, in bulk transfers, an OUT token is might always used, even if the endpoint is configured with an IN direction.

[tmon-nordic]

For example, in bulk transfers, an OUT token is might always used, even if the endpoint is configured with an IN direction.

That must be some rather strange HAL design decision, it is definitely not how USB works. OUT token is only used for bulk OUT endpoints.

[yimjiajun]

The OUT token can be used for interrupt or bulk either control transfers. it’s not limited to bulk transfers.
In this case, the mcux_xfer->direction value is used to pass the transfer direction to the NXP SDK, which uses it to determine whether to process the transfer as an IN or OUT token.

In USB, bit 7 of the endpoint address (bEndpointAddress) indicates the direction of the endpoint:
0: OUT (host to device)
1: IN (device to host)
This bit can be used to determine the transfer direction in the USB stack.
Where using on 1 to 15 endpoint-address[3:0] rather than 0.