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:	Fri, 9 Jan 2009 23:23:43 +0100
From:	Pavel Machek <pavel@...e.cz>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Frans Pop <elendil@...net.nl>, oliver@...kum.org,
	gregkh@...e.de, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	torvalds@...ux-foundation.org,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Len Brown <lenb@...nel.org>
Subject: Re: [Regression] USB wakeup problem on Toshiba Portege R500

On Fri 2009-01-09 18:53:41, Rafael J. Wysocki wrote:
> [CCing ACPI and Len)
> 
> On Friday 09 January 2009, Alan Stern wrote:
> > On Thu, 8 Jan 2009, Frans Pop wrote:
> > 
> > > Rafael J. Wysocki wrote:
> > > > On Thursday 08 January 2009, Oliver Neukum wrote:
> > > >> Am Thursday 08 January 2009 17:36:12 schrieb Rafael J. Wysocki:
> > > >> You are making a very persuasive argument for reverting it.
> > > >> But what about laptops that only have a USB keyboard?
> > > > 
> > > > Well, up to and including 2.6.28 they needed to echo 'enable' to the USB
> > > > controllers' /sys/devices/.../power/wakeup files, so if the patch is
> > > > reverted, they won't be worse off than they were day before
> > > > yesterday. :-) 
> > > > 
> > > > Perhaps we can choose the default depending on whether or not any HID
> > > > devices are attached to given controller?
> > > 
> > > Is "resume on keyboard activity" really all that needed? Both my laptops 
> > > and my desktop resume fine after pressing the power button.
> > > 
> > > Also consider the following cases:
> > > - laptop has been suspended with external USB mouse connected
> > >   - mouse is moved (accidentally or because it is in the way of a coffee
> > >     cup)
> > >   - mouse cable is removed before putting the laptop in a bag for
> > >     transport
> > > - laptop is in docking station with USB mouse/kbd connected to that
> > >   - again, mouse gets moved for some reason
> > >   - laptop is undocked while suspended
> > >   - or the reverse: laptop gets docked
> > > 
> > > IMO it is not desirable that the system gets resumed as a result of any of 
> > > those actions. I'm not complete sure that it would in all those cases, 
> > > but have they been considered?
> > > 
> > > And in general I've always been in favor of things only happening 
> > > automagically if I've explicitly asked for that, and not by default.
> > 
> > I don't mind reverting the "automatically enable PCI wakeup" commit.  But 
> > we should first come to a definite policy for kernel default wakeup 
> > settings, rather than deciding things piecemeal for different subsystems.
> > 
> > My proposal:
> > 
> > 	Devices and events that are clearly associated with system
> > 	wakeup should be enabled by default.  For example: Power
> > 	button and laptop lid.
> 
> Agreed.
> 
> > 	All other devices capable of waking up the system should be
> > 	disabled by default.  This presumably includes every PCI
> > 	device.  If users want keyboard or mouse events to cause
> > 	a system resume then they will have to configure their
> > 	desktop management program to enable it.
> 
> I generally agree, with one exception.  There are network adapters which
> can be enabled to wake up by the BIOS and their drivers set them up for WoL
> currently on this basis.  These should remain enabled IMO.

Agreed. WoL worked before and it should remain working.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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