Skip to content
Snippets Groups Projects

fix(usbcdc): Re-enable after lockup when attached again

Merged schneider requested to merge schneider/cdc-reenable into master

When opening an ACM device Linux sends the ACM_SET_CONTROL_LINE_STATE with DTR and CTS high. We can use this re-enable the ACM device on our side after a lockup.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Looks good to me! Thanks for keeping our codebase clean.

    However, I'm only a bot - so a human will still have to approve this request.

  • This is great! While at it, is there a similar callback when the device is closed? Maybe we can circumvent the need for the ugly lockup_disable altogether that way? I.e. revert the hack in 4a292ac0 ("workaround(cdcacm): Fix CDC-ACM lockup on host hangup") finally?

  • I tried a lot, but there are quirks...

    The following creates such an event:

    • attach card10
    • run cat /dev/ttyACM0
    • hit Ctrl+c

    The following does not:

    • attach
    • run screen /dev/ttyACM0
    • hit Ctrl+a k

    Don't know why :/

  • I tried a lot, but there are quirks...

    The following creates such an event:

    • attach card10
    • run cat /dev/ttyACM0
    • hit Ctrl+c

    The following does not:

    • attach
    • run screen /dev/ttyACM0
    • hit Ctrl+a k

    Don't know why :/

  • Looked a bit through the relevant kernel code, I guess screen sets stty -hupcl by default which supresses the DTR lowering though the tty subsystem. If that is correct, screen /dev/ttyACM0 hupcl should trigger the event. But in any case, this path is never going to work reliably.

    What could work is a detection somewhere on USB bus level. If I interpret the code correctly, once the last open fd for the CDC-ACM device is closed, any writes from card10 will be answered with an error. So ideally, MAXUSB notices this and stops trying to overfill its internal buffer ... Which is what my hack is doing right now (in a very dirty way) so we're back where we'd need to fix MAXUSB internals :/

  • rahix added 1-Additional-Feature label and removed 1-Bug label

    added 1-Additional-Feature label and removed 1-Bug label

  • Though regarding the changes in this MR: I think this is fine; worst case we won't detect all wakeups (if the tty was configured with stty -hupcl) and if there were any accidental wakeups, we'd go back to lockup_disable = 1 automatically anyway.

  • rahix mentioned in issue #54

    mentioned in issue #54

  • merged

  • rahix mentioned in commit 12992926

    mentioned in commit 12992926

Please register or sign in to reply
Loading