Escalate USB recovery when keyboard HID writes time out - #1516
Draft
adamshiervani wants to merge 1 commit into
Draft
Escalate USB recovery when keyboard HID writes time out#1516adamshiervani wants to merge 1 commit into
adamshiervani wants to merge 1 commit into
Conversation
After a UDC rebind, the RV1106 DWC3 race can leave /dev/hidg0 openable but non-functional: every write times out while the UDC still reports "configured". The rebind recovery path verified health by reopening the chardev — which succeeds in this state — and writeWithTimeout swallows the deadline errors (host-suspend tolerance), so nothing ever escalated to the full gadget reconfigure that actually fixes it. Keyboard input was silently dropped until the user manually cycled identifier profiles (#1512). Two complementary mechanisms: 1. Write-probe verification in the recovery ladder: after reopening the keyboard HID file, re-send the current keys-down state (a no-op for the host) and, unlike the regular report path, surface a timeout. While the UDC reports "configured", a reopen that probes broken is not success — the ladder escalates to the full reconfigure instead of declaring victory, fixing the gadget before the user ever types. 2. Runtime write-timeout streak: consecutive keyboard write timeouts are counted (reset on success, on recovery, and while the state is not "configured", where timeouts are expected — e.g. host suspend). When the streak reaches 3 while "configured", recovery runs the full reconfigure directly, rate-limited to one attempt per 30s. This catches breakage that occurs without a preceding detach event. Fixes #1512
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1512
After a UDC rebind, the DWC3 race can leave
/dev/hidg0openable but dead: every write times out while the UDC still reportsconfigured. Recovery verifies health by reopening the chardev — which succeeds in that state — andwriteWithTimeoutswallows deadline errors (host-suspend tolerance), so the existing escalation to a full gadget reconfigure never fires. Keyboard input is silently dropped (mouse fine, stateconfigured) until identifier profiles are cycled by hand.Changes
configured→ escalate to the full reconfigure, so recovery completes before the user types.configured(where timeouts are expected, e.g. host suspend). 3 in a row whileconfigured→ full reconfigure, rate-limited to 30s. Covers breakage with no preceding detach.Testing
ra-hid-write-recoverye2e reproduces the bug deterministically: unbindusbhidfrom the gadget keyboard interface on the host → gadget writes time out whileconfigured. Fails ondev(keyboard dead for the full 120s window), passes here (recovery ~2s after the first timeout, confirmed by re-enumeration in host dmesg).hidg0unusable converges via ladder → reconfigure in one extra re-enumeration — no input needed, no reconfigure loop after.