btw 4019 doesnt support vht160 in ath10k see vht160_mcs_rx_highest in
core params
if it does support vht160, ath10k must be adjusted here
Am 28.04.2018 um 17:37 schrieb Ben Greear:
On 04/28/2018 08:26 AM, Sebastian Gottschall wrote:
Am 28.04.2018 um 17:01 schrieb Ben Greear:
On 04/27/2018
From: Sebastian Gottschall
current handling of peer_bw_rxnss_override parameter is based on guessing the
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since
VHT160 operation mode only supports 2x2 chainmasks
Hi Ben
Thanks for your time.
If I want to try ath10k-ct-driver, where I can get stable version?
There has information about pci-e layout.
The device has two PCI-e slots. one is the original pci-e slot of main board
and the other one is the output of pci-e switch.
case 1:one is the original
ath10k has a replay detection issue which was fixed in v4.14 and we would
like to get this security fix also to linux-stable-4.4.But for that it
depends on 3 mac80211 patches so the below mac80211 commits needs to be
picked first in the same order and then apply this patchset.
f980ebc058c2 : mac80
Chipset QCA99X0 doesnot have rx_hdr_status padded to
align in 4-byte boundary.Hence define a new hw_params
field to handle different alignment behaviour between
different chipsets.
[Upstream commit : 2f38c3c01de945234d23dd163e3528ccb413066d]
Signed-off-by: Vasanthkumar Thiagarajan
Signed-off-by:
Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available
