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

[Andrey Yurovsky]

On Wed, Sep 16, 2009 at 1:20 PM, Bing Zhao <bzhao at marvell.com> wrote:
> Hi Andrey,
>
>> -----Original Message-----
>> From: Andrey Yurovsky [mailto:andrey at cozybit.com]
>> Sent: Tuesday, September 15, 2009 4:41 PM
>> To: Bing Zhao
>> Cc: libertas-dev at lists.infradead.org; linux-wireless at vger.kernel.org; Amitkumar Karwar; Dan Williams
>> Subject: Re: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
>>
>> Hi Bing.  This is not specific to the actual implementation of the
>> deep sleep commands in your patch but,
>>
>> On Tue, Sep 15, 2009 at 4:45 PM, Bing Zhao <bzhao at marvell.com> wrote:
>> > +       Path: /sys/kernel/debug/libertas_wireless/ethX/
>>
>> Is the sysfs interface really necessary?  It seems like yet another
>> non-standard configuration option to keep track of.
>
> Actually the debugfs interface is used in the patch.
>
> 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.

>> 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.

  -Andrey

> Regards,
>
> Bing
>
>>
>>   -Andrey
>