Subject: Re: ath driver and wep
To: Greg Troxel <email@example.com>
From: Sam Leffler <firstname.lastname@example.org>
Date: 10/02/2005 10:33:55
Greg Troxel wrote:
> Sam Leffler <email@example.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
> 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
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.