linux-kernel - Re: [GIT PULL] PM updates for 2.6.33

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]

Message-ID: <alpine.LFD.2.00.0912062204431.3560@localhost.localdomain>
Date:	Sun, 6 Dec 2009 22:15:26 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Zhang Rui <rui.zhang@...el.com>
cc:	Alan Stern <stern@...land.harvard.edu>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [GIT PULL] PM updates for 2.6.33

On Sun, 6 Dec 2009, Linus Torvalds wrote:
> 
> And drivers that want to do things asynchronously don't need to register 
> or worry: all they do is literally [...]

Side note: for specific bus implementations, you obviously don't have to 
even expose the choice. Things like the whole "suspend_late" and 
"resume_early" phases don't make sense for USB devices, and the USB core 
layer don't even expose those to the various USB drivers.

The same is true of the prepare_suspend/suspend split I'm proposing: I 
suspect that for something like USB, it would make most sense to just do 
normal node suspend in prepare_suspend, which would do everything 
asynchronously. Only USB hub devices would get involved at the later 
'suspend()' phase.

So I'm not suggesting that "all drivers" would necessarily even need 
changing in order to take advantage of asynchronous behavior.

You could change just the _core_ USB layer would do everything 
automatically for USB devices, and now USB devices would automatically 
suspend asynchronously not because the generic device layer knows about 
it, but because the USB bus layer chose to do that "async_run()" on the 
leaf node suspend functions (or rather: a helper function that calls the 
leaf-node suspend, and then does the 'up_read()' call on the parent 
lock: the actual usb driverrs would never know about any of this).

				Linus
--
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/