wifi: wcn36xx: Add RX frame SNR as a source of system entropy

The signal-to-noise-ratio SNR is returned by the wcn36xx firmware for each
received frame. SNR represents all of the unwanted interferen

wifi: wcn36xx: Add RX frame SNR as a source of system entropy

The signal-to-noise-ratio SNR is returned by the wcn36xx firmware for each
received frame. SNR represents all of the unwanted interference signal
after filtering out the fundamental frequency and harmonics of the
frequency.

Noise can come from various electromagnetic sources, from temperature
affecting the performance hardware components or quantization effects
converting from analog to digital domains.

The SNR value returned by the WiFi firmware then is a good source of
entropy.

Other WiFi drivers offer up the noise component of the FFT as an entropy
source for the random pool e.g.

commit 2aa56cca3571 ("ath9k: Mix the received FFT bins to the random pool")

I attended Jason's talk on sources of randomness at Plumbers and it
occurred to me that SNR is a reasonable candidate to add.

Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220915004117.1562703-2-bryan.odonoghue@linaro.org

show more ...

wcn36xx: Implement tx_rate reporting

Currently, the driver reports a tx_rate of 6.0 MBit/s no matter the true
rate:

root@linaro-developer:~# iw wlan0 link
Connected to 6c:f3:7f:eb:9b:92 (on wlan0)

wcn36xx: Implement tx_rate reporting

Currently, the driver reports a tx_rate of 6.0 MBit/s no matter the true
rate:

root@linaro-developer:~# iw wlan0 link
Connected to 6c:f3:7f:eb:9b:92 (on wlan0)
SSID: SQ-DEVICETEST
freq: 5200
RX: 4141 bytes (32 packets)
TX: 2082 bytes (15 packets)
signal: -77 dBm
rx bitrate: 135.0 MBit/s MCS 6 40MHz short GI
tx bitrate: 6.0 MBit/s

bss flags: short-slot-time
dtim period: 1
beacon int: 100

This patch requests HAL_GLOBAL_CLASS_A_STATS_INFO via a hal_get_stats
firmware message and reports it via ieee80211_ops::sta_statistics.

root@linaro-developer:~# iw wlan0 link
Connected to 6c:f3:7f:eb:73:b2 (on wlan0)
SSID: SQ-DEVICETEST
freq: 5700
RX: 26788094 bytes (19859 packets)
TX: 1101376 bytes (12119 packets)
signal: -75 dBm
rx bitrate: 135.0 MBit/s MCS 6 40MHz short GI
tx bitrate: 108.0 MBit/s VHT-MCS 5 40MHz VHT-NSS 1

bss flags: short-slot-time
dtim period: 1
beacon int: 100

Tested on MSM8939 with WCN3680B running firmware CNSS-PR-2-0-1-2-c1-00083,
and verified by sniffing frames over the air with Wireshark to ensure the
MCS indices match.

Signed-off-by: Edmond Gagnon <egagnon@squareup.com>
Reviewed-by: Benjamin Li <benl@squareup.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220325224212.159690-1-egagnon@squareup.com

show more ...

wcn36xx: clean up some inconsistent indenting

Eliminate the follow smatch warnings:
drivers/net/wireless/ath/wcn36xx/main.c:1394 wcn36xx_get_survey() warn:
inconsistent indenting
drivers/net/wireles

wcn36xx: clean up some inconsistent indenting

Eliminate the follow smatch warnings:
drivers/net/wireless/ath/wcn36xx/main.c:1394 wcn36xx_get_survey() warn:
inconsistent indenting
drivers/net/wireless/ath/wcn36xx/txrx.c:379 wcn36xx_rx_skb() warn:
inconsistent indenting

Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220201041548.18464-1-yang.lee@linux.alibaba.com

show more ...

wcn36xx: Track SNR and RSSI for each RX frame

The BDs for each RX frame contain both the RSSI and SNR for the received
frame. If we track and store this information it can be useful to us in
get_sur

wcn36xx: Track SNR and RSSI for each RX frame

