On 05/14/2015 12:35 PM, Liu CF/TW wrote:
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.
This fine for me. I'll just keep using my patch that enables nohwcrypt
module option to enable my own rx-sw-crypt feature. If I ever
get raw-tx working for encrypted packets I'll set that flag in
my firmware as you suggest.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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