Fwd: [linux-pm] [patch/rft 2.6.17-rc5-git 0/6] PM_EVENT_PRETHAW

[David Brownell]

Summary message below; see everything at these URLs, if interested:

[0] http://lists.osdl.org/pipermail/linux-pm/2006-June/002448.html
[1] http://lists.osdl.org/pipermail/linux-pm/2006-June/002444.html
[2] http://lists.osdl.org/pipermail/linux-pm/2006-June/002446.html
[3] http://lists.osdl.org/pipermail/linux-pm/2006-June/002447.html
[4] http://lists.osdl.org/pipermail/linux-pm/2006-June/002443.html
[5] http://lists.osdl.org/pipermail/linux-pm/2006-June/002445.html
[6] http://lists.osdl.org/pipermail/linux-pm/2006-June/002442.html

----------  Forwarded Message  ----------

Subject: [linux-pm] [patch/rft 2.6.17-rc5-git 0/6] PM_EVENT_PRETHAW
Date: Monday 05 June 2006 9:36 am
From: David Brownell <david-b@xxxxxxxxxxx>
To: linux-pm@xxxxxxxxxxxxxx

Following this message will be patches adding the new PRETHAW event,
so that drivers can make sure that swsusp doesn't put hardware into
bogus states before resuming.

As previously discussed, this is needed by drivers which examine the
hardware state during resume() methods ... notably, USB controller
drivers, which expect to see true suspend states in order to handle
remote wakeup, but currently break with swsusp.  Only two states are
valid in resume():  after hardware reset, or else the state that
suspend() left it in.  PRETHAW allows drivers to force the former.

In sequence, the patches are:

 - prethaw-misc.patch ... fixes code that's currently broken/dubious
   so that it won't care about the new message (and is thus more or
   less mergeable regardless of the rest of these patches)

 - prethaw-header.patch ... defines the new event and its message

 - prethaw-fw.patch ... IDE and (dumb) PCI can handle it simplistically

 - prethaw-video.patch ... likewise, but this is per-driver not at the
   framework level

 - prethaw-usb.patch ... fixing various "swsusp resume fails if the
   HCD is statically linked" bugs

 - prethaw-core.patch ... updating the pm core to issue PRETHAW
   events, handling for which which the previous patches added.

Yes, it might be worth splitting some of those driver patches out into
patch-per-driver format.  Yes, I _did_ look at a couple hundred drivers
(grr) to see what needed changing ... darn few drivers treat suspend() as
anything other than PM_EVENT_SUSPEND.

- Dave

_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxx
https://lists.osdl.org/mailman/listinfo/linux-pm


-------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/