Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a4cf02c590
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (epx->dev_addr == dev_addr && epx->max_packet_size > 0) { | ||
| usbh_dpram->epx_buf_ctrl = 0; | ||
| usbh_dpram->epx_ctrl = 0; | ||
| rp2usb_reset_transfer(epx); |
There was a problem hiding this comment.
When an address-0 device behind a hub is unplugged while its EPX transfer is active and another attached device already has a non-interrupt transfer pending, this reset leaves epx->state as EPSTATE_IDLE without starting the survivor. The RP2040 SOF path in hcd_rp2040_irq() switches to next_ep only while the current EPX is active, and the RP2350 path requires a stopped-on-NAK event that cannot arrive after these registers are cleared, so the pending transfer can remain stuck indefinitely unless unrelated work later re-arms EPX. After removing the closing device's endpoints, explicitly hand EPX to a surviving pending endpoint and normalize the polling/switch state.
Useful? React with 👍 / 👎.
| if (epx->dev_addr == dev_addr && epx->max_packet_size > 0) { | ||
| usbh_dpram->epx_buf_ctrl = 0; | ||
| usbh_dpram->epx_ctrl = 0; | ||
| rp2usb_reset_transfer(epx); |
There was a problem hiding this comment.
When an address-0 device behind a hub disappears during an active SETUP transaction, zeroing epx_ctrl and epx_buf_ctrl does not cancel that transaction because hcd_setup_send() arms it solely through the SIE SEND_SETUP/START_TRANS bits. The root bus remains connected in this topology, so after rp2usb_reset_transfer() frees the software endpoint, the old SIE operation can still produce a TRANS_COMPLETE or STALL interrupt; both handlers then report completion using the current epx, potentially completing a reused address-0 endpoint or another device's transfer. Stop the active SIE transaction and clear its latched completion state before resetting or reusing EPX.
Useful? React with 👍 / 👎.
Hardware-in-the-loop (HIL) Test ReportNo HIL run for this push (no affected boards, or hardware testing did not run). |
Code sizeBaseline: unavailable - the PR snapshots record no single base commit 0 builds on 0 boards compared, 0 changed Not compared:
no comparable pairs |
This branch has not been deployed
1 participant
This fixes repeated USB-device unplug/re-plug failures on the RP2040 host controller, which could panic with "buf_ctrl ... already available".
AI (Codex) analysis traced the failure to stale state in the shared EPX DPRAM registers:
The changes adapt safeguards from commits 93ff3da and 9ac343a that seem to have gone lost during later RP2040 HCD refactoring.
I have verified the fix on an original Raspberry Pi RP2040 board with repeated unplug/re-plug testing; the panic no longer occurs.
Tested with a Bluetooth HCI USB to UART bridge which uses Control, Interrupt and Bulk transfers.