On Wed, 2014-01-22 at 16:05 -0800, Ben Greear wrote: > >> + * @IEEE80211_KEY_FLAG_SW_RX_CRYPT: This flag indicates hardware will not > >> + * do any decrypt for received packets, though it may have uploaded > >> + * the hardware key to be used for encrypting transmitted frames. > > > > This isn't needed, all you need to do is return 0 from the set_key > > callback in the driver, without programming the key into the device. And > > then ignore tkip key updates for such a key. > > I want and need to program the key into the device so that it can do the > encryption for transmit. But, I need software to do full decryption on > receive. Ok so the "without programming the key into the device" part was iwlwifi specific (on TX the key is given explicitly with that device.) However, the same still applies - just replace that by "without enabling it for RX" or so. > That is the only way I could get ath10k to do any sort of software crypt, > and in fact, that is the most efficient way to get the features I need > so I might try getting ath9k to support the same mode some day... > > I'll be posting ath10k patches to use this soon, but the dark magic > is down in the firmware in this case. Ok, whatever, what I'm saying is that mac80211 doesn't care about whether you enabled the key for RX or not if you return 0 from set_key(). All it cares about it that if you return 0 the key must be available for TX. You therefore don't need to make any mac80211 changes. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
