disable wifi stopped working on XO-1

[dsd]

10.1.2 build 300 for XO-1. Hal Murray says

> The My Settings/Radio Wireless/Radio checkbox seems to turn itself back on.
> If I turn it off, then get out of My Settings, then go back to My Settings,
> it's on.
>
> The WiFi LED doesn't track that checkbox.  If the box is (was?) unchecked,
> the LED stays on when it suspends.  That's what I expect.  If the box is
> checked, the LED still stays on when it suspends.  I was expecting it to turn
> off.

[pgf]

there's no linkage between rfkill and the XO-1 libertas driver, so the control panel checkbox doesn't do anything at all. adding this linkage wouldn't be difficult -- the olpc_ec_cmd() calls necessary can be found in olpc-pm.c, and it's obvious where to put them in olpc-rfkill.c.

before i realized how easy that would be, i prototyped the following, which does essentially the same thing, and which would also work, but i'm not recommending it:

a quick solution would involve removing the rfkill package, and instead installing the following emulation script:

#!/bin/sh

# fake rfkill command.  the XO-1 wireless driver isn't hooked
# up to rfkill, and there are no other rfkillable devices,
# so the real command would do no good.

usage()
{
        echo "${0##*/} {block|unblock} {wifi|wlan}" >&2
        exit 1
}

case $2 in
wifi|wlan)  ;;
*)         usage ;;
esac

case $1 in
block)    echo 0 > /sys/power/wlan-enabled ;;
unblock)  echo 1 > /sys/power/wlan-enabled ;;
*)        usage ;;
esac

this would also require either:

chmod a+w /sys/power/wlan-enabled

or

chown olpc:olpc /sys/power/wlan-enabled

probably from olpc-configure.

[pgf]

hmm. not so fast.

on XO-1, the interface we use for disabling wireless isn't really an enable/disable mechanism. it's more of a "reset and release" vs. "reset and hold in reset". i.e., there's no way to force the wlan out of reset without _causing_ a reset.

the result is that if we implement rfkill on top of this, then two "rfkill unblock wifi" commands in a row will cause a wlan reset. we could keep a state variable, but since there's another path to the wlan reset capability via /sys/power/wlan-enabled, that get's complicated, and possibly error-prone. if there were an EC command called "EC_WLAN_FETCH_RESET_STATE" we could use that to avoid a second reset, but there isn't.

ideas? most of the time this won't be an issue. what's at stake is implementing what looks like an rfkill interface which isn't really correct.

[dsd]

How about this:

olpc-pm provides functions for "disable wlan" and "enable wlan". Those functions record state in software, so that enabling an already-enabled wlan does nothing. a separate function can be used to read the software-stored state.

Then the /sys and rfkill interfaces would both share those functions.

[dsd]

pushed that interface to olpc-2.6 and updated the sysfs file

[pgf]

rfkill implemented for XO-1. works in parallel with the wlan-enabled interface (i.e., they both reflect each others changes). wlan-enabled still has the side-effect of doing a reset on ever enable, even if already enabled. rfkill doesn't behave that way.

[dsd]

test in upcoming os301

[Quozl]

Tested in os301 XO-1, turning radio off in control panel works correctly, as does returning to the control panel, and turning it back on.