#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 |
Description
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 , 13 years ago
comment:2 by , 13 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 , 13 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 , 13 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 , 13 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 , 13 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 , 12 years ago
Milestone: | 0.5.0 → 0.5.1 |
---|
comment:8 by , 12 years ago
See also: | → #448 |
---|
comment:9 by , 10 years ago
Milestone: | 0.6.0 → 0.7.1 |
---|
comment:10 by , 7 years ago
Milestone: | 0.7.1 |
---|
comment:11 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fix merged in commit df6ded8c93d4c5e36bb3d1598f5b42fb5553ffe3:
commit df6ded8c93d4c5e36bb3d1598f5b42fb5553ffe3 Merge: f5e5f73a3 b2dca8de8 Author: Jakub Jermar <jakub@jermar.eu> Date: Wed Feb 28 17:06:42 2018 +0100 Merge github.com:helenos-xhci-team/helenos 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 , 6 years ago
Milestone: | → 0.7.2 |
---|
Initial support for device_gone (hubs try to remove attached devices, support in libusbdev) and hubdriver implementation was merged in r1274.