rusb2: OUT clear-halt and iso activate leave a stale BRDY after ACLRM
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 65/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- c
- Domain
- embedded-iot
Research direction
Read src/portable/renesas/rusb2/dcd_rusb2.c, especially dcd_edpt_clear_stall() and dcd_edpt_iso_activate(), and compare the OUT and IN branches' use of pipe_brdy_clear(). Clear BRDYSTS after ACLRM in both OUT paths, then validate with usbtest on ra4m1_ek (USBFS) and ra6m5_ek (USBHS).
Written by the indexing model from the issue text.
Description
Deferred from https://github.com/hathach/tinyusb/pull/4146 (#4038). Pre-existing at the PR's base 834c42cb8.
The OUT branch of dcd_edpt_clear_stall() (src/portable/renesas/rusb2/dcd_rusb2.c:1118-1127) and dcd_edpt_iso_activate() (:1028-1033) run ACLRM without clearing BRDYSTS; the IN branch does (:1114-1115, pipe_brdy_clear()).
Evidence
- A packet completing during
pipe_reset()'s PBUSY wait leaves a stale BRDY. Afterdcd_int_enable()a queued or iso pipe enterspipe_xfer_out()->pipe_wait_for_ready()(:155-160) and spins on FRDY up toRUSB2_FIFO_READY_SPIN(100000) inside the ISR. - RA6M5 UM R01UH0891EJ0150 §29.3.6.1 p993: a receive pipe raises BRDY only on packet reception, and PIPEBRDY is cleared only by software.
- Effect is bounded ISR latency, no corruption seen.
Remaining work
- Clear BRDYSTS for the pipe after ACLRM in both paths, via the same
pipe_brdy_clear()helper. - Validate on ra4m1_ek (USBFS) and ra6m5_ek (USBHS) with usbtest.
Why deferred: same omission exists at the base; outside #4146's scope.
Related: #4148 — bus-reset ACLRM preconditions and the 100 ns hold, same file.
- Dominant language
- C
- Stars
- 7.2k
- Forks
- 1.6k
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 96
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
-
test_audio_host: out-of-bounds read in test_audio_host_uses_exponential_full_speed_iso_intervalOpenfollowup Prio 📌
Difficulty 2/5 1-3 hours 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
-
followup Prio 📌
Difficulty 1/5 Under an hour Newbie friendliness 84/100
Maintainers usually reply within 1 day
Similar issues
-
dspromote: /etc/exports uses -alldirs on non-mount-point directories, so mountd exports nothingOpenbug
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
nextbsd/nextbsd-userland#434 ·
Maintainers usually reply within 1 day
-
[YSQL] Local-node initdb reads postgres.bki, but YB clusters bootstrap only from yb_postgres.bkiOpenarea/ysql kind/enhancement priority/low status/awaiting-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
yugabyte/yugabyte-db#35763 ·
Maintainers usually reply within 1 day
-
category:port-update
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 2 days
-
emerge failure MARK mark-unstable media-kit
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
macaroni-os/mark-issues#834 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
NVIDIA/open-gpu-kernel-modules#1479 · 2 comments ·
Maintainers usually reply within 1 day