Re: [rfc/rft]power management for btusb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 20 Aug 2008, Marcel Holtmann wrote:

> Hi Alan,
> 
> > > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux