Re: [PATCH] ath10k/mac80211: add rawtxrx, nohwcrypt module param for raw tx injection, sw crypto support.

[Kalle Valo <kvalo@qca.qualcomm.com>]

"Liu CF/TW" <cfliu.tw@gmail.com> writes:

>>> I wonder does it make any sense to have nohwcrypt parameter? Especially
>>> if ath10k doesn't support case rawtxrx=0 and nohwcrypt=1. One
>>> possibility I came up is to have multiple values for rawtxrx, for
>>> example is rawtxrx=1 means HW crypt enabled and rawtxrx=2 HW crypt
>>> disabled. Ideas welcome.
>
> Indeed. I picked nohwcrypt because it seems to be the convention in
> previous Atheros drivers for this feature.

Yeah, but I don't think we need to follow that in ath10k. Especially not
until we get SW encryption working in all cases.

> In this case, I will drop nohwcrypt and do as you suggested.
>
> rawmode = 0: Raw mode disabled. Use the default native WiFi mode. In
> this mode, only HW crypto is supported.
> rawmode = 1: Use Raw rx decap + raw tx encap mode. Supports both SW
> and HW crypto.
> rawmode = 2: Same as 1, but with HW crypto engine globally disabled.

I would guess that HW crypto globally disabled (value 2 above) will be
more popular, right? So would it make sense to reverse the values and
use value 1 for that?

> When rawmode = 1, I want a further per BSS control to make some BSS
> use HW crypto and some BSS bypass HW crypto.
> For those BSS that have HW crypto bypassed, their data frames may come
> from either the normal wlan interfaces (therefore mac80211 sw crypto
> used), or from monitor interfaces (therefore Tx injected frames
> already encrypted + Rx frames still encrypted)

Ok, we need to think how to configure this. Maybe a debugfs interface?

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k