drivers: usb: udc: fix for control buffer rework#106339
drivers: usb: udc: fix for control buffer rework#106339MaureenHelm merged 4 commits intozephyrproject-rtos:mainfrom
Conversation
Slightly refine the format Signed-off-by: Chun-Chieh Li <ccli8@nuvoton.com>
The crash results from Control transfer STALL interrupt flag not cleared. To catch all uncleared interrupt flags, all Control transfer interrupt flags are cleared altogether at one place instead of separately, with their handling order not changed. Signed-off-by: Chun-Chieh Li <ccli8@nuvoton.com>
The scheduled transfer message can be just a hint and its attached transfer buffer can be NULL. Skip this case. Signed-off-by: Chun-Chieh Li <ccli8@nuvoton.com>
Remove the error check because it may misjudge some right cases. For example, for HSUSBD, in the case Setup-DataIn-StatusOut and immediately following Setup-DataOut-StatusIn, the DataOut in the second Control transfer has arrived but user buffer for OUT may be only ready for StatusOut in the first Control transfer. Signed-off-by: Chun-Chieh Li <ccli8@nuvoton.com>
|
| priv->ctrlout_tailroom -= data_len; | ||
| } | ||
|
|
||
| if (data_rmn) { |
There was a problem hiding this comment.
DataOut in the second Control transfer has arrived but user buffer for OUT may be only ready for StatusOut in the first Control transfer
What I found problematic is that the hardware automatically receives first Data Out transfer. The workaround for this in software is to mask HSUSBD_CEPINTEN_RXPKIEN_Msk so even that data packet was received, it won't be processed until data buffer is enqueued. Is it possible for the HW to not automatically accept first Data Out packet?
There was a problem hiding this comment.
Yes, the HSUSBD hardware will automatically receive the first Data Out transfer. However, the hardware doesn't open related control to disable it.
jfischer-no
added
bug
5 participants
For Nuvoton NuMaker SoC series, this has the following modifications after USB UDC rework #103493. It includes: