On Thu, May 14, 2015 at 8:12 AM, Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> wrote:
> "Liu CF/TW" <cfliu.tw@xxxxxxxxx> writes:
>
>> I am going to propose just one single module parameter control: enc_mode
>>
>> - enc_mode = 0: Use HW crypto (default),
>>
>> Driver behavior:
>> - ath10k driver uses native WiFi mode for both Tx/Rx.
>> - ath10k driver configures key to HW.
>> Given HW key descriptor is configured, mac80211 would offload Tx
>> encryption to HW and only do Rx decryption (by mac80211) if HW failed
>> to do it.
>
> But isn't the point here to use 802.11 frames ("raw mode")? Then why
> name the module paramater as enc_mode? I think that's confusing.
>
> And to me enc_mode doesn't tell much, my first thought was "encoding
> mode". Wouldn't cryptmode tell more to the user?
>
>
Thanks for the suggestion. Yes, crypt_mode is better. I didn't mean
"enc({ap, oding})_mode" but "enc(ryption)_mode"
IMO, the new use cases enabled by the change are sw crypto support and
raw Tx frame injection (to bypass hw crypto if already encrypted).
Therefore I suggest use "crypt_mode" as module param so it's clear one
only needs to set it if sw crypto is desired.
"raw_mode" itself as a module param doesn't mean much to user, it
doesn't say what new use cases are supported. After all, both native
wifi and raw mode supports HW crypto.
In Ben's use case, driver that loads CT firmware can continue to run
without setting anything (default crypt_mode=0 means use HW crypto)
and FW continues its magic to enable Rx SW crypto fallback. At some
point when CT firmware implements the FW feature
TX_RAW_ENCAP_SUPPORTED, all the crypt_modes=0,1,2 also works there.
Does this make sense?
David
> --
> Kalle Valo
--
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
