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.0912071403520.3560@localhost.localdomain>
Date:	Mon, 7 Dec 2009 14:06:59 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan Stern <stern@...land.harvard.edu>
cc:	Zhang Rui <rui.zhang@...el.com>, "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>
Subject: Re: [GIT PULL] PM updates for 2.6.33

On Mon, 7 Dec 2009, Alan Stern wrote:
> > 
> > Make the USB host controller do its suspend asynchronously. We don't 
> > suspend PCI bridges anyway, iirc (but I didn't actually check). And at 
> > worst, we can make the PCI _bridges_ know about async suspends, and solve 
> > it that way - without actually making any normal PCI drivers do it.
> 
> This sounds suspiciously like pushing the problem up a level and 
> hoping it will go away.  (Sometimes that even works.)

The "we don't suspend bridges anyway" is definitely a "hoping it will go 
away" issue. I think we did suspend bridges for a short while during the 
PM switch-over some time ago, and it worked most of the time, and then on 
some machines it just didn't work at all. Probably because ACPI ends up 
touching registers behind bridges that we closed down etc.

So PCI bridges are kind of special. Right now we don't touch them, and if 
we ever do, that will be another issue.

> In the end it isn't a very big issue.  Using one vs. two passes in 
> dpm_suspend() is pretty unimportant.

I also suspect that even if you do the USB host controller suspend 
synchronously, doing the actual USB devices asynchronously would still 
help - even if it's only "asynchronously per bus" thing. 

So in fact, it's probably a good first step to start off doing only the 
USB devices, not the controller.

		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/