Hi All,
Please keep me CC-ed as I'm not subscribed.
Some time ago a mail about turning of the leds on usb pendrives once unmounted

by hal was send to the fedora-devel list:

https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01807.html
This mail talked about echo 2 > power/state for usb devices.
I tested the method described in the mail to turn of the drive light and it

worked well.
As I think that turning of the drive led (as windows does) would be good visual

feedback to the end user that its safe to remove the device I've written a

patch for hal which does the power state change automatically when the last

partition of a usb massstorage device gets unmounted.
However when testing the patch I found out that my now newer kernel no longer

has power/state for usb devices, it only has power/level. I can send suspend to

power/level, but then remounting the device won't work and me syslog fills

itself with:

sd 2:0:0:0: [sdc] READ CAPACITY failed

sd 2:0:0:0: [sdc] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK

sd 2:0:0:0: [sdc] Sense not available.

sd 2:0:0:0: [sdc] Write Protect is off

sd 2:0:0:0: [sdc] Mode Sense: 00 00 00 00

sd 2:0:0:0: [sdc] Assuming drive cache: write through
Because hal keeps polling the device.
So this leads me to a couple of questions:

1) Would it be possible to funtionality to the kernel to suspend a device in

    such a way that it will automatically unsuspend when used again?

2) Would it be possible to still make the polls succeed then with out

    unsuspending the device (or atleast without doing something that would make

    the led light again, what makes the led light exactly is unknown), or should

    hal stop polling then?
Note I'm aware that some usb devices may not like being suspended, but thats a

problem for later, if this cannot be made to work with devices which do handle

suspend properly, then thinking about white and/or blacklisting it irrelevant.
Regards,
Hans
-

What did power/state do, and can that capability be easily recovered?

Being able to turn off the lights is desirable, but it may be that

standby is the only way to do that, with all the issue already discussed

in this thread. But if there's another way, it would be useful.
--

Bill Davidsen <davidsen@tmr.com>

   "We have more to fear from the bungling of the incompetent than from

the machinations of the wicked."  - from Slashdot

-

(linux-usb-devel needs CC)
It is possible - USB now supports autosuspend. After a long debate, it was

however devcided that it is explicitly turned off, and userspace is free

to turn it on via sysfs interface for whatever devices the user likes to

do so.
This is mainly because there is a huge load of USB devices out there that

don't support this feature correctly, and we will break them if we perform 
How would you know how exactly respond to poll() that no userspace program

gets confused? There are many different kinds of USB devices.
--

Jiri Kosina

-

The correct answer is that HAL should top polling while the device is

suspended.
In kernels starting with 2.6.23-rc6, the correct way to enable

autosuspend for a USB device is basically like this:
	echo D >/sys/bus/usb/devices/.../power/autosuspend

	echo auto >/sys/bus/usb/devices/.../power/level
where D is the time (in seconds) the device should remain idle before

it is autosuspended.  An autosuspended device will be woken up to

respond to polls.  (Note however that in this kernel, autosuspend

support for USB mass-storage devices was removed because it can

cause problems related to spinning down disk drives.)
If instead you do
	echo suspend >/sys/bus/usb/devices/.../power/level
it will simply suspend the device immediately.  The device will not be

woken up automatically and attempts to poll it (or do anything else)

will fail.
Alan Stern
-

I'm afraid that that doesn't work for usb mass-storage devices.
Here is what I did:

1) kill hal

2) insert usb stick -> led lights

3):

echo -n 1 >    /sys/bus/usb/devices/.../power/autosuspend

echo -n auto > /sys/bus/usb/devices/.../power/level
4) wait
Nothing happens, where as sending "suspend" to power/level does turn the led

off. Now call me naive, but I would expect a mass-storage devices with no

partitions mounted to autosuspend when autosuspend is enabled for that device.
And yes I'm pretty sure nothing else is talking to the device.
As usual keep please me CC-ed as I'm not on the list.
Regards,
Hans

-

I don't know what went wrong.  It works fine on my systems.  You did

fill in the correct device path for the "...", right?  And you don't

need the "-n" -- adding it shouldn't matter, but you should try reading

back the contents of those files to make sure the values did get 
Yes, that is naive.  The driver has no way to tell whether or not any

partitions are mounted.  Furthermore, you might very well want to

access the raw device without mounting any partitions (database

managers frequently do such things to reduce I/O overhead), in which 
You can be absolutely certain by using usbmon (see

Documentation/usb/usbmon.txt).  It will also show whether any suspends

or resumes are actually being sent.
Alan Stern
-

Yes, the one that comes and goes as I plug in one of the USB-sticks I ue for 
How does this relate to your "It works fine on my systems" remark, do I need to

do anything other the unmounting the paritions to make the device eligible for

autosuspend, like unbind the sd driver or even the usb-storage driver?
If so I must say I find that a little counter intuitive.
Regards,
Hans
p.s.
As always, please keep me CC-ed, not on the list.
-

You shouldn't have to do anything.  Mounted or unmounted, bound to sd

or not bound, it shouldn't matter.  Provided the device isn't being

used, it ought to autosuspend.
I repeat: To find out what is really happening, you should use usbmon.
Alan Stern
-

<please use reply to all to keep me cc-ed, I'm not subscribed>
Thats not what I had in mind, autosuspend doesn't work (presumably because hal

keeps polling for media change) maybe I should fix hal to not keep polling for

devices which don't have removable media?
What one was able todo some time ago when there still was a power/state sysfs

entry for usb devices, was suspend the device without changing the autosuspend

state and then it would wake automatically when used again, I think it would be

easiest for hal to see this behaviour back.
Note I'm not saying that this behaviour should be brought back, currently I'm

mainly trying to find out what hal may / may not expect from the kernel with

regards to usb suspend in the future so that I can write a hal patch based on that.
Regards,
Hans
-

If you find a way to tell which devices fall into that class.
	Regards

		Oliver
-

Hi Hans,
I think the correct solution is that HAL stops polling the device as soon

as it sees that it got autosuspended.
--

Jiri Kosina

-

And how would we notice a medium change then? If there's an alternative

way to notice it or we know it cannot happen there's no reason to poll at all.
	Regards

		Oliver
-

It looks like hal is currently polling device of which it knows the medium is

not removable, like USB-pens.
Regards,
Hans
-

It doesn't, which is the point. The overwhelming number of USB devices

don't bother to correctly declare themselves not removable SCSI devices.

The discrimination will have to happen on a product:vendor basis, which

means that a large database has to be built and maintained.
	Regards

		Oliver

-