linux-kernel - 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]

Date:	Sat, 03 Mar 2007 23:48:52 +0100
From:	Tilman Schmidt <tilman@...p.cc>
To:	LKML <linux-kernel@...r.kernel.org>
CC:	nigel@...el.suspend2.net, "Rafael J. Wysocki" <rjw@...k.pl>,
	Pavel Machek <pavel@....cz>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Suspend/resume semantics for ISDN drivers (was: NAK new drivers without
 proper power management?)

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?

Thanks for any insights,
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@...p.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


Download attachment "signature.asc" of type "application/pgp-signature" (254 bytes)