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?

 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.


-- 
        Greg Troxel <gdt@ir.bbn.com>