Isn't Wifi supposed to be off by default?

[Werner Almesberger]

Andy Green wrote:
> but the rfkill + power
> reduction thing replacing existing alleged power control stuff is also
> really needed if we didn't know that already.

I'm afraid rfkill will not be the best choice for this after all.
I've tried to implemented it as an equivalent to bind/unbind of
the MMC driver, but there are two big issues with this approach:

- rfkill state is not synchronized with bind/unbind, module
  load/unload, etc. I can work around it to the extent that this
  at least doesn't cause crashes, but you can still easily get
  the situation that rfkill says the device is disabled while it's
  happily transmitting.

  This issue could be patched up by hooking into the bus notifier,
  but that yields another host of layering violations and potential
  races.

- in order to avoid a lethal race, locking needs to be rearranged
  in the driver core.

  That's not a problem per se, but given that the whole thing doesn't
  really fit anyway, I see little point in trying to sell that change
  to upstream.

Placing the rfkill mechanism one layer higher solves most of these
issues:

- in order to preserve rfkill state across suspend/resume, we still
  need a private interface between a platform device that talks to
  the rfkill subsystem and the AR6k driver. But that can be implemented
  reasonably cleanly in the HIF.

- that rfkill front-end and the HIF can tightly synchronize to make
  sure no rfkill changes are lost.

- the locking changes are all in the HIF. They're not trivial (it's
  the addition of a fourth execution path to the already somewhat
  convoluted shutdown mechanism), but well in line with what that
  part of the HIF is already doing.

The disadvantage is that, if someone mistakes rfkill for the optimum
power-saving mechanism, they lose about 17mW compared to bind/unbind
or module unloading.

> Module removal should also enforce lowest power mode if it isn't already
> too I guess.

If you remove s3cmci.ko, then it does that. If you only remove
ar6000.ko, then the driver will still keep the bus powered and
the clock running (it's the latter that makes the difference).
That's the 17mW again.

Here are some measurements for modules:

                        min      average  max       stddev
boot, cut PMU           147.93mA 148.19mA 148.76mA  0.231mA
insmod mmc_core.ko      148.07mA 148.47mA 149.30mA  0.380mA
insmod s3cmci.ko        152.57mA 153.13mA 154.14mA  0.488mA
insmod ar6000.ko        153.60mA 154.01mA 154.79mA  0.342mA
rfkill                  152.58mA 153.26mA 154.88mA  0.717mA

This is without setting an ESSID or such.

Suspend also takes down the MMC driver, so it gets the best power
saving, no matter what else has been done.

- Werner