[PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688

[Sebastian Andrzej Siewior]

* Andrey Yurovsky | 2009-09-16 13:47:48 [-0700]:

>> Some information (such as the interface name and path) in README file is out of date. We just copy-and-paste it for the new deepsleep command. We need a separate patch to clean up the REAME file and keep it up to date.
>
>Ok.  Either way, this is another out-of-band interface (regardless of
>if it's debugfs or sysfs).  That said, I believe that debugfs should
>be used for debugging, not for configuring driver/device features like
>these.
I agree on this. Debugfs is for debug only and should stay that way.
What do other driver in regard to this? I hardly belive that the
libertas driver is the only "deep sleep" user.

>>> Deep sleep seems to pretty much "turn off" the wifi card (as far as
>>> the user is concerned) so how about a simpler approach: enter deep
>>> sleep when the interface is brought down (ifconfig wlanN down) and
>>> exit deep sleep when it's brought up. ?Do this only when deep sleep is
>>> supported/possible. ?Alternately, maybe this belongs as an rfkill
>>> feature?
>>
>> Entering/exiting deep sleep doesn't have to depend on wlanN interface's up and down. User can still put the chip into sleep when wlanN is up. And, with auto deep sleep feature, the driver automatically wakes the chip up for sending user commands (for example, scan) and put the chip back to sleep after certain time period of inactivity. The deepsleep command through debugfs interface provides the flexibility of deep sleep options.
>>
>> The rfkill shuts down the RF transmitter of the device but most of other modules may be still functioning. The deep sleep shuts down most of the modules (including the RF) on the chip to save as much power as possible.
>
>It seems that when the device is in deep sleep, it's effectively
>"turned off" as far as the user is concerned.  That seems really
>similar to "ifconfig down" or rfkill, does the user really care about
>anything beyond that?  I understand that it's possible to control this
>feature independently of either of those functions, but is it ever
>necessary?  If not, it would be great to just integrate it into one
>(or both) of these already standard network interface semantics and
>not introduce a whole new configuration parameter.

iwconfig has an interface for this I think:
|interface power {period N|timeout N|saving N|off}