On Fri, 18 Jan 2013, Sarah Sharp wrote: > On Fri, Jan 18, 2013 at 02:09:26PM -0500, Alan Stern wrote: > > On Fri, 18 Jan 2013, Sarah Sharp wrote: > > > > > Hi Alan, > > > > > > What's the current state of USB mass storage suspend? I know there was > > > some purposed changes to the SCSI or block layer that would have > > > effected suspend, and I wondered if those made it in. > > > > The block-layer autosuspend patches are in pretty good shape. I > > haven't heard any objections to them recently from James Bottomley or > > Jens Axboe, so maybe they'll be accepted soon. > > Can you remind me how those patches will change the current auto-suspend > behavior? Currently the sd driver disables autosuspend whenever the disk device file is open. With these patches, sd enables autosuspend all the time. The suspend timer is reset whenever a SCSI command completes, and suspend attempts fail with -EBUSY whenever the request queue is non-empty. Adding a non-PM request to the request queue causes an autoresume. > > Don't forget that autosuspend for mass storage is available right now, > > in 3.7 and earlier kernels. It affects only disks whose device file > > isn't open (hence no mounted filesystems on the disk), and it has to be > > enabled by userspace (write "auto" to power/control for the SCSI disk > > device and its ancestors). > > Ok, just to verify, say I have this tree: > > sarah@xanatos:~$ lsusb -t > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M > |__ Port 2: Dev 2, If 0, Class=stor., Driver=usb-storage, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M > |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/4p, 12M > |__ Port 2: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M > |__ Port 2: Dev 3, If 1, Class=HID, Driver=usbhid, 1.5M > |__ Port 3: Dev 4, If 0, Class=HID, Driver=usbhid, 1.5M > |__ Port 3: Dev 4, If 1, Class=HID, Driver=usbhid, 1.5M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M > |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/3p, 480M > |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M > |__ Port 6: Dev 3, If 0, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M > |__ Port 6: Dev 3, If 1, Class='bInterfaceClass 0x0e not yet handled', Driver=uvcvideo, 480M > > If I want the usb-storage device to suspend, I would have to run: > > root@xanatos:/sys/bus/usb/devices/4-2/power# echo auto > control > root@xanatos:/sys/bus/usb/devices/4-2/power# echo 100 > autosuspend_delay_ms > > Auto-suspend is already enabled for the roothub. I unmounted the > filesystem on the SD card, and then waited for the port to go into U3. > That never happened, although I could see the port transition into other > link power states like U2. > > I'm not sure why the device isn't going into U3. I have > CONFIG_USB_SUSPEND turned on for this kernel. You have to do more than this; you have to enable autosuspend for the SCSI disk device. For example: I plug in a flash drive: [ 5532.627071] usb 1-8: new high-speed USB device number 2 using ehci_hcd [ 5532.742479] usb 1-8: New USB device found, idVendor=1307, idProduct=0165 [ 5532.742487] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 5532.742492] usb 1-8: Product: USB Mass Storage Device [ 5532.742496] usb 1-8: Manufacturer: USBest Technology [ 5532.742499] usb 1-8: SerialNumber: 00000000000126 [ 5532.844096] Initializing USB Mass Storage driver... [ 5532.844359] scsi2 : usb-storage 1-8:1.0 [ 5532.846403] usbcore: registered new interface driver usb-storage [ 5532.846412] USB Mass Storage support registered. [ 5532.847047] scsi 2:0:0:0: Direct-Access Ut165 USB2FlashStorage 0.00 PQ: 0 ANSI: 2 [ 5532.849155] sd 2:0:0:0: Attached scsi generic sg3 type 0 [ 5532.850757] sd 2:0:0:0: [sdc] 7892040 512-byte logical blocks: (4.04 GB/3.76 GiB) [ 5532.851516] sd 2:0:0:0: [sdc] Write Protect is off [ 5532.851527] sd 2:0:0:0: [sdc] Mode Sense: 00 00 00 00 [ 5532.852318] sd 2:0:0:0: [sdc] Asking for cache data failed [ 5532.852326] sd 2:0:0:0: [sdc] Assuming drive cache: write through [ 5532.857345] sd 2:0:0:0: [sdc] Asking for cache data failed [ 5532.857355] sd 2:0:0:0: [sdc] Assuming drive cache: write through [ 5532.986172] sdc: sdc1 [ 5532.989198] sd 2:0:0:0: [sdc] Asking for cache data failed [ 5532.989207] sd 2:0:0:0: [sdc] Assuming drive cache: write through [ 5532.989213] sd 2:0:0:0: [sdc] Attached SCSI removable disk No autosuspend. echo auto >/sys/bus/usb/devices/1-8/power/control. No autosuspend. echo auto >/sys/class/block/sdc/../../power/control. Still no autosuspend. echo 0 >/sys/class/block/sdc/events_poll_msecs (disable polling for media changes). After 2 seconds, the device autosuspends. > > The autosuspend delay at the USB level probably should be set to 0; > > then the autosuspend delay at the SCSI disk level will control the > > actual power changes. > > Is there a way to get at the auto-suspend delay at the SCSI disk level > through sysfs? Of course you can change it via sysfs. In my case, the path is /sys/class/block/sdc/../../power/autosuspend_delay_ms. Or if you want to expand that in full: /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0/host2/target2:0:0/2:0:0:0/power/autosuspend_delay_ms > What's the default timeout? Currently the SCSI stack doesn't use idle timeouts; it suspends as soon as the device file is closed. As for the new scheme... Hmmm, apparently the timeout never gets set anywhere. That's a bug in the patch set. > Isn't there a sysfs file to control the polling rate for removable > media? I don't remember where is it though. (I seem to ask about mass > storage suspend approximately once a year, and the state gets swapped > out in that time. :) Yes, there is such a file. See above. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
