[PATCH 0/3] More updates for 2.6.25

[PATCH 0/3] More updates for 2.6.25

[Rafael J. Wysocki]

Len,

Please add the following three patches to the suspend branch.

Thanks,
Rafael

[PATCH 1/3] Suspend: Invoke suspend notifications after console switch

[Rafael J. Wysocki]

From: Johannes Berg <johannes@sipsolutions.net>

In order to fix APM emulation it is necessary to enable apm-emulation
notifications for suspends triggered in various ways via the suspend
notifiers.  However, this will cause the systems using APM emulation
to lock up between X being needed to switch away from the VT and X
already waiting for resume in the APM ioctl.

This patch moves the console switch (if enabled) before the suspend
notification (and after the resume notification) to avoid this issue.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 kernel/power/main.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6/kernel/power/main.c
===================================================================
--- linux-2.6.orig/kernel/power/main.c
+++ linux-2.6/kernel/power/main.c
@@ -173,12 +173,12 @@ static int suspend_prepare(void)
 	if (!suspend_ops || !suspend_ops->enter)
 		return -EPERM;
 
+	pm_prepare_console();
+
 	error = pm_notifier_call_chain(PM_SUSPEND_PREPARE);
 	if (error)
 		goto Finish;
 
-	pm_prepare_console();
-
 	if (suspend_freeze_processes()) {
 		error = -EAGAIN;
 		goto Thaw;
@@ -198,9 +198,9 @@ static int suspend_prepare(void)
 
  Thaw:
 	suspend_thaw_processes();
-	pm_restore_console();
  Finish:
 	pm_notifier_call_chain(PM_POST_SUSPEND);
+	pm_restore_console();
 	return error;
 }
 
@@ -307,8 +307,8 @@ int suspend_devices_and_enter(suspend_st
 static void suspend_finish(void)
 {
 	suspend_thaw_processes();
-	pm_restore_console();
 	pm_notifier_call_chain(PM_POST_SUSPEND);
+	pm_restore_console();
 }
 
 

[PATCH 1/3] Suspend: Invoke suspend notifications after console switch

[Rafael J. Wysocki]

From: Johannes Berg <johannes@sipsolutions.net>

In order to fix APM emulation it is necessary to enable apm-emulation
notifications for suspends triggered in various ways via the suspend
notifiers.  However, this will cause the systems using APM emulation
to lock up between X being needed to switch away from the VT and X
already waiting for resume in the APM ioctl.

This patch moves the console switch (if enabled) before the suspend
notification (and after the resume notification) to avoid this issue.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 kernel/power/main.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6/kernel/power/main.c
===================================================================
--- linux-2.6.orig/kernel/power/main.c
+++ linux-2.6/kernel/power/main.c
@@ -173,12 +173,12 @@ static int suspend_prepare(void)
 	if (!suspend_ops || !suspend_ops->enter)
 		return -EPERM;
 
+	pm_prepare_console();
+
 	error = pm_notifier_call_chain(PM_SUSPEND_PREPARE);
 	if (error)
 		goto Finish;
 
-	pm_prepare_console();
-
 	if (suspend_freeze_processes()) {
 		error = -EAGAIN;
 		goto Thaw;
@@ -198,9 +198,9 @@ static int suspend_prepare(void)
 
  Thaw:
 	suspend_thaw_processes();
-	pm_restore_console();
  Finish:
 	pm_notifier_call_chain(PM_POST_SUSPEND);
+	pm_restore_console();
 	return error;
 }
 
@@ -307,8 +307,8 @@ int suspend_devices_and_enter(suspend_st
 static void suspend_finish(void)
 {
 	suspend_thaw_processes();
-	pm_restore_console();
 	pm_notifier_call_chain(PM_POST_SUSPEND);
+	pm_restore_console();
 }
 
 

[PATCH 2/3] Hibernation: Invoke suspend notifications after console switch

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Following the recent change in the suspend code path, switch consoles before
calling PM notifiers during hibernation.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 kernel/power/disk.c |   17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

Index: linux-2.6/kernel/power/disk.c
===================================================================
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -458,20 +458,13 @@ static void power_down(void)
 	while(1);
 }
 
-static void unprepare_processes(void)
-{
-	thaw_processes();
-	pm_restore_console();
-}
-
 static int prepare_processes(void)
 {
 	int error = 0;
 
-	pm_prepare_console();
 	if (freeze_processes()) {
 		error = -EBUSY;
-		unprepare_processes();
+		thaw_processes();
 	}
 	return error;
 }
@@ -491,6 +484,7 @@ int hibernate(void)
 		goto Unlock;
 	}
 
+	pm_prepare_console();
 	error = pm_notifier_call_chain(PM_HIBERNATION_PREPARE);
 	if (error)
 		goto Exit;
@@ -530,11 +524,12 @@ int hibernate(void)
 		swsusp_free();
 	}
  Thaw:
-	unprepare_processes();
+	thaw_processes();
  Finish:
 	free_basic_memory_bitmaps();
  Exit:
 	pm_notifier_call_chain(PM_POST_HIBERNATION);
+	pm_restore_console();
 	atomic_inc(&snapshot_device_available);
  Unlock:
 	mutex_unlock(&pm_mutex);
@@ -603,6 +598,7 @@ static int software_resume(void)
 		goto Unlock;
 	}
 
+	pm_prepare_console();
 	error = pm_notifier_call_chain(PM_RESTORE_PREPARE);
 	if (error)
 		goto Finish;
@@ -626,11 +622,12 @@ static int software_resume(void)
 
 	printk(KERN_ERR "PM: Restore failed, recovering.\n");
 	swsusp_free();
-	unprepare_processes();
+	thaw_processes();
  Done:
 	free_basic_memory_bitmaps();
  Finish:
 	pm_notifier_call_chain(PM_POST_RESTORE);
+	pm_restore_console();
 	atomic_inc(&snapshot_device_available);
 	/* For success case, the suspend path will release the lock */
  Unlock:

[PATCH 2/3] Hibernation: Invoke suspend notifications after console switch

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>

Following the recent change in the suspend code path, switch consoles before
calling PM notifiers during hibernation.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 kernel/power/disk.c |   17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

Index: linux-2.6/kernel/power/disk.c
===================================================================
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -458,20 +458,13 @@ static void power_down(void)
 	while(1);
 }
 
-static void unprepare_processes(void)
-{
-	thaw_processes();
-	pm_restore_console();
-}
-
 static int prepare_processes(void)
 {
 	int error = 0;
 
-	pm_prepare_console();
 	if (freeze_processes()) {
 		error = -EBUSY;
-		unprepare_processes();
+		thaw_processes();
 	}
 	return error;
 }
@@ -491,6 +484,7 @@ int hibernate(void)
 		goto Unlock;
 	}
 
+	pm_prepare_console();
 	error = pm_notifier_call_chain(PM_HIBERNATION_PREPARE);
 	if (error)
 		goto Exit;
@@ -530,11 +524,12 @@ int hibernate(void)
 		swsusp_free();
 	}
  Thaw:
-	unprepare_processes();
+	thaw_processes();
  Finish:
 	free_basic_memory_bitmaps();
  Exit:
 	pm_notifier_call_chain(PM_POST_HIBERNATION);
+	pm_restore_console();
 	atomic_inc(&snapshot_device_available);
  Unlock:
 	mutex_unlock(&pm_mutex);
@@ -603,6 +598,7 @@ static int software_resume(void)
 		goto Unlock;
 	}
 
+	pm_prepare_console();
 	error = pm_notifier_call_chain(PM_RESTORE_PREPARE);
 	if (error)
 		goto Finish;
@@ -626,11 +622,12 @@ static int software_resume(void)
 
 	printk(KERN_ERR "PM: Restore failed, recovering.\n");
 	swsusp_free();
-	unprepare_processes();
+	thaw_processes();
  Done:
 	free_basic_memory_bitmaps();
  Finish:
 	pm_notifier_call_chain(PM_POST_RESTORE);
+	pm_restore_console();
 	atomic_inc(&snapshot_device_available);
 	/* For success case, the suspend path will release the lock */
  Unlock:

[PATCH 3/3] PM: Remove obsolete /sys/devices/.../power/state docs

[Rafael J. Wysocki]

From: David Brownell <david-b@pacbell.net>

The /sys/devices/.../power/state files have been gone for a while
now, but I just noticed some documentation that still refers to
them.  (Fortunately described as DEPRECATED and WILL REMOVE).

Time to remove that obsolete documentation too ...

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---

 Documentation/power/devices.txt |   49 ----------------------------------------
 1 file changed, 49 deletions(-)

Index: linux-2.6/Documentation/power/devices.txt
===================================================================
--- linux-2.6.orig/Documentation/power/devices.txt
+++ linux-2.6/Documentation/power/devices.txt
@@ -502,52 +502,3 @@ If the CPU can have a "cpufreq" driver, 
 to shift to lower voltage settings and reduce the power cost of executing
 a given number of instructions.  (Without voltage adjustment, it's rare
 for cpufreq to save much power; the cost-per-instruction must go down.)
-
-
-/sys/devices/.../power/state files
-==================================
-For now you can also test some of this functionality using sysfs.
-
-	DEPRECATED:  USE "power/state" ONLY FOR DRIVER TESTING, AND
-	AVOID USING dev->power.power_state IN DRIVERS.
-
-	THESE WILL BE REMOVED.  IF THE "power/state" FILE GETS REPLACED,
-	IT WILL BECOME SOMETHING COUPLED TO THE BUS OR DRIVER.
-
-In each device's directory, there is a 'power' directory, which contains
-at least a 'state' file.  The value of this field is effectively boolean,
-PM_EVENT_ON or PM_EVENT_SUSPEND.
-
-   *	Reading from this file displays a value corresponding to
-	the power.power_state.event field.  All nonzero values are
-	displayed as "2", corresponding to a low power state; zero
-	is displayed as "0", corresponding to normal operation.
-
-   *	Writing to this file initiates a transition using the
-   	specified event code number; only '0', '2', and '3' are
-	accepted (without a newline); '2' and '3' are both
-	mapped to PM_EVENT_SUSPEND.
-
-On writes, the PM core relies on that recorded event code and the device/bus
-capabilities to determine whether it uses a partial suspend() or resume()
-sequence to change things so that the recorded event corresponds to the
-numeric parameter.
-
-   -	If the bus requires the irqs-disabled suspend_late()/resume_early()
-	phases, writes fail because those operations are not supported here.
-
-   -	If the recorded value is the expected value, nothing is done.
-
-   -	If the recorded value is nonzero, the device is partially resumed,
-	using the bus.resume() and/or class.resume() methods.
-
-   -	If the target value is nonzero, the device is partially suspended,
-	using the class.suspend() and/or bus.suspend() methods and the
-	PM_EVENT_SUSPEND message.
-
-Drivers have no way to tell whether their suspend() and resume() calls
-have come through the sysfs power/state file or as part of entering a
-system sleep state, except that when accessed through sysfs the normal
-parent/child sequencing rules are ignored.  Drivers (such as bus, bridge,
-or hub drivers) which expose child devices may need to enforce those rules
-on their own.

[PATCH 3/3] PM: Remove obsolete /sys/devices/.../power/state docs

[Rafael J. Wysocki]

From: David Brownell <david-b@pacbell.net>

The /sys/devices/.../power/state files have been gone for a while
now, but I just noticed some documentation that still refers to
them.  (Fortunately described as DEPRECATED and WILL REMOVE).

Time to remove that obsolete documentation too ...

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---

 Documentation/power/devices.txt |   49 ----------------------------------------
 1 file changed, 49 deletions(-)

Index: linux-2.6/Documentation/power/devices.txt
===================================================================
--- linux-2.6.orig/Documentation/power/devices.txt
+++ linux-2.6/Documentation/power/devices.txt
@@ -502,52 +502,3 @@ If the CPU can have a "cpufreq" driver, 
 to shift to lower voltage settings and reduce the power cost of executing
 a given number of instructions.  (Without voltage adjustment, it's rare
 for cpufreq to save much power; the cost-per-instruction must go down.)
-
-
-/sys/devices/.../power/state files
-==================================
-For now you can also test some of this functionality using sysfs.
-
-	DEPRECATED:  USE "power/state" ONLY FOR DRIVER TESTING, AND
-	AVOID USING dev->power.power_state IN DRIVERS.
-
-	THESE WILL BE REMOVED.  IF THE "power/state" FILE GETS REPLACED,
-	IT WILL BECOME SOMETHING COUPLED TO THE BUS OR DRIVER.
-
-In each device's directory, there is a 'power' directory, which contains
-at least a 'state' file.  The value of this field is effectively boolean,
-PM_EVENT_ON or PM_EVENT_SUSPEND.
-
-   *	Reading from this file displays a value corresponding to
-	the power.power_state.event field.  All nonzero values are
-	displayed as "2", corresponding to a low power state; zero
-	is displayed as "0", corresponding to normal operation.
-
-   *	Writing to this file initiates a transition using the
-   	specified event code number; only '0', '2', and '3' are
-	accepted (without a newline); '2' and '3' are both
-	mapped to PM_EVENT_SUSPEND.
-
-On writes, the PM core relies on that recorded event code and the device/bus
-capabilities to determine whether it uses a partial suspend() or resume()
-sequence to change things so that the recorded event corresponds to the
-numeric parameter.
-
-   -	If the bus requires the irqs-disabled suspend_late()/resume_early()
-	phases, writes fail because those operations are not supported here.
-
-   -	If the recorded value is the expected value, nothing is done.
-
-   -	If the recorded value is nonzero, the device is partially resumed,
-	using the bus.resume() and/or class.resume() methods.
-
-   -	If the target value is nonzero, the device is partially suspended,
-	using the class.suspend() and/or bus.suspend() methods and the
-	PM_EVENT_SUSPEND message.
-
-Drivers have no way to tell whether their suspend() and resume() calls
-have come through the sysfs power/state file or as part of entering a
-system sleep state, except that when accessed through sysfs the normal
-parent/child sequencing rules are ignored.  Drivers (such as bus, bridge,
-or hub drivers) which expose child devices may need to enforce those rules
-on their own.

Re: [PATCH 0/3] More updates for 2.6.25

[Len Brown]

On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> Len,
> 
> Please add the following three patches to the suspend branch.

Applied (and suspend branch has been re-based to latest linus tree)

thanks,
-Len

Re: [PATCH 0/3] More updates for 2.6.25

[Pavel Machek]

On Tue 2008-01-15 23:22:33, Len Brown wrote:
> On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> > Len,
> > 
> > Please add the following three patches to the suspend branch.
> 
> Applied (and suspend branch has been re-based to latest linus tree)

Was that "lets reorder notifications, old order was more logical, but
it fixes apm?" series?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 0/3] More updates for 2.6.25

[Rafael J. Wysocki]

On Wednesday, 16 of January 2008, Pavel Machek wrote:
> On Tue 2008-01-15 23:22:33, Len Brown wrote:
> > On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> > > Len,
> > > 
> > > Please add the following three patches to the suspend branch.
> > 
> > Applied (and suspend branch has been re-based to latest linus tree)
> 
> Was that "lets reorder notifications, old order was more logical, but
> it fixes apm?" series?

Yes, plus the docs update from Dave Brownell.

Greetings,
Rafael

Re: [PATCH 0/3] More updates for 2.6.25

[Rafael J. Wysocki]

On Wednesday, 16 of January 2008, Pavel Machek wrote:
> On Tue 2008-01-15 23:22:33, Len Brown wrote:
> > On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> > > Len,
> > > 
> > > Please add the following three patches to the suspend branch.
> > 
> > Applied (and suspend branch has been re-based to latest linus tree)
> 
> Was that "lets reorder notifications, old order was more logical, but
> it fixes apm?" series?

Yes, plus the docs update from Dave Brownell.

Greetings,
Rafael

Re: [PATCH 0/3] More updates for 2.6.25

[Pavel Machek]

On Wed 2008-01-16 13:37:18, Rafael J. Wysocki wrote:
> On Wednesday, 16 of January 2008, Pavel Machek wrote:
> > On Tue 2008-01-15 23:22:33, Len Brown wrote:
> > > On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> > > > Len,
> > > > 
> > > > Please add the following three patches to the suspend branch.
> > > 
> > > Applied (and suspend branch has been re-based to latest linus tree)
> > 
> > Was that "lets reorder notifications, old order was more logical, but
> > it fixes apm?" series?
> 
> Yes, plus the docs update from Dave Brownell.

Can we stop that reordering? I do not think it is such a good idea.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 0/3] More updates for 2.6.25

[Rafael J. Wysocki]

On Wednesday, 23 of January 2008, Pavel Machek wrote:
> On Wed 2008-01-16 13:37:18, Rafael J. Wysocki wrote:
> > On Wednesday, 16 of January 2008, Pavel Machek wrote:
> > > On Tue 2008-01-15 23:22:33, Len Brown wrote:
> > > > On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> > > > > Len,
> > > > > 
> > > > > Please add the following three patches to the suspend branch.
> > > > 
> > > > Applied (and suspend branch has been re-based to latest linus tree)
> > > 
> > > Was that "lets reorder notifications, old order was more logical, but
> > > it fixes apm?" series?
> > 
> > Yes, plus the docs update from Dave Brownell.
> 
> Can we stop that reordering? I do not think it is such a good idea.

In this particular case it's needed to unbreak the APM emulation and it
certainly is not a good idea to have two different orderings of the notifiers
vs the freezer (hence the second patch in the series).

Thanks,
Rafael

Re: [PATCH 0/3] More updates for 2.6.25

[Rafael J. Wysocki]

On Wednesday, 23 of January 2008, Pavel Machek wrote:
> On Wed 2008-01-16 13:37:18, Rafael J. Wysocki wrote:
> > On Wednesday, 16 of January 2008, Pavel Machek wrote:
> > > On Tue 2008-01-15 23:22:33, Len Brown wrote:
> > > > On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> > > > > Len,
> > > > > 
> > > > > Please add the following three patches to the suspend branch.
> > > > 
> > > > Applied (and suspend branch has been re-based to latest linus tree)
> > > 
> > > Was that "lets reorder notifications, old order was more logical, but
> > > it fixes apm?" series?
> > 
> > Yes, plus the docs update from Dave Brownell.
> 
> Can we stop that reordering? I do not think it is such a good idea.

In this particular case it's needed to unbreak the APM emulation and it
certainly is not a good idea to have two different orderings of the notifiers
vs the freezer (hence the second patch in the series).

Thanks,
Rafael

Re: [PATCH 0/3] More updates for 2.6.25

[Rafael J. Wysocki]

On Wednesday, 23 of January 2008, Rafael J. Wysocki wrote:
> On Wednesday, 23 of January 2008, Pavel Machek wrote:
> > On Wed 2008-01-16 13:37:18, Rafael J. Wysocki wrote:
> > > On Wednesday, 16 of January 2008, Pavel Machek wrote:
> > > > On Tue 2008-01-15 23:22:33, Len Brown wrote:
> > > > > On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> > > > > > Len,
> > > > > > 
> > > > > > Please add the following three patches to the suspend branch.
> > > > > 
> > > > > Applied (and suspend branch has been re-based to latest linus tree)
> > > > 
> > > > Was that "lets reorder notifications, old order was more logical, but
> > > > it fixes apm?" series?
> > > 
> > > Yes, plus the docs update from Dave Brownell.
> > 
> > Can we stop that reordering? I do not think it is such a good idea.
> 
> In this particular case it's needed to unbreak the APM emulation and it
> certainly is not a good idea to have two different orderings of the notifiers
> vs the freezer

Sorry, s/notifiers vs the freezer/console switch vs the notifiers/

> (hence the second patch in the series).

Re: [PATCH 0/3] More updates for 2.6.25

[Rafael J. Wysocki]

On Wednesday, 23 of January 2008, Rafael J. Wysocki wrote:
> On Wednesday, 23 of January 2008, Pavel Machek wrote:
> > On Wed 2008-01-16 13:37:18, Rafael J. Wysocki wrote:
> > > On Wednesday, 16 of January 2008, Pavel Machek wrote:
> > > > On Tue 2008-01-15 23:22:33, Len Brown wrote:
> > > > > On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> > > > > > Len,
> > > > > > 
> > > > > > Please add the following three patches to the suspend branch.
> > > > > 
> > > > > Applied (and suspend branch has been re-based to latest linus tree)
> > > > 
> > > > Was that "lets reorder notifications, old order was more logical, but
> > > > it fixes apm?" series?
> > > 
> > > Yes, plus the docs update from Dave Brownell.
> > 
> > Can we stop that reordering? I do not think it is such a good idea.
> 
> In this particular case it's needed to unbreak the APM emulation and it
> certainly is not a good idea to have two different orderings of the notifiers
> vs the freezer

Sorry, s/notifiers vs the freezer/console switch vs the notifiers/

> (hence the second patch in the series).

Re: [PATCH 0/3] More updates for 2.6.25

[Pavel Machek]

On Wed 2008-01-16 13:37:18, Rafael J. Wysocki wrote:
> On Wednesday, 16 of January 2008, Pavel Machek wrote:
> > On Tue 2008-01-15 23:22:33, Len Brown wrote:
> > > On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> > > > Len,
> > > > 
> > > > Please add the following three patches to the suspend branch.
> > > 
> > > Applied (and suspend branch has been re-based to latest linus tree)
> > 
> > Was that "lets reorder notifications, old order was more logical, but
> > it fixes apm?" series?
> 
> Yes, plus the docs update from Dave Brownell.

Can we stop that reordering? I do not think it is such a good idea.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 0/3] More updates for 2.6.25

[Pavel Machek]

On Tue 2008-01-15 23:22:33, Len Brown wrote:
> On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> > Len,
> > 
> > Please add the following three patches to the suspend branch.
> 
> Applied (and suspend branch has been re-based to latest linus tree)

Was that "lets reorder notifications, old order was more logical, but
it fixes apm?" series?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 0/3] More updates for 2.6.25

[Len Brown]

On Thursday 10 January 2008 19:18, Rafael J. Wysocki wrote:
> Len,
> 
> Please add the following three patches to the suspend branch.

Applied (and suspend branch has been re-based to latest linus tree)

thanks,
-Len

[PATCH 0/3] More updates for 2.6.25

[Rafael J. Wysocki]

Len,

Please add the following three patches to the suspend branch.

Thanks,
Rafael