> DriveEject() is sufficient on iPod and Kindle to make the "unsafe to remove
> blabla" warning go away.
Right, that's why I wondered why drive detaching was necessary. Just as a way to "clean up" and also reduce power consumption, or whether some devices really need it. (Just in case we need to disable can_detach right before a release, when time gets tight :) ).
> Maybe we can look at the usb interface classes to avoid ejecting USB connected
> card readers? I also think the DMI data tells you whether a particular usb port
> has an external receptable - I remember Kay talking about that (adding to Cc).
(In reply to comment #1)
> DriveEject() is sufficient on iPod and Kindle to make the "unsafe to remove
> blabla" warning go away.
Right, that's why I wondered why drive detaching was necessary. Just as a way to "clean up" and also reduce power consumption, or whether some devices really need it. (Just in case we need to disable can_detach right before a release, when time gets tight :) ).
> Maybe we can look at the usb interface classes to avoid ejecting USB connected
> card readers? I also think the DMI data tells you whether a particular usb port
> has an external receptable - I remember Kay talking about that (adding to Cc).
That would be nice. The original report already has an udev dump (http:// launchpadlibrar ian.net/ 29486956/ UdevDb. txt):
P: /devices/ pci0000: 00/0000: 00:1d.7/ usb1/1- 3/1-3:1. 0/host2/ target2: 0:0/2:0: 0:0/block/ sdb ENC=Generic- ENC=Multi- Card\x20\ x20\x20\ x20\x20\ x20 INTERFACES= :080650:
E: ID_VENDOR=Generic-
E: ID_VENDOR_
E: ID_VENDOR_ID=0bda
E: ID_MODEL=Multi-Card
E: ID_MODEL_
E: ID_MODEL_ID=0158
E: ID_TYPE=disk
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_USB_
> Please also ask the original reporter for output of dmidecode and
> 'tree /sys'.
Done, will report back when data arrives.
Thanks!