Isn't Wifi supposed to be off by default?

[Werner Almesberger]

c_c wrote:
>   I was reading about the power consumption issues with WiFi, and so made a
> small script to switch off WiFi containing 
>    iwconfig eth0 txpower off

This is already implied by --wlan disable.

>    wmiconfig -i eth0 --wlan disable

This is good as long as you make sure you never touch --power maxperf.
If you want to be extra-careful, you would first issue
wmiconfig -i eth0 --power rec

>    ifconfig eth0 down (probably don't need this)

Only if you want to use interface removal/creation as a way to signal
the upper layers that reconfiguration is needed.

But see below for a better solution.

>   And last night I had an uninterrupted suspend from 22:51 to 05:53!

Ah, nothing like a good night's sleep ;-)

>   1. Were most of my wakeups because of WiFi?

WLAN has a wakeup-on-WLAN (WoW) mechanism that could indeed cause
wakeups. I've only noticed stray WoW interrupts while powering down,
but it's not impossible that there's some yet to be explores problem.

The kernel printk's "ar6000_wow interrupt" whenever such an interrupt
is delivered, so you can easily check if they're causing problems.

> I should have kept track of
> the reason - but I didn't. Will do so now. But, Isn't WiFi supposed to be
> off by default?

This depends on how your kernel is configured and if user space is
taking any actions. If we consider only the kernel itself and further
assume that you're using one of the default configurations, then the
module itself used to be powered up but unconfigured until recently.

With this week's changes to andy-tracking (2.6.28), you still get the
old behaviour if you build your kernel with gta02-moredrivers-defconfig.
If you build it with gta02-packaging-defconfig, the WLAN driver is built
as a module and thus inactive until user space decides to load it.

> Top causes for wakeups:
>   39.0% (204.0)       <interrupt> : s3c-mci 

This comparably high interrupt rate is expected behaviour, as far as
SDIO is concerned. What happens is that the SDIO stack polls the
device periodically for pending interrupts, which involves sending a
command over the bus each time, which in turn produces a completion
interrupt on the host side.

The stack does this seemingly foolish thing because the S3C MMC
driver does not support handling SDIO interrupt as real interrupts.

You can avoid all these complications by either using module removal
or by unbinding the driver during a period in which you wish to
minimize power consumption:

cd /sys/bus/platform/drivers/s3c2440-sdi
echo s3c2440-sdi >unbind

To reactivate:
echo s3c2440-sdi >bind

This will, while unbound:

- power down the module's function (not the module itself. Our
  hardware can't do that. But the remaining power consumption
  should be marginal.)

- stop the SDIO stack's polling

- remove the network interface (eth0)

- signal the removal and - when re-binding - addition of the
  interface through netlink

- lose all configuration of the network interface kept inside the
  kernel, including ESSID, IP address, and routes

So you need user space to pick up the notification and configure
the interface. Since the device may have moved to a different
network while incommunicado, you usually wouldn't want to blindly
reuse the previous settings anyway.

- Werner