linux-kernel - Re: Suspend/resume semantics for ISDN drivers (was: NAK new drivers without proper power management?)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200703042004.26684.rjw@sisk.pl>
Date:	Sun, 4 Mar 2007 20:04:25 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Tilman Schmidt <tilman@...p.cc>
Cc:	LKML <linux-kernel@...r.kernel.org>, nigel@...el.suspend2.net,
	Pavel Machek <pavel@....cz>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: Suspend/resume semantics for ISDN drivers (was: NAK new drivers without proper power management?)

On Saturday, 3 March 2007 23:48, Tilman Schmidt wrote:
> Ok, I've thought some more but I still don't know ...
> 
> 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.

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/