The BDs for each RX frame contain both the RSSI and SNR for the received
frame. If we track and store this information it can be useful to us in
get_survey() and potentially elsewhere.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220115001646.3981501-4-bryan.odonoghue@linaro.org

show more ...

wcn36xx: Implement get_snr()

The wcn36xx BD phy descriptor returns both Received Signal Strength
Information (RSSI) and Signal To Noise Ratio (SNR) with each delivered BD.

The macro to extract this

wcn36xx: Implement get_snr()

The wcn36xx BD phy descriptor returns both Received Signal Strength
Information (RSSI) and Signal To Noise Ratio (SNR) with each delivered BD.

The macro to extract this data is a simple-one liner, easily imported from
prima driver. This data will be useful to us when implementing
mac80211-ops->get_survey().

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220115001646.3981501-2-bryan.odonoghue@linaro.org

show more ...

wcn36xx: fix RX BD rate mapping for 5GHz legacy rates

The linear mapping between the BD rate field and the driver's 5GHz
legacy rates table (wcn_5ghz_rates) does not only apply for the latter
four r

wcn36xx: fix RX BD rate mapping for 5GHz legacy rates

The linear mapping between the BD rate field and the driver's 5GHz
legacy rates table (wcn_5ghz_rates) does not only apply for the latter
four rates -- it applies to all eight rates.

Fixes: 6ea131acea98 ("wcn36xx: Fix warning due to bad rate_idx")
Signed-off-by: Benjamin Li <benl@squareup.com>
Tested-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211104010548.1107405-3-benl@squareup.com

show more ...

wcn36xx: populate band before determining rate on RX

status.band is used in determination of status.rate -- for 5GHz on legacy
rates there is a linear shift between the BD descriptor's rate field an

wcn36xx: populate band before determining rate on RX

status.band is used in determination of status.rate -- for 5GHz on legacy
rates there is a linear shift between the BD descriptor's rate field and
the wcn36xx driver's rate table (wcn_5ghz_rates).

We have a special clause to populate status.band for hardware scan offload
frames. However, this block occurs after status.rate is already populated.
Correctly handle this dependency by moving the band block before the rate
block.

This patch addresses kernel warnings & missing scan results for 5GHz APs
that send their beacons/probe responses at the higher four legacy rates
(24-54 Mbps), when using hardware scan offload:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:4532 ieee80211_rx_napi+0x744/0x8d8
Modules linked in: wcn36xx [...]
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.19.107-g73909fa #1
Hardware name: Square, Inc. T2 (all variants) (DT)
Call trace:
dump_backtrace+0x0/0x148
show_stack+0x14/0x1c
dump_stack+0xb8/0xf0
__warn+0x2ac/0x2d8
warn_slowpath_null+0x44/0x54
ieee80211_rx_napi+0x744/0x8d8
ieee80211_tasklet_handler+0xa4/0xe0
tasklet_action_common+0xe0/0x118
tasklet_action+0x20/0x28
__do_softirq+0x108/0x1ec
irq_exit+0xd4/0xd8
__handle_domain_irq+0x84/0xbc
gic_handle_irq+0x4c/0xb8
el1_irq+0xe8/0x190
lpm_cpuidle_enter+0x220/0x260
cpuidle_enter_state+0x114/0x1c0
cpuidle_enter+0x34/0x48
do_idle+0x150/0x268
cpu_startup_entry+0x20/0x24
rest_init+0xd4/0xe0
start_kernel+0x398/0x430
---[ end trace ae28cb759352b403 ]---

Fixes: 8a27ca394782 ("wcn36xx: Correct band/freq reporting on RX")
Signed-off-by: Benjamin Li <benl@squareup.com>
Tested-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211104010548.1107405-2-benl@squareup.com

show more ...

wcn36xx: Fix discarded frames due to wrong sequence number

The firmware is offering features such as ARP offload, for which
firmware crafts its own (QoS)packets without waking up the host.
Point is

wcn36xx: Fix discarded frames due to wrong sequence number

The firmware is offering features such as ARP offload, for which
firmware crafts its own (QoS)packets without waking up the host.
Point is that the sequence numbers generated by the firmware are
not in sync with the host mac80211 layer and can cause packets
such as firmware ARP reponses to be dropped by the AP (too old SN).

To fix this we need to let the firmware manages the sequence
numbers by its own (except for QoS null frames). There is a SN
counter for each QoS queue and one global/baseline counter for
Non-QoS.

Fixes: 84aff52e4f57 ("wcn36xx: Use sequence number allocated by mac80211")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1635150336-18736-1-git-send-email-loic.poulain@linaro.org

show more ...

wcn36xx: Add chained transfer support for AMSDU

WCNSS RX DMA transfer support is limited to 3872 bytes, which is
enough for simple MPDUs (single MSDU), but not enough for cases
with A-MSDU (dependin

wcn36xx: Add chained transfer support for AMSDU

WCNSS RX DMA transfer support is limited to 3872 bytes, which is
enough for simple MPDUs (single MSDU), but not enough for cases
with A-MSDU (depending on max AMSDU size or max MPDU size).

In that case the MPDU is spread over multiple transfers, with the
first transfer containing the MPDU header and (at least) the first
A-MSDU subframe and additional transfer(s) containing the following
A-MSDUs. This can be handled with a series of flags to tagging the
first and last A-MSDU transfers.

In that case we have to bufferize and re-linearize the A-MSDU buffers
into a proper MPDU skb before forwarding to mac80211 (in the same way
as it is done in ath10k).

This change also includes sanity check of the buffer descriptor to
prevent skb overflow.

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1634557705-11120-1-git-send-email-loic.poulain@linaro.org

show more ...

wcn36xx: Correct band/freq reporting on RX

For packets originating from hardware scan, the channel and band is
included in the buffer descriptor (bd->rf_band & bd->rx_ch).

For 2Ghz band the channel

wcn36xx: Correct band/freq reporting on RX

For packets originating from hardware scan, the channel and band is
included in the buffer descriptor (bd->rf_band & bd->rx_ch).

For 2Ghz band the channel value is directly reported in the 4-bit
rx_ch field. For 5Ghz band, the rx_ch field contains a mapping
index (given the 4-bit limitation).

The reserved0 value field is also used to extend 4-bit mapping to
5-bit mapping to support more than 16 5Ghz channels.

This change adds correct reporting of the frequency/band, that is
used in scan mechanism. And is required for 5Ghz hardware scan
support.

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1634554678-7993-1-git-send-email-loic.poulain@linaro.org

show more ...

wcn36xx: Fix tx_status mechanism

This change fix the TX ack mechanism in various ways:

- For NO_ACK tagged packets, we don't need to wait for TX_ACK indication
and so are not subject to the single

wcn36xx: Fix tx_status mechanism

This change fix the TX ack mechanism in various ways:

- For NO_ACK tagged packets, we don't need to wait for TX_ACK indication
and so are not subject to the single packet ack limitation. So we don't
have to stop the tx queue, and can call the tx status callback as soon
as DMA transfer has completed.

- Fix skb ownership/reference. Only start status indication timeout
once the DMA transfer has been completed. This avoids the skb to be
both referenced in the DMA tx ring and by the tx_ack_skb pointer,
preventing any use-after-free or double-free.

- This adds a sanity (paranoia?) check on the skb tx ack pointer.

- Resume TX queue if TX status tagged packet TX fails.

Cc: stable@vger.kernel.org
Fixes: fdf21cc37149 ("wcn36xx: Add TX ack support")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1634567281-28997-1-git-send-email-loic.poulain@linaro.org

show more ...

wcn36xx: Fix (QoS) null data frame bitrate/modulation

We observe unexpected connection drops with some APs due to
non-acked mac80211 generated null data frames (keep-alive).
After debugging and capt

wcn36xx: Fix (QoS) null data frame bitrate/modulation

We observe unexpected connection drops with some APs due to
non-acked mac80211 generated null data frames (keep-alive).
After debugging and capture, we noticed that null frames are
submitted at standard data bitrate and that the given APs are
in trouble with that.

After setting the null frame bitrate to control bitrate, all
null frames are acked as expected and connection is maintained.

Not sure if it's a requirement of the specification, but it seems
the right thing to do anyway, null frames are mostly used for control
purpose (power-saving, keep-alive...), and submitting them with
a slower/simpler bitrate/modulation is more robust.

Cc: stable@vger.kernel.org
Fixes: 512b191d9652 ("wcn36xx: Fix TX data path")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1634560399-15290-1-git-send-email-loic.poulain@linaro.org

show more ...

wcn36xx: fix RX BD rate mapping for 5GHz legacy rates

[ Upstream commit cfdf6b19e750f7de8ae71a26932f63b52e3bf74c ]

The linear mapping between the BD rate field and the driver's 5GHz
legacy rates ta

wcn36xx: fix RX BD rate mapping for 5GHz legacy rates

[ Upstream commit cfdf6b19e750f7de8ae71a26932f63b52e3bf74c ]

The linear mapping between the BD rate field and the driver's 5GHz
legacy rates table (wcn_5ghz_rates) does not only apply for the latter
four rates -- it applies to all eight rates.

Fixes: 6ea131acea98 ("wcn36xx: Fix warning due to bad rate_idx")
Signed-off-by: Benjamin Li <benl@squareup.com>
Tested-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211104010548.1107405-3-benl@squareup.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

wcn36xx: populate band before determining rate on RX

[ Upstream commit c9c5608fafe4dae975c9644c7d14c51ad3b0ed73 ]

status.band is used in determination of status.rate -- for 5GHz on legacy
rates the

wcn36xx: populate band before determining rate on RX

[ Upstream commit c9c5608fafe4dae975c9644c7d14c51ad3b0ed73 ]

status.band is used in determination of status.rate -- for 5GHz on legacy
rates there is a linear shift between the BD descriptor's rate field and
the wcn36xx driver's rate table (wcn_5ghz_rates).

We have a special clause to populate status.band for hardware scan offload
frames. However, this block occurs after status.rate is already populated.
Correctly handle this dependency by moving the band block before the rate
block.

This patch addresses kernel warnings & missing scan results for 5GHz APs
that send their beacons/probe responses at the higher four legacy rates
(24-54 Mbps), when using hardware scan offload:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:4532 ieee80211_rx_napi+0x744/0x8d8
Modules linked in: wcn36xx [...]
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.19.107-g73909fa #1
Hardware name: Square, Inc. T2 (all variants) (DT)
Call trace:
dump_backtrace+0x0/0x148
show_stack+0x14/0x1c
dump_stack+0xb8/0xf0
__warn+0x2ac/0x2d8
warn_slowpath_null+0x44/0x54
ieee80211_rx_napi+0x744/0x8d8
ieee80211_tasklet_handler+0xa4/0xe0
tasklet_action_common+0xe0/0x118
tasklet_action+0x20/0x28
__do_softirq+0x108/0x1ec
irq_exit+0xd4/0xd8
__handle_domain_irq+0x84/0xbc
gic_handle_irq+0x4c/0xb8
el1_irq+0xe8/0x190
lpm_cpuidle_enter+0x220/0x260
cpuidle_enter_state+0x114/0x1c0
cpuidle_enter+0x34/0x48
do_idle+0x150/0x268
cpu_startup_entry+0x20/0x24
rest_init+0xd4/0xe0
start_kernel+0x398/0x430
---[ end trace ae28cb759352b403 ]---

Fixes: 8a27ca394782 ("wcn36xx: Correct band/freq reporting on RX")
Signed-off-by: Benjamin Li <benl@squareup.com>
Tested-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211104010548.1107405-2-benl@squareup.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

wcn36xx: Fix discarded frames due to wrong sequence number

[ Upstream commit 113f304dbc1627c6ec9d5329d839964095768980 ]

The firmware is offering features such as ARP offload, for which
firmware cra

wcn36xx: Fix discarded frames due to wrong sequence number

[ Upstream commit 113f304dbc1627c6ec9d5329d839964095768980 ]

The firmware is offering features such as ARP offload, for which
firmware crafts its own (QoS)packets without waking up the host.
Point is that the sequence numbers generated by the firmware are
not in sync with the host mac80211 layer and can cause packets
such as firmware ARP reponses to be dropped by the AP (too old SN).

To fix this we need to let the firmware manages the sequence
numbers by its own (except for QoS null frames). There is a SN
counter for each QoS queue and one global/baseline counter for
Non-QoS.

Fixes: 84aff52e4f57 ("wcn36xx: Use sequence number allocated by mac80211")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1635150336-18736-1-git-send-email-loic.poulain@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

wcn36xx: Correct band/freq reporting on RX

[ Upstream commit 8a27ca39478270e07baf9c09aa0c99709769ba03 ]

For packets originating from hardware scan, the channel and band is
included in the buffer de

wcn36xx: Correct band/freq reporting on RX

[ Upstream commit 8a27ca39478270e07baf9c09aa0c99709769ba03 ]

For packets originating from hardware scan, the channel and band is
included in the buffer descriptor (bd->rf_band & bd->rx_ch).

For 2Ghz band the channel value is directly reported in the 4-bit
rx_ch field. For 5Ghz band, the rx_ch field contains a mapping
index (given the 4-bit limitation).

The reserved0 value field is also used to extend 4-bit mapping to
5-bit mapping to support more than 16 5Ghz channels.

This change adds correct reporting of the frequency/band, that is
used in scan mechanism. And is required for 5Ghz hardware scan
support.

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1634554678-7993-1-git-send-email-loic.poulain@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

wcn36xx: Fix (QoS) null data frame bitrate/modulation

commit d3fd2c95c1c13ec217d43ebef3c61cfa00a6cd37 upstream.

We observe unexpected connection drops with some APs due to
non-acked mac80211 genera

wcn36xx: Fix (QoS) null data frame bitrate/modulation

commit d3fd2c95c1c13ec217d43ebef3c61cfa00a6cd37 upstream.

We observe unexpected connection drops with some APs due to
non-acked mac80211 generated null data frames (keep-alive).
After debugging and capture, we noticed that null frames are
submitted at standard data bitrate and that the given APs are
in trouble with that.

After setting the null frame bitrate to control bitrate, all
null frames are acked as expected and connection is maintained.

Not sure if it's a requirement of the specification, but it seems
the right thing to do anyway, null frames are mostly used for control
purpose (power-saving, keep-alive...), and submitting them with
a slower/simpler bitrate/modulation is more robust.

Cc: stable@vger.kernel.org
Fixes: 512b191d9652 ("wcn36xx: Fix TX data path")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1634560399-15290-1-git-send-email-loic.poulain@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

wcn36xx: Fix tx_status mechanism

commit a9e79b116cc4d0057e912be8f40b2c2e5bdc7c43 upstream.

This change fix the TX ack mechanism in various ways:

- For NO_ACK tagged packets, we don't need to wait

wcn36xx: Fix tx_status mechanism

commit a9e79b116cc4d0057e912be8f40b2c2e5bdc7c43 upstream.

This change fix the TX ack mechanism in various ways:

- For NO_ACK tagged packets, we don't need to wait for TX_ACK indication
and so are not subject to the single packet ack limitation. So we don't
have to stop the tx queue, and can call the tx status callback as soon
as DMA transfer has completed.

- Fix skb ownership/reference. Only start status indication timeout
once the DMA transfer has been completed. This avoids the skb to be
both referenced in the DMA tx ring and by the tx_ack_skb pointer,
preventing any use-after-free or double-free.

- This adds a sanity (paranoia?) check on the skb tx ack pointer.

- Resume TX queue if TX status tagged packet TX fails.

Cc: stable@vger.kernel.org
Fixes: fdf21cc37149 ("wcn36xx: Add TX ack support")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1634567281-28997-1-git-send-email-loic.poulain@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

wcn36xx: Fix missing frame timestamp for beacon/probe-resp

When receiving a beacon or probe response, we should update the
boottime_ns field which is the timestamp the frame was received at.
(cf mac

wcn36xx: Fix missing frame timestamp for beacon/probe-resp

When receiving a beacon or probe response, we should update the
boottime_ns field which is the timestamp the frame was received at.
(cf mac80211.h)

This fixes a scanning issue with Android since it relies on this
timestamp to determine when the AP has been seen for the last time
(via the nl80211 BSS_LAST_SEEN_BOOTTIME parameter).

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1629992768-23785-1-git-send-email-loic.poulain@linaro.org

show more ...

wcn36xx: Fix missing frame timestamp for beacon/probe-resp

[ Upstream commit 8678fd31f2d3eb14f2b8b39c9bc266f16fa24b22 ]

When receiving a beacon or probe response, we should update the
boottime_ns f

wcn36xx: Fix missing frame timestamp for beacon/probe-resp

[ Upstream commit 8678fd31f2d3eb14f2b8b39c9bc266f16fa24b22 ]

When receiving a beacon or probe response, we should update the
boottime_ns field which is the timestamp the frame was received at.
(cf mac80211.h)

This fixes a scanning issue with Android since it relies on this
timestamp to determine when the AP has been seen for the last time
(via the nl80211 BSS_LAST_SEEN_BOOTTIME parameter).

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1629992768-23785-1-git-send-email-loic.poulain@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

wcn36xx: Specify ieee80211_rx_status.nss

Specify the number of spatial streams in ieee80211_rx_status. For non VHT
data-rates the wireless core doesn't care about this field, however for VHT
data-ra

wcn36xx: Specify ieee80211_rx_status.nss

Specify the number of spatial streams in ieee80211_rx_status. For non VHT
data-rates the wireless core doesn't care about this field, however for VHT
data-rates it does.

Every version of wcn36xx has one spatial stream, so specify nss for
wcn3620, wcn3660 and wcn3680 now.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200829033846.2167619-7-bryan.odonoghue@linaro.org

show more ...

wcn36xx: Fix warning due to bad rate_idx

The rate_idx is the index of the bitrate in the supported rate table.
However the 5Ghz band has a smaller legacy bitrate table than 2.4Ghz
since it does not

wcn36xx: Fix warning due to bad rate_idx

The rate_idx is the index of the bitrate in the supported rate table.
However the 5Ghz band has a smaller legacy bitrate table than 2.4Ghz
since it does not have the DSSS bitrates (1, 2, 5.5, 11).

So in 5Ghz band the index should adjusted accrodingly (-4).

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
[bod: Made sure fix is only applied if the rate_idx > n_bitrates]
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200829033846.2167619-6-bryan.odonoghue@linaro.org

show more ...

wcn36xx: Add 802.11ac MCS rates

This commit incorporates the 802.11ac table defined in downstream into
upstream wcn36xx.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by:

wcn36xx: Add 802.11ac MCS rates

This commit incorporates the 802.11ac table defined in downstream into
upstream wcn36xx.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200829033846.2167619-5-bryan.odonoghue@linaro.org

show more ...

wcn36xx: Fix software-driven scan

For software-driven scan, rely on mac80211 software scan instead
of internal driver implementation. The internal implementation
cause connection trouble since it ke

wcn36xx: Fix software-driven scan

For software-driven scan, rely on mac80211 software scan instead
of internal driver implementation. The internal implementation
cause connection trouble since it keep the antenna busy during
the entire scan duration, moreover it's only a passive scanning
(no probe request). Therefore, let mac80211 manages sw scan.

Note: we fallback to software scan if firmware does not report
scan offload support or if we need to scan the 5Ghz band (currently
not supported by the offload scan...).

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1598288035-19790-1-git-send-email-loic.poulain@linaro.org

show more ...

wcn36xx: Use sequence number allocated by mac80211

Instead of using the firmware generated sequence number, use the one
already allocated by the mac80211 layer. This allows better control
of the seq

wcn36xx: Use sequence number allocated by mac80211

Instead of using the firmware generated sequence number, use the one
already allocated by the mac80211 layer. This allows better control
of the sequence numbers and avoid to rely on same sequence for Data,
QOS Data and QOS Null Data packets.

Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1595586052-16081-7-git-send-email-loic.poulain@linaro.org

show more ...