Sparse warns:
drivers/net/wireless/ath/wcn36xx/txrx.c: note: in included file (through drivers/net/wireless/ath/wcn36xx/txrx.h):
drivers/net/wireless/ath/wcn36xx/wcn36xx.h:107:24: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/wcn36xx/wcn36xx.h:107:24: expected unsigned int [usertype]
drivers/net/wireless/ath/wcn36xx/wcn36xx.h:107:24: got restricted __be32 [usertype]
drivers/net/wireless/ath/wcn36xx/wcn36xx.h:107:24: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/wcn36xx/wcn36xx.h:107:24: expected unsigned int [usertype]
drivers/net/wireless/ath/wcn36xx/wcn36xx.h:107:24: got restricted __be32 [usertype]
Use void pointers and two separate variables to workaround the warning. Also
now the callers don't need any casting. There's actually cpu_to_be32_array()
available but decided to do minimal changes instead.
Compile tested only.
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20240320182449.3757215-3-kvalo@kernel.org
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 2aa56cca35 ("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
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
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
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
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: 6ea131acea ("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
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: 8a27ca3947 ("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
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: 84aff52e4f ("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
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
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
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: fdf21cc371 ("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
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: 512b191d96 ("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
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
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
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
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
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
This patch contains the following fixes:
- Use correct queue for submitting QoS packet. The queue id to use
is a one-to-one mapping with the TID.
- Don't encrypt a frame with IEEE80211_TX_INTFL_DONT_ENCRYPT flag.
- Use the 'special queue' for null packets, preventing the firmware
to submit it as AMPDU.
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-5-git-send-email-loic.poulain@linaro.org
The controller is capable of reporting TX indication which can be used
to report TX ack when IEEE80211_TX_CTL_REQ_TX_STATUS is set.
The support was only partially implemented.
The firmware can be configured for reporting event when a packet is
acked, without specifying which packet though. In order to send a
packet flagged with TX status callback, we need to stop the queue,
submit the packet and wait for the firmware ack event. Then the queue
can be restarted and mac80211 status callback called.
In case the packet is not acked, no ack event will be received,
therefore a timeout mechanism is introduced to restart the queue
and call the status cb in case no event is received after a 100ms.
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-3-git-send-email-loic.poulain@linaro.org
When wcn36xx_dxe_tx_frame() fails to transmit the TX frame, the driver
will call into ieee80211_free_txskb() for the skb in flight, so it'll no
longer be valid. Hence, we shouldn't keep a reference to it in ctl->skb.
Also, if the skb has IEEE80211_TX_CTL_REQ_TX_STATUS set, a pointer to
it will currently remain in wcn->tx_ack_skb, which will potentially lead
to a crash if accessed later.
Fix this by checking the return value of wcn36xx_dxe_tx_frame(), and
nullify wcn->tx_ack_skb again in case of errors. Move the assignment
of ctl->skb in wcn36xx_dxe_tx_frame() so it only happens when the
transmission is successful.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
wcn36xx_start_tx function retrieves the buffer descriptor from the
channel control queue to start filling tx buffer information. However,
nothing prevents this same buffer to be concurrently accessed in a
concurent tx call, leading to potential buffer coruption and firmware
crash (observed during iperf test). The channel control queue should
only be accessed and updated with the channel lock.
Fix this issue by using a local buffer descriptor which will be copied
in the thread-safe wcn36xx_dxe_tx_frame.
Note that buffer descriptor size is few bytes so the introduced copy
overhead is insignificant. Moreover, this allows to keep the locked
section minimal.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Ramon Fried <rfried@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Using the software based channel scan mechanism from mac80211 keeps us
offline for 10-15 second, we should instead issue a start_scan/end_scan
on each channel reducing this time.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath.git patches for 4.7. Major changes:
ath10k
* implement set_tsf() for 10.2.4 branch
* remove rare MSI range support
* remove deprecated firmware API 1 support
ath9k
* add module parameter to invert LED polarity
wcn36xx
* fixes to get the driver properly working on Dragonboard 410c
Makes the code a little easier to read.
Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
This enum is already perfectly aliased to enum nl80211_band, and
the only reason for it is that we get IEEE80211_NUM_BANDS out of
it. There's no really good reason to not declare the number of
bands in nl80211 though, so do that and remove the cfg80211 one.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When HW crypto is used, there's no need for the CCMP/GCMP MIC to
be available to mac80211, and the hardware might have removed it
already after checking. The MIC is also useless to have when the
frame is already decrypted, so allow indicating that it's not
present.
Since we are running out of bits in mac80211_rx_flags, make
the flags field a u64.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, wcn36xx only asks for a TX BA session if it has
already established one for RX. Thus, two wcn36xx devices cannot
do a-mpdu between themselves since they both wait for the other
to go first. Fix this by starting a BA session after a few QoS
data frames have been sent to a STA.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The pdu is part of the buffer descriptor, so it makes
sense that one function would fill both. Also, passing
the whole skb instead of just the header pointer to the
set_tx_data function paves the way for using its fields
for ampdu setup inside set_tx_data().
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
wcn36xx currently sends an incorrect sequence number into the BA session
setup firmware command: it should be saving or updating the ssn in the
TX_START ampdu_action callback instead of waiting until TX_OPERATIONAL.
However, we can sidestep the issue by letting the hardware generate the
sequence numbers for QoS frames, as is done in prima, so do that.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
bd->tx_comp is a single bit in a bitfield, so assigning
"info->flags & IEEE80211_TX_CTL_REQ_TX_STATUS" only happens
to work because TX_STATUS is defined to BIT(0); if it were
any other bit this assignment would fail.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This fixes problems seen with multiple softap clients and reconnecting
softap clients.
Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is more line with the names of the other members
Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The purpose of this housekeeping is to make some room for
VHT flags. The radiotap vendor fields weren't in use.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is a mac80211 driver for Qualcomm WCN3660/WCN3680 devices. So
far WCN3660/WCN3680 is available only on MSM platform.
Firmware can be found here:
https://www.codeaurora.org/cgit/external/hisense/platform/vendor/qcom-opensource/wlan/prima/tree/firmware_bin?h=8130_CS
Wiki page is available here:
http://wireless.kernel.org/en/users/Drivers/wcn36xx
A lot people made a contribution to this driver. Here is the list in
alphabetical order:
Eugene Krasnikov <k.eugene.e@gmail.com>
Kalle Valo <kvalo@qca.qualcomm.com>
Olof Johansson <dev@skyshaper.net>
Pontus Fuchs <pontus.fuchs@gmail.com>
Yanbo Li <yanbol@qti.qualcomm.com>
Signed-off-by: Eugene Krasnikov <k.eugene.e@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
