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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 27 Jul 2009 11:09:58 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	list@...k.ath.cx
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Oliver Neukum <oliver@...kum.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>
Subject: Re: [Bug #13624] usb: wrong autosuspend initialization

On Mon, 27 Jul 2009 list@...k.ath.cx wrote:

> Alan Stern wrote:
> > On Sun, 26 Jul 2009, Rafael J. Wysocki wrote:
> > 
> >> This message has been generated automatically as a part of a report
> >> of regressions introduced between 2.6.29 and 2.6.30.
> >>
> >> The following bug entry is on the current list of known regressions
> >> introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> >> be listed and let me know (either way).
> >>
> >>
> >> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13624
> >> Subject		: usb: wrong autosuspend initialization
> >> Submitter	:  <list@...k.ath.cx>
> >> Date		: 2009-06-25 18:18 (32 days old)
> > 
> > There's some question as to whether this should be considered a kernel 
> > bug.  The kernel isn't doing anything wrong; the problem is that 
> > various userspace programs enable autosuspend for devices that can't 
> > support it properly.
> > 
> > Alan Stern
> > 
> 
> I'm currently working on a patch for laptop_mode. The maintainer tells 
> me there's work going on in the kernel to blacklist USB devices that 
> don't implement autosuspend correctly (like mice turning their light 
> off, etc...). Is that true?

No, it isn't.  The kernel has no way to tell whether mice behave that
way or not.

The only suspend-related blacklisting in the kernel is concerned with
broken devices that can't be resumed after they have been suspended.  
The kernel has to reset these devices instead of resuming them.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