usbh: tuh_edpt_abort_xfer releases the endpoint even when the HCD had nothing to abort
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- c
- Domain
- embedded-iot
Research direction
Read src/host/usbh.c around tuh_edpt_abort_xfer() and the abort-return contract in hcd.h first. Audit the HCD implementations named in the issue: rusb2, musb, ohci, ch32_usbfs, template, max3421, and ip3516. Done means their return values consistently indicate whether an abort occurred and usbh preserves the queued-completion behavior when nothing was aborted.
Written by the indexing model from the issue text.
Description
From #4177. tuh_edpt_abort_xfer() clears BUSY and releases a non-control endpoint whatever hcd_edpt_abort_xfer() returns: https://github.com/hathach/tinyusb/blob/7936dae4e/src/host/usbh.c#L1260-L1262
If the transfer completed just before the abort, its completion event is already queued. The abort finds nothing to cancel, usbh releases the endpoint, the caller re-arms it, and then the queued event runs: it clears the new transfer's BUSY/CLAIMED and invokes the callback, so the class arms the endpoint a second time.
Evidence: hit on raspberry_pi_pico2 with a stress hook that aborted and re-armed the hub status endpoint every frame: rp2040 int_edpt_abort reported "already completed" once, then the second arm panicked buf_ctrl @ 0x50100088 already available. With the hook changed to re-arm only when the HCD abort returned true, 3×7084 cycles ran clean.
Remaining work
- usbh should leave BUSY set (the queued completion releases it) when
hcd_edpt_abort_xfer()returns false, ashcd.hdocuments. - HCD returns are inconsistent today (rusb2, musb, ohci, ch32_usbfs, template return false unconditionally or for unsupported cases; max3421, ip3516 return true), so each port needs auditing before usbh relies on the return.
Why deferred: cross-HCD change; #4177 only makes rp2040 return false when nothing was active.
- Dominant language
- C
- Stars
- 7.2k
- Forks
- 1.6k
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 100
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hathach/tinyusb
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 1/5 Under an hour Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
libsdl-org/SDL#16607 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
PowerShell/Win32-OpenSSH#2482 · 1 reaction ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
zephyrproject-rtos/zephyr#123881 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day