Follow us on Google+ Follow us on Facebook Follow us on Twitter

Opened 6 years ago

Last modified 4 weeks ago

#383 new enhancement

USB device removal

Reported by: Jiri Svoboda Owned by:
Priority: major Milestone:
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 (10)

comment:1 Changed 6 years ago by Jan Vesely

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

comment:2 Changed 6 years ago by Jan Vesely

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 Changed 6 years ago by Jiri Svoboda

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 Changed 6 years ago by Jan Vesely

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 Changed 6 years ago by Jan Vesely

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 Changed 6 years ago by Jiri Svoboda

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 Changed 6 years ago by Jakub Jermář

Milestone: 0.5.00.5.1

comment:8 Changed 6 years ago by Jiri Svoboda

See also: #448

comment:9 Changed 3 years ago by Jakub Jermář

Milestone: 0.6.00.7.1

comment:10 Changed 4 weeks ago by Jakub Jermář

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