Re: 2.6.23-rc6-mm1: failure to boot on HP nx6325, no sound when booted, USB-related WARNING

Linus Torvalds
2007-09-20T21:57:10Z

On Thu, 20 Sep 2007, Linus Torvalds wrote:
>
> (Btw, the above commit message points to just my response with a testing
> patch to the real email: the actual explanation of the INSANE ordering is
> from Len Brown in
>
> https://lists.linux-foundation.org/pipermail/linux-pm/2006-November/004161.html
>
> and there Len claims that we *must* wake up CPU's early).

..and points to commit 1a38416cea8ac801ae8f261074721f35317613dc which in
turn talks about http://bugzilla.kernel.org/show_bug.cgi?id=5651

Howerver, it seems that bugzilla entry may just be bogus. It talks about
"it appears that some firmware in the future may depend on that sequence
for correction operation"

Len, Shaohua, what are the real issues here?

It would indeed be nice if we could just take CPU's down early (while
everything is working), and run the whole suspend code with just one CPU,
rather than having to worry about the ordering between CPU and device
takedown.

That said, at least with STR, the situation is:

1) suspend_console
2) device_suspend(PMSG_SUSPEND) (== ->suspend)
3) disable_nonboot_cpus()
4) device_power_down(PMSG_SUSPEND) (== ->suspend_late)
5) pm_ops->enter()
6) device_power_up() (== ->resume_early)
7) enable_nonboot_cpus()
8) pm_finish()
9) device_resume() (== ->resume
10) resume_console

So if we agree that things like timers etc should *never* be suspended by
the early suspend, and *always* use "suspend_late/resume_early", then at
least STR should be ok.

And I think that's a damn reasonable thing to agree on: timers (and
anything else that CPU shutdown/bringup could *possibly* care about)
should be considered core enough that they had better be on the
suspend_late/resume_early list.

Thomas, Rafael, can you verify that at least STR is ok in this respect?

Linus