From: Pavel Machek <pavel@ucw.cz>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Tilman Schmidt <tilman@imap.cc>,
LKML <linux-kernel@vger.kernel.org>,
nigel@nigel.suspend2.net, Arjan van de Ven <arjan@infradead.org>
Subject: Re: Suspend/resume semantics for ISDN drivers (was: NAK new drivers without proper power management?)
Date: Fri, 9 Mar 2007 00:35:20 +0100 [thread overview]
Message-ID: <20070308233520.GD2793@elf.ucw.cz> (raw)
In-Reply-To: <200703042004.26684.rjw@sisk.pl>
Hi!
> > On 12.02.2007 01:10 I wrote:
> > > I don't doubt your basic assessment. However it doesn't translate that
> > > easily into a real implementation. In my case, I maintain a USB driver,
> > > so I have to deal with USB specifics of suspend/resume which happen not
> > > to be that well documented. My driver provides an isdn4linux device but
> > > isdn4linux knows nothing about suspend/resume so I am on my own on how
> > > to reconcile the two. The device itself, though in turn far from trivial,
> > > is actually the least of my worries.
> >
> > So, how *should* an isdn4linux driver handle a request to suspend?
> > Specifically, if there are active connections, should it try to
> > shut them down in an orderly fashion (which might imply some delays
> > waiting for the remote station to acknowledge, etc.)? Should it kill
> > them abruptly (as for a USB unplug event)? Or should it just refuse
> > to suspend while a connection is still active?
>
> I think that refusing to suspend wouldn't be a good approach (think of an
> emergency suspend when the battery is running low).
>
> Probably the closing of connections would be the nicest thing from the
> user's point of view.
It depends on "how long does connection close take". If it is more
than few seconds, kill them abruptly.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2007-03-08 23:35 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-09 21:57 NAK new drivers without proper power management? Nigel Cunningham
2007-02-09 22:17 ` Arjan van de Ven
2007-02-09 22:26 ` Nigel Cunningham
2007-02-09 22:44 ` Rafael J. Wysocki
2007-02-09 22:51 ` Nigel Cunningham
2007-02-09 23:12 ` Rafael J. Wysocki
2007-02-09 23:28 ` Nigel Cunningham
2007-02-10 0:12 ` Rafael J. Wysocki
2007-02-10 0:25 ` Jeff Garzik
2007-02-10 6:43 ` Willy Tarreau
2007-02-10 23:52 ` Tilman Schmidt
2007-02-10 7:15 ` Arjan van de Ven
2007-02-10 19:38 ` Pavel Machek
2007-02-10 22:20 ` Rafael J. Wysocki
2007-02-10 22:37 ` Nigel Cunningham
2007-02-10 23:45 ` Tilman Schmidt
2007-02-11 0:27 ` Rafael J. Wysocki
2007-02-11 22:41 ` Nigel Cunningham
2007-02-13 15:55 ` Mark Lord
2007-02-13 16:06 ` Christoph Hellwig
2007-02-11 22:37 ` Nigel Cunningham
2007-02-12 0:10 ` Tilman Schmidt
2007-02-12 0:20 ` Rafael J. Wysocki
2007-02-12 4:08 ` Nigel Cunningham
2007-02-12 20:06 ` Rafael J. Wysocki
2007-02-12 22:38 ` Nigel Cunningham
2007-03-03 22:48 ` Suspend/resume semantics for ISDN drivers (was: NAK new drivers without proper power management?) Tilman Schmidt
2007-03-04 19:04 ` Rafael J. Wysocki
2007-03-08 23:35 ` Pavel Machek [this message]
2007-02-11 6:46 ` NAK new drivers without proper power management? Willy Tarreau
2007-02-11 13:04 ` Rafael J. Wysocki
2007-02-11 22:47 ` Nigel Cunningham
2007-02-11 22:57 ` Manu Abraham
2007-02-11 23:20 ` Nigel Cunningham
2007-02-11 23:25 ` Manu Abraham
2007-02-11 23:29 ` Pavel Machek
2007-02-11 23:33 ` Nigel Cunningham
2007-02-12 16:52 ` Pavel Machek
2007-02-12 20:31 ` Rafael J. Wysocki
2007-02-12 20:58 ` Pavel Machek
2007-02-12 21:01 ` Rafael J. Wysocki
2007-02-12 21:24 ` Nigel Cunningham
2007-02-12 21:43 ` Rafael J. Wysocki
2007-02-13 9:42 ` Tilman Schmidt
2007-02-13 19:24 ` Rafael J. Wysocki
2007-02-14 23:45 ` Stefan Richter
2007-02-12 9:45 ` Arjan van de Ven
2007-02-12 12:59 ` Gerhard Mack
2007-02-12 20:20 ` Willy Tarreau
2007-02-13 15:23 ` Brad Campbell
2007-02-12 20:46 ` Rafael J. Wysocki
2007-02-12 13:51 ` Tino Keitel
2007-02-11 19:42 ` Pavel Machek
2007-02-11 21:02 ` Alan
2007-02-11 23:04 ` Rafael J. Wysocki
2007-02-12 0:28 ` Alan
2007-02-12 0:24 ` Rafael J. Wysocki
2007-02-11 23:10 ` Nigel Cunningham
2007-02-11 23:16 ` Rafael J. Wysocki
2007-02-11 23:22 ` Nigel Cunningham
2007-02-11 23:23 ` Pavel Machek
2007-02-11 23:21 ` Pavel Machek
2007-02-11 23:29 ` Nigel Cunningham
2007-02-11 22:21 ` Tilman Schmidt
2007-02-12 8:49 ` Geert Uytterhoeven
2007-02-12 15:04 ` Pavel Machek
2007-02-12 15:57 ` Geert Uytterhoeven
2007-02-12 16:55 ` Pavel Machek
2007-02-12 20:38 ` Nigel Cunningham
2007-02-13 10:02 ` Tilman Schmidt
2007-02-10 3:42 ` Matthew Garrett
2007-02-10 4:42 ` Nigel Cunningham
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=20070308233520.GD2793@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nigel@nigel.suspend2.net \
--cc=rjw@sisk.pl \
--cc=tilman@imap.cc \
/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