[PATCH powerd] Look in /var/lock/ppp for LCK..ttyUSB* also.

[Sascha Silbe]

Jerry Vonau <jvonau at shaw.ca> writes:

[Hack to prevent suspend while GSM connection is in use]
> How could we have dbus delay suspend while the ppp connection is
> becoming active?

You need to extend powerd-dbus/nm_monitor.c to monitor other device
types (GSM in this case) in addition to WLAN devices. See the
NetworkManager 0.8 D-Bus API [1] and libnm-glib 0.8 API [2] for Fedora
14 or NM 0.9 D-Bus API [3] and libnm-glib 0.9 API [4] for Fedora
17. While most of nm_monitor.c only talks about WLAN devices, the WLAN
specific code is limited to a few checks to ignore non-WLAN devices (in
device_added_cb(), device_removed_cb() and examine_device()).

If you only want to inhibit suspend while the PPP connection gets
established, all you need to do is to modify the checks mentioned above
to allow NM_DEVICE_TYPE_MODEM in addition to
NM_DEVICE_TYPE_WIFI. However, that's unlikely to do what you really
want, as at least on XO-1 and XO-1.5 the USB ports get powered down
during suspend, so you'd loose the GSM connection right after it got
established. On XO-1.75 that problem may be fixed, but I wouldn't bet on
most GSM modems to implement waking the host on incoming packets
properly or even at all. We're still having trouble with the WLAN chips
in this regard, even after several years of using the same two chips
(USB8388 in XO-1, SD8686 in XO-1.5 and XO-1.75). GSM modems are an order
of magnitude more problematic, so it's probably best to just inhibit
suspend on all systems as long as a GSM connection is active. You can
change that in check_device_state():

diff --git i/powerd-dbus/nm_monitor.c w/powerd-dbus/nm_monitor.c
index fb10555..d33d8aa 100644
--- i/powerd-dbus/nm_monitor.c
+++ w/powerd-dbus/nm_monitor.c
@@ -16,8 +16,11 @@ typedef struct DeviceHandle {
 
 static void check_device_state(NMDevice *device, DeviceHandle *handle, gboolean *suspend_ok)
 {
-       if (handle->state >= NM_DEVICE_STATE_PREPARE &&
-               handle->state < NM_DEVICE_STATE_ACTIVATED) {
+       if ((handle->state >= NM_DEVICE_STATE_PREPARE &&
+            handle->state < NM_DEVICE_STATE_ACTIVATED) ||
+           (handle->state == NM_DEVICE_STATE_ACTIVATED &&
+            NM_IS_DEVICE_MODEM(device))
+                   ) {
                g_message("%d: device %p state %d inhibits suspend", (int)time(0),
                        device, handle->state);
                *suspend_ok = FALSE;

Untested, for NM 0.9 only. For NM 0.8 you need to check both
NM_IS_GSM_DEVICE and NM_IS_CDMA_DEVICE. Since all of those are macros,
a simply #ifdef NM_IS_DEVICE_MODEM should be enough to distinguish
between NM 0.8 and NM 0.9; no need for autoconf magic.


In addition, you'll want to inhibit suspend while the GSM modem is
trying to register with the cellular network provider. For that you'll
need to monitor ModemManager (similar to the monitoring of
wpa-supplicant that powerd theoretically does for WLAN devices). Check
out the ModemManager 0.5 API [5] (F14 and F17).

For monitoring whether the modem is currently trying to register to the
mobile phone network provider, you can use the GetRegistrationInfo() and
RegistrationInfo() signal (enumeration MM_MODEM_GSM_NETWORK_REG_STATUS).


The approach detailed above is the high-tech solution that upstream
should have in the long term. In the meantime you'll probably get best
results using USB based suspend inhibit. This is what I use:

{{{
sascha.silbe at mimosa:~$ grep -A2 GSM /etc/olpc-powerd/flags/usb-inhibits 
# GSM modems are very slow to (re)establish a connection and practically
# unusable with aggressive suspend
class=commc
sascha.silbe at mimosa:~$ 
}}}

Plug in the GSM modem to use it (you'll have to explicitly establish the
connection as NM 0.9 regressed over NM 0.8 w.r.t. automatic connection
for GSM devices), remove it when you're done. Stable connection (as far
as possible over GSM) while in use, no power draw while disconnected.

I haven't checked whether class=commc works for all (or most) GSM
modems. Caveat emptor.

Sascha

[1] http://projects.gnome.org/NetworkManager/developers/api/08/spec-08.html
[2] http://projects.gnome.org/NetworkManager/developers/libnm-glib/08/
[3] http://projects.gnome.org/NetworkManager/developers/api/09/spec.html
[4] http://projects.gnome.org/NetworkManager/developers/libnm-glib/09/
[5] http://projects.gnome.org/NetworkManager/developers/mm-spec-05.html
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20120529/cebeec08/attachment.sig>