Thread (22 messages) flat view 22 messages, 4 authors, 2008-08-20

Re: [rfc/rft]power management for btusb

From: Alan Stern <stern@rowland.harvard.edu>
Date: 2008-08-20 15:55:23

On Wed, 20 Aug 2008, Marcel Holtmann wrote:
Hi Alan,
quoted
quoted
finally I found the device and setting it to auto makes it actually
suspend. Why is this not default? The driver has to enable it anyway.
If there's no driver then it would take effect right away.  This causes 
problems for devices during startup -- the period of time from device 
discovery to driver binding is long enough (because there's so much 
other activity during bootup) that the device can autosuspend before 
the driver is there to prevent it.

For well-behaved devices this wouldn't matter.  But unfortunately there 
are lots of devices which break when they suspend.  That's why 
level = auto is not the default.
is there any way to make it default if we know it works all the time?
No, probably not.  But in general we don't know that.  And we do know
that a fair number of devices really are broken in this way -- lots of
printers or scanners have this problem.  Too many for us to want to
keep a blacklist in the kernel, as Oliver mentioned.

The idea is that some desktop management program, like hal, should be 
able to recognize which devices can autosuspend safely and then enable 
them.  That way the whole problem is pushed out to userspace.  :-)

There is one exception: The kernel enables autosuspend automatically 
for hubs.

Alan Stern
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help