Re: [PATCH] USB: Only enable autosuspend by default on certain device classes

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

 



On Fri, 3 Aug 2007, Matthew Garrett wrote:

> This patch is exactly that - a way of getting most of the benefits of 
> autosuspend without any real probability of breaking hardware. If you 
> mean "Are the distributions willing to pop up dialogs asking users to 
> start caring about obscure aspects of the USB spec", then I don't think 
> that's actually making things better.

Quite aside from issues involving desktop ease-of-use and distribution 
intentions, there is a technical matter to consider.  With the default 
autosuspend timeout set to 2 seconds, as it is now, it can often happen 
that userspace isn't able to respond in time to prevent a device from 
being suspended.  At bootup especially, the system is so busy running 
lots of tasks that response to a newly-detected device can be delayed 
for tens of seconds.  Even loading the device driver's module can take 
so long that the device gets autosuspended first.

There are two possible solutions, both involving the kernel (since
userspace can't respond in time).  One is to change the default timeout
to something larger, or even disable it completely.  Then people would
need to rely on userspace tools to enable autosuspend on known-good
devices.  The other possibility is to have a fairly reliable blacklist
or whitelist and again rely on userspace to manage edge cases.  This is 
of course more flexible than a blanket default setting, but it's still 
pretty rigid.  On the other hand, a blacklist can't be changed without 
rebuilding the kernel whereas the default timeout can be adjusted on 
the boot command line.

I don't know what the "best" approach is, but I can't see any
alternative to these two.  Furthermore, whatever approach we settle on
_has_ to be able to handle devices which simply die upon being 
suspended.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux