From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Linux-pm mailing list <linux-pm@lists.linux-foundation.org>
Subject: Re: [RFC 2/2] PM: Lock all devices during suspend/hibernate
Date: Wed, 1 Aug 2007 00:20:46 +0200 [thread overview]
Message-ID: <200708010020.47144.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0707311648530.4896-100000@iolanthe.rowland.org>
On Tuesday, 31 July 2007 22:51, Alan Stern wrote:
> This patch adds an extra step to the device suspend/resume procedures,
> in which every device is locked/unlocked. In addition, a new global
> rwsem prevents additional devices from being registered at these times.
>
> Alan Stern
>
>
> Index: usb-2.6/drivers/base/power/main.c
> ===================================================================
> --- usb-2.6.orig/drivers/base/power/main.c
> +++ usb-2.6/drivers/base/power/main.c
> @@ -24,17 +24,38 @@
> #include <linux/mutex.h>
> #include <linux/pm.h>
> #include <linux/resume-trace.h>
> +#include <linux/rwsem.h>
>
> #include "../base.h"
> #include "power.h"
>
> +/*
> + * The entries in the dpm_active list are in a depth first order, simply
> + * because children are guaranteed to be discovered after parents, and
> + * are inserted at the back of the list on discovery.
> + *
> + * All the other lists are kept in the same order, for consistency.
> + * However the lists aren't always traversed in the same order.
> + * Semaphores must be acquired from the top (i.e., front) down
> + * and released in the opposite order. Devices must be suspended
> + * from the bottom (i.e., end) up and resumed in the opposite order.
> + * That way no parent will be suspended while it still has an active
> + * child.
> + *
> + * Since device_pm_add() may be called with a device semaphore held,
> + * we must never try to acquire a device semaphore while holding
> + * dpm_list_mutex.
> + */
> +
> LIST_HEAD(dpm_active);
> +static LIST_HEAD(dpm_locked);
> static LIST_HEAD(dpm_off);
> static LIST_HEAD(dpm_off_irq);
>
> -static DEFINE_MUTEX(dpm_mtx);
> static DEFINE_MUTEX(dpm_list_mtx);
>
> +static DECLARE_RWSEM(device_registration_rwsem);
Is it only intended for device registration, or can it be used in some other
code paths too?
> +
> int (*platform_enable_wakeup)(struct device *dev, int is_on);
>
>
> @@ -59,29 +80,112 @@ void device_pm_remove(struct device *dev
> pr_debug("PM: Removing info for %s:%s\n",
> dev->bus ? dev->bus->name : "No Bus",
> kobject_name(&dev->kobj));
> +
> + /* Don't remove a device while the PM core has it locked for suspend */
> + down(&dev->sem);
> mutex_lock(&dpm_list_mtx);
> dpm_sysfs_remove(dev);
> list_del_init(&dev->power.entry);
> mutex_unlock(&dpm_list_mtx);
> + up(&dev->sem);
> +}
> +
> +/**
> + * device_add_pm_lock - mutual exclusion for registration and suspend
> + *
> + * Returns 0 if no suspend is underway and device registration
> + * may proceed, otherwise -EBUSY.
> + */
> +int device_add_pm_lock(void)
> +{
> + if (down_read_trylock(&device_registration_rwsem))
> + return 0;
> + return -EBUSY;
> +}
I would do:
+ return down_read_trylock(&device_registration_rwsem) ? 0 : -EBUSY;
Apart from this, I have no comments. :-)
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
next prev parent reply other threads:[~2007-07-31 22:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-30 20:48 Suspend without the freezer Alan Stern
2007-07-31 3:52 ` Dmitry Torokhov
2007-07-31 9:05 ` Rafael J. Wysocki
2007-07-31 15:24 ` Alan Stern
2007-07-31 19:08 ` Rafael J. Wysocki
2007-07-31 20:48 ` [RFC 1/2] PM: merge drivers/base/power/{main, suspend, resume}.c Alan Stern
2007-07-31 22:15 ` Rafael J. Wysocki
2007-07-31 20:51 ` [RFC 2/2] PM: Lock all devices during suspend/hibernate Alan Stern
2007-07-31 22:20 ` Rafael J. Wysocki [this message]
2007-08-01 14:11 ` Alan Stern
2007-08-01 15:37 ` Rafael J. Wysocki
2007-08-01 17:58 ` Alan Stern
2007-08-01 18:59 ` Rafael J. Wysocki
2007-08-01 3:50 ` Re: Suspend without the freezer Paul Mackerras
2007-08-01 14:33 ` Alan Stern
2007-08-01 19:08 ` Rafael J. Wysocki
2007-08-01 20:16 ` Alan Stern
2007-07-31 14:58 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200708010020.47144.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-pm@lists.linux-foundation.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.