Greg Troxel wrote:
> Sam Leffler <sam@errno.com> writes:
> 
> 
>>I believe I understand the issue; I've been corresponding  with David
>>Young.  The net80211 layer assumes that when it calls the driver to
>>set a key value that value will be preserved.  The ath driver calls to
>>the hal to write the key cache but on netbsd this apparently fails for
>>cardbus cards because the socket power is off (I verified that it
>>works for minipci cards).  All other systems I'm familiar with do not
>>do this.
> 
> 
> This matches my understanding; I just wasn't confident I had it
> right.  It also fits with my patch helping.
> 
> 
>>My response was that it wasn't clear for Atheros parts that
>>much was to be gained by powering off the socket since the card in
>>full sleep w/ the phy/radio turned off should draw very little power
>>(the default state the card is set in on calling ath_stop; e.g. when
>>marking the interface down).  If in fact cards are drawing noticeable
>>power then something is wrong and we should fix that.  If folks still
>>feel it's critical to power off the socket then you'll need a
>>workaround in the driver to restore the key cache contents on power
>>up--which is what Greg has done.
> 
> 
> My understanding of cardbus on NetBSD is that normal behavior for
> network devices is to power off the slot when the interface is down.
> This may not save much more power than 'full sleep' and thus not be
> justifiable from a power point of view, but it's the way (almost?)
> every other device is.  The driver already writes a bunch of things on
> power up, and writing key bits seems easy enough.  From this I have
> two thoughts/questions:
> 
>  Do wep keys on a cardbus ath survive suspend/resume on FreeBSD?  Does
>  the card somehow stay in full sleep during suspend, instead of being
>  unpowered?

None my laptops resume properly on freebsd (undoubtedly operator error).

> 
>  It seems reasonable to allow drivers to power off cards that are not
>  UP.  I wonder if it makes sense to have a call in net80211 that a
>  driver can invoke to say "push hardware settings to me again" that
>  invokes the wep key write methods and perhaps other things.  This may
>  be the only case, but it felt like a bit of an abstraction violation
>  to be iterating over the key array.
> 

It's likely something must be done specially for resume because there 
are more than wep keys to restore (e.g. the unicast key(s) for 
wpa/802.1x).  To be honest sta mode operation has been lower priority 
than ap mode; e.g. I still haven't finished power save support.

	Sam