From: Matthew Wilcox <matthew@wil.cx>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Jiri Slaby <jirislaby@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-pm@lists.linux-foundation.org, drzeus@drzeus.cx,
linux-acpi@vger.kernel.org, Adam Belay <ambx1@neo.rr.com>,
Matthieu Castet <castet.matthieu@free.fr>,
Li Shaohua <shaohua.li@intel.com>, Len Brown <lenb@kernel.org>
Subject: Re: RFC: PNP: do not stop/start devices in suspend/resume path
Date: Wed, 5 Dec 2007 11:50:13 -0700 [thread overview]
Message-ID: <20071205185012.GA27526@parisc-linux.org> (raw)
In-Reply-To: <200712051124.18852.bjorn.helgaas@hp.com>
On Wed, Dec 05, 2007 at 11:24:18AM -0700, Bjorn Helgaas wrote:
> This means we will not disable the device and release its
> resources. The driver suspend method typically does not release
> its resources in the suspend path. For example, if we have:
>
> 03f8-03ff : 00:06
> 03f8-03ff : serial
>
> pnp_stop_dev() would release the 00:06 region, which still
> has a child. This causes a warning from __release_resource
> and corrupts /proc/ioports.
So, I put the warning in there because I genuinely didn't know if we
were doing this, and if so what the semantics should be.
I'm quite happy to see resources with children being released -- I just
want to know what we should do with those children. As the first person
to come across this problem, I think you get to decide the semantics.
It seems to me from this description that all we want to do is reparent
the children -- which is easy enough to do; just a matter of twizzling
all the ->parent pointers of the children; the ->sibling of the resource
before the one being released and the ->sibling of the last child of the
one being released.
If you think it's a genuine bug that happens to have been caught by this
check, I'm happy to see the check being useful, and we don't need to
allow the removal of resources.
The only thing is, if you're going to be re-acquiring these resources
upon resume, you'll need to use insert_resource() instead of
request_region() because the child will now be in that spot.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2007-12-05 18:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-22 21:41 WARNING: at kernel/resource.c:189 __release_resource Jiri Slaby
2007-11-27 6:05 ` Andrew Morton
2007-11-27 12:38 ` Matthew Wilcox
2007-11-29 23:40 ` Bjorn Helgaas
2007-11-30 0:42 ` Andrew Morton
2007-11-30 21:08 ` Bjorn Helgaas
2007-11-30 22:49 ` Jiri Slaby
2007-11-30 22:58 ` Bjorn Helgaas
2007-12-01 8:12 ` Jiri Slaby
2007-12-01 12:00 ` Jiri Slaby
2007-12-05 18:24 ` RFC: PNP: do not stop/start devices in suspend/resume path Bjorn Helgaas
2007-12-05 18:50 ` Matthew Wilcox [this message]
2007-12-06 1:07 ` Rafael J. Wysocki
2007-12-06 23:25 ` Bjorn Helgaas
2007-12-12 8:16 ` Andrew Morton
2007-12-12 16:29 ` Bjorn Helgaas
2007-12-13 8:26 ` Pierre Ossman
2007-12-07 7:13 ` RFC: " Shaohua Li
2007-12-10 23:26 ` Bjorn Helgaas
2007-12-24 1:43 ` do not stop/start devices in suspend/resume path: the SCSI case Stephane Ascoet
2007-12-24 3:21 ` Bjorn Helgaas
2007-12-01 21:01 ` WARNING: at kernel/resource.c:189 __release_resource Pierre Ossman
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=20071205185012.GA27526@parisc-linux.org \
--to=matthew@wil.cx \
--cc=akpm@linux-foundation.org \
--cc=ambx1@neo.rr.com \
--cc=bjorn.helgaas@hp.com \
--cc=castet.matthieu@free.fr \
--cc=drzeus@drzeus.cx \
--cc=jirislaby@gmail.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=shaohua.li@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).