From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: Re: Hotplug events during sleep transition
Date: Tue, 27 Dec 2005 16:51:47 -0500 [thread overview]
Message-ID: <d120d5000512271351s766ef783j6d32ea802f5ee3cd@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.50.0512271300560.4933-100000@monsoon.he.net>
On 12/27/05, Patrick Mochel <mochel@digitalimplant.org> wrote:
>
> On Mon, 26 Dec 2005, Dmitry Torokhov wrote:
>
> > On Monday 26 December 2005 16:20, Patrick Mochel wrote:
> > > > > Unbinding and
> > > > > rebinding do a whole lot more. A device does an entire round trip through
> > > > > the driver core, which does a lot of crap. There are several memory
> > > > > allocations, perhaps dozens of sysfs files created, and a handful of locks
> > > > > taken adn lists traversed.
> > > >
> > > > No, you're thinking of unregistering and re-registering a device or
> > > > driver. Unbinding and rebinding is much simpler, although still somewhat
> > > > complex.
> > >
> > > Ah, point taken; I was thinking that all USB devices were still
> > > disconnected during a suspend transition..
> > >
> >
> > Device removal could happen at any point, even during suspend transition.
> > The kernel should be able to handle this scenario therefore implementation
> > that assumes that device tree is frozen in flawed. As far as I understand
> > the only thing that does not work at the moment is invoking hotplug handler.
>
> I don't think that the tree should be assumed to be frozen. I just think
> that we should try to avoid doing a full add or remove of a device (or
> really, any object) while in a suspend or resume transition.
>
> During normal system operation, how does a USB device get removed? Does it
> happen via the USB hub thread? Forgive me for asking a question that's
> probably been asked countless times, but is this thread running during a
> suspend transition?
>
That's Greg/Alan question, I am ignorant here.
> Would it be possible to simply mark the device as 'removed' and ignore it
> until we resumed, and then clean it up (hotplug events and everything)?
>
Unfortunately swsusp resumes devices in the middle of suspend process
with everything frozen and drivers don't know if they may clean up or
have to postpone doing so. To do it uniformly you'd need to introduce
threads and offload cleanups. I doubt it is good idea to require each
subsystem to define cleanup thread or [ab]used keventd?
--
Dmitry
next prev parent reply other threads:[~2005-12-27 21:51 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-22 14:28 Hotplug events during sleep transition Alan Stern
2005-12-22 14:34 ` Pavel Machek
2005-12-22 18:20 ` Dmitry Torokhov
2005-12-22 20:52 ` Patrick Mochel
2005-12-22 20:56 ` Randy.Dunlap
2005-12-22 22:13 ` Alan Stern
2005-12-23 3:49 ` Patrick Mochel
2005-12-23 3:52 ` Dmitry Torokhov
2005-12-23 15:20 ` Alan Stern
2005-12-23 15:35 ` Patrick Mochel
2005-12-23 16:52 ` Alan Stern
2005-12-23 17:20 ` Pavel Machek
2005-12-23 21:22 ` Alan Stern
2005-12-23 21:28 ` Greg KH
2005-12-23 22:09 ` Nigel Cunningham
2005-12-23 22:31 ` Pavel Machek
2005-12-23 22:40 ` Nigel Cunningham
2005-12-23 22:48 ` Pavel Machek
2005-12-23 22:57 ` Nigel Cunningham
2005-12-24 0:29 ` Nigel Cunningham
2005-12-24 15:11 ` Alan Stern
2005-12-24 15:28 ` Pavel Machek
2005-12-24 17:02 ` Greg KH
2005-12-23 21:28 ` Pavel Machek
2005-12-23 19:40 ` Greg KH
2005-12-24 0:23 ` Patrick Mochel
2005-12-25 2:56 ` Alan Stern
2005-12-25 8:53 ` Pavel Machek
2005-12-25 16:43 ` Alan Stern
2005-12-25 16:52 ` Dmitry Torokhov
2005-12-25 19:54 ` Pavel Machek
2005-12-25 19:52 ` Pavel Machek
2005-12-26 3:53 ` Alan Stern
2005-12-26 21:20 ` Patrick Mochel
2005-12-26 22:50 ` Dmitry Torokhov
2005-12-26 23:01 ` Alan Stern
2005-12-27 21:45 ` Dmitry Torokhov
2005-12-27 22:08 ` Pavel Machek
2005-12-27 22:21 ` Dmitry Torokhov
2005-12-27 22:31 ` Pavel Machek
2005-12-27 22:39 ` Dmitry Torokhov
2005-12-27 22:44 ` Pavel Machek
2005-12-29 2:07 ` Alan Stern
2005-12-27 21:09 ` Patrick Mochel
2005-12-27 21:51 ` Dmitry Torokhov [this message]
2005-12-28 4:36 ` Patrick Mochel
2005-12-28 6:11 ` Dmitry Torokhov
2005-12-28 10:59 ` Rafael J. Wysocki
2005-12-29 2:18 ` Alan Stern
2005-12-29 2:55 ` Nigel Cunningham
2005-12-29 11:29 ` Rafael J. Wysocki
2005-12-30 17:46 ` Alan Stern
2006-01-04 23:31 ` Pavel Machek
2006-01-05 16:07 ` Alan Stern
2006-01-05 19:05 ` Pavel Machek
2005-12-29 2:13 ` Alan Stern
2005-12-29 2:10 ` Alan Stern
2005-12-29 5:20 ` Dmitry Torokhov
2005-12-30 18:26 ` Alan Stern
2005-12-30 19:18 ` Dmitry Torokhov
2005-12-30 19:26 ` Alan Stern
2005-12-30 19:42 ` Dmitry Torokhov
2005-12-30 20:13 ` Alan Stern
2005-12-29 2:02 ` Alan Stern
2005-12-30 18:34 ` Patrick Mochel
2005-12-30 19:21 ` Alan Stern
2006-01-02 23:49 ` Patrick Mochel
2005-12-26 23:25 ` Alan Stern
2005-12-23 18:32 ` Dmitry Torokhov
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=d120d5000512271351s766ef783j6d32ea802f5ee3cd@mail.gmail.com \
--to=dmitry.torokhov@gmail.com \
--cc=dtor_core@ameritech.net \
--cc=linux-pm@lists.osdl.org \
--cc=mochel@digitalimplant.org \
/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