Opened 12 years ago

Closed 6 years ago

Last modified 5 years ago

#383 closed enhancement (fixed)

USB device removal

Reported by: Jiri Svoboda Owned by:
Priority: major Milestone: 0.7.2
Component: helenos/usb/other Version: mainline
Keywords: Cc:
Blocker for: Depends on: #390
See also: #448


Now that DDF supports device removal (anticipated and surprise), the USB stack should be enhanced to make use of this functionality.

Change History (12)

comment:1 by Jan Vesely, 12 years ago

Initial support for device_gone (hubs try to remove attached devices, support in libusbdev) and hubdriver implementation was merged in r1274.

comment:2 by Jan Vesely, 12 years ago

All drivers but usbmouse support surprise unplug.
The only driver that makes sense to support anticipated removal is mass storage (dunno, maybe unmount is enough).
IMO this could be closed as fixed.

comment:3 by Jiri Svoboda, 12 years ago

All drivers should support anticipated removal (i.e. dev_remove entry point) regardless whether surprise removal could cause any potential problem or not. If a driver already supports surprise removal (dev_gone), adding support for anticipated removal should be relatively easy.

comment:4 by Jan Vesely, 12 years ago

OK, thx, I was not sure whether device remove for devices that have not use of it(mouse, keyboard,…) should be considered not supported or noop.

comment:5 by Jan Vesely, 12 years ago

Depends on: #390

Ignore my last comment, anticipated removal can not be supported unless there is a way to abort ongoing communication. Surprise removal is easier in this regard as there is no ongoing communication.

comment:6 by Jiri Svoboda, 12 years ago

Actually it depends on whether the anticipated removal is forced or not. Non-forced removal only succeeds if there are no clients connected to the device. Forced removal always succeeds and kicks any potential clients out.

I think that for non-forced removal you do not need a way to abort communication (no clients - no communication, if any communication is in progress, you can fail).

I admit that it is not documented whether an offline operation is forced or not, I need to fix this in the documentation. I imagine it should be implemented as not forced (the easier case) now and then we should perhaps add the possibility to pass a force flag. Non-forced removal is the more interesting case since it is normally sufficient for anticipated removal.

comment:7 by Jakub Jermář, 12 years ago


comment:8 by Jiri Svoboda, 12 years ago

See also: #448

comment:9 by Jakub Jermář, 9 years ago


comment:10 by Jakub Jermář, 6 years ago

Milestone: 0.7.1

comment:11 by Jakub Jermář, 6 years ago

Resolution: fixed
Status: newclosed

Fix merged in commit df6ded8c93d4c5e36bb3d1598f5b42fb5553ffe3:

commit df6ded8c93d4c5e36bb3d1598f5b42fb5553ffe3
Merge: f5e5f73a3 b2dca8de8
Author: Jakub Jermar <>
Date:   Wed Feb 28 17:06:42 2018 +0100

    This commit merges support for USB 3 and generally refactors, fixes,
    extends and cleans up the existing USB framework.
    Notable additions and features:
      * new host controller driver has been implemented to control various
        xHC models (among others, NEC Renesas uPD720200)
      * isochronous data transfer mode
      * support for explicit USB device removal
      * USB tablet driver

comment:12 by Jakub Jermář, 5 years ago

Milestone: 0.7.2
Note: See TracTickets for help on using tickets.