linux-kernel - Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0708022240250.1043-100000@netrider.rowland.org>
Date:	Thu, 2 Aug 2007 22:46:53 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Matthew Garrett <mjg59@...f.ucam.org>
cc:	Greg KH <gregkh@...e.de>, <linux-usb-devel@...ts.sourceforge.net>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default
 on certain device classes

On Fri, 3 Aug 2007, Matthew Garrett wrote:

> On Thu, Aug 02, 2007 at 06:15:05PM -0700, Greg KH wrote:
> 
> > Well, if you do this, then you can pretty much delete the whole quirk
> > table we have, right?
> 
> At the moment, yes.
> 
> > And personally, I want to do better than Windows XP when it comes to
> > power management.  This patch is only going to suspend a very tiny
> > subset of devices, including a whole bunch of ones that do not even have
> > drivers in Linux, causing our power footprint to be bigger than needed.
> 
> I agree. I'd much rather see us suspending devices whenever possible - 
> it's just that I have concerns over the scalability of the blacklist, 
> given the number of devices that seem to have issues.

While I agree in general, perhaps a different approach would work
better.  For instance, we could blacklist a few known-bad device
classes (maybe even using the existing blacklist) rather than
whitelisting a few known-good ones -- or trying to blacklist each 
member of the bad classes!

Also, building something this sweeping into a kernel driver feels like
a mistake.  It ought to be more easily configurable from userspace, say
via a sysfs file.  Although this wouldn't be so important if we take
the blacklist-classes route.

Alan Stern

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