Jason Yan [Mon, 4 May 2020 11:33:21 +0000 (19:33 +0800)]
rtlwifi: rtl8188ee: remove Comparison to bool in rf.c
Fix the following coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rf.c:476:6-14: WARNING:
Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rf.c:54:5-22: WARNING:
Comparison to bool
Colin Ian King [Fri, 1 May 2020 17:39:00 +0000 (18:39 +0100)]
libertas_tf: avoid a null dereference in pointer priv
Currently there is a check if priv is null when calling lbtf_remove_card
but not in a previous call to if_usb_reset_dev that can also dereference
priv. Fix this by also only calling lbtf_remove_card if priv is null.
It is noteable that there don't seem to be any bugs reported that the
null pointer dereference has ever occurred, so I'm not sure if the null
check is required, but since we're doing a null check anyway it should
be done for both function calls.
Addresses-Coverity: ("Dereference before null check") Fixes: baa0280f08c7 ("libertas_tf: don't defer firmware loading until start()") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200501173900.296658-1-colin.king@canonical.com
gcc-10 reports a warning for mwifiex_cmd_802_11_key_material_v1:
drivers/net/wireless/marvell/mwifiex/sta_cmd.c: In function 'mwifiex_cmd_802_11_key_material_v1':
cc1: warning: writing 16 bytes into a region of size 0 [-Wstringop-overflow=]
In file included from drivers/net/wireless/marvell/mwifiex/sta_cmd.c:23:
drivers/net/wireless/marvell/mwifiex/fw.h:993:9: note: at offset 0 to object 'action' with size 2 declared here
993 | __le16 action;
| ^~~~~~
As the warning makes no sense, I reported it as a bug for gcc. In the
meantime using a temporary pointer for the key data makes the code easier
to read and stops the warning.
Justin Li [Mon, 4 May 2020 06:07:33 +0000 (01:07 -0500)]
brcmfmac: Add P2P Action Frame retry delay to fix GAS Comeback Response failure issue
It was observed that P2P Cert. 5.1.19: DEVUT responds to Service
Discovery request failed due to DUT did not send GAS Comeback Response
after receiving request from test bed P2P peer. To fix this issue,
we need to add P2P Action Frame retry delay to enhance P2P connection
under VSDB and noisy environment, since the peer can be in other
channels under VSDB.
Joseph Chuang [Mon, 4 May 2020 06:07:32 +0000 (01:07 -0500)]
brcmfmac: Fix P2P Group Formation failure via Go-neg method
P2P group formation fails since either peer is not able to send go-neg
confirm or dut is not able to send go-neg response. To fix this, retry
limit should be increased and dwell time check should be added.
Wright Feng [Mon, 4 May 2020 06:07:31 +0000 (01:07 -0500)]
brcmfmac: support the second p2p connection
With RSDB feature, firmware is able to support two P2P-AGO or two
P2P-GC at the same time. So we add the second p2p connection type
to map to the second P2P connection bsscfg.
Dejin Zheng [Mon, 4 May 2020 08:34:42 +0000 (16:34 +0800)]
rtw88: fix an issue about leak system resources
the related system resources were not released when pci_iomap() return
error in the rtw_pci_io_mapping() function. add pci_release_regions() to
fix it.
Fixes: e3037485c68ec1a ("rtw88: new Realtek 802.11ac driver") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200504083442.3033-1-zhengdejin5@gmail.com
Ping-Ke Shih [Mon, 4 May 2020 10:50:10 +0000 (18:50 +0800)]
rtw88: 8723d: add interface configurations table
Interface configuration table is used to configure PCI PHY that are
normally decided by design or bootstrap pin, and driver can do additional
settings by this table.
This ops is used to do statistics of false alarm periodically, and then
fine tune RX initial gain to adaptive different circumstance.
There are three steps, hold/get/reset counter, to retrieve false alarm
counters that consist of CCK and OFDM. In addition to false alarm
counters, it also collects CRC ok/error counters of CCK, OFDM and HT.
Ping-Ke Shih [Mon, 4 May 2020 10:50:07 +0000 (18:50 +0800)]
rtw88: 8723d: some chips don't support LDPC
Some chips are not able to receive LDPC packets. Add an attribute
to rtw_chip_info to determine if the LDPC capability in [ht/vht]_cap
should be advertised or not.
Ping-Ke Shih [Mon, 4 May 2020 10:50:06 +0000 (18:50 +0800)]
rtw88: handle C2H_CCX_TX_RPT to know if packet TX'ed successfully
TX status report of 8723D differs from 8822B/8822C, it uses
C2H_CCX_TX_RPT (0x03) with different format. With sequence number
and TX status, driver can know if certain packet was transmitted
successfully.
Ping-Ke Shih [Mon, 4 May 2020 10:50:05 +0000 (18:50 +0800)]
rtw88: 8723d: Add set_channel
Set MAC/BB/RF register according to specified channel. The function
rtw_set_channel_mac() is used to set MAC registers, but 8723D only need
some of them.
For channel 14, we need to set different CCK DFIR values, so restore the
values when channel 1 to 13 is selected.
Spur calibration is needed in channel 13 and 14, and we do notch if spur
is over threshold.
Ping-Ke Shih [Mon, 4 May 2020 10:50:04 +0000 (18:50 +0800)]
rtw88: 8723d: Add query_rx_desc
This ops is used to parse RX descriptor to know the length of received
packet and containing PHY status. If PHY status is existing, the order is
RX descriptor, PHY status and then packet.
There are two types of PHY status, named CCK and OFDM. Their size are the
same, but formats are different.
struct ieee80211_rx_status is also filled depends on above information.
Ping-Ke Shih [Mon, 4 May 2020 10:50:03 +0000 (18:50 +0800)]
rtw88: 8723d: Add DIG parameter
To improve user experience in field, we need DIG to adjust RX initial gain
depends on field situation. Since each chip has its own register address,
this commit defines 8723d specific address.
Jason Yan [Sun, 26 Apr 2020 10:37:09 +0000 (18:37 +0800)]
ray_cs: use true,false for bool variable
Fix the following coccicheck warning:
drivers/net/wireless/ray_cs.c:2797:5-14: WARNING: Comparison of 0/1 to
bool variable
drivers/net/wireless/ray_cs.c:2798:2-11: WARNING: Assignment of 0/1 to
bool variable
ath11k: Replace zero-length array with flexible-array
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
Masashi Honma [Mon, 4 May 2020 21:44:43 +0000 (06:44 +0900)]
ath9k_htc: Silence undersized packet warnings
Some devices like TP-Link TL-WN722N produces this kind of messages
frequently.
kernel: ath: phy0: Short RX data len, dropping (dlen: 4)
This warning is useful for developers to recognize that the device
(Wi-Fi dongle or USB hub etc) is noisy but not for general users. So
this patch make this warning to debug message.
ath6kl: Replace zero-length array with flexible-array
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This patch follows up on a bug-report by Frank Schäfer that
discovered P2P GO wasn't working with wpa_supplicant.
This patch removes part of the broken P2P GO support but
keeps the vif switchover code in place.
Cc: <stable@vger.kernel.org>
Link: <https://lkml.kernel.org/r/3a9d86b6-744f-e670-8792-9167257edef8@googlemail.com> Reported-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200425092811.9494-1-chunkeey@gmail.com
John Crispin [Tue, 5 May 2020 07:42:03 +0000 (10:42 +0300)]
ath11k: add tx hw 802.11 encapsulation offloading support
This patch adds support for ethernet rxtx mode to the driver. The feature
is enabled via a new module parameter. If enabled to driver will enable
the feature on a per vif basis if all other requirements were met.
ath11k: fix resource unavailability for htt stats after peer stats display
htt stats are not working after htt peer stats display
and also after htt peer stats reset. Trying to dump htt
stats shows "Resource temporarily unavailable".
This is because of "ar->debug.htt_stats.stats_req" member is being
consecutively used for all htt stats without being reset
during the previous usage. Hence assigning NULL to this member
after freeing the allocated memory fixes the issue.
Jason Yan [Mon, 4 May 2020 11:33:36 +0000 (19:33 +0800)]
ath11k: use true,false for bool variables
Fix the following coccicheck warning:
drivers/net/wireless/ath/ath11k/dp_rx.c:2964:1-39: WARNING: Assignment
of 0/1 to bool variable
drivers/net/wireless/ath/ath11k/dp_rx.c:2965:1-38: WARNING: Assignment
of 0/1 to bool variable
Wen Gong [Mon, 4 May 2020 09:03:14 +0000 (12:03 +0300)]
ath10k: remove the max_sched_scan_reqs value
The struct cfg80211_wowlan of NET_DETECT WoWLAN feature share the same
struct cfg80211_sched_scan_request together with scheduled scan request
feature, and max_sched_scan_reqs of wiphy is only used for sched scan,
and ath10k does not support scheduled scan request feature, so ath10k
does not set flag NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR, but ath10k
set max_sched_scan_reqs of wiphy to a non zero value 1, then function
nl80211_add_commands_unsplit of cfg80211 will set it support command
NL80211_CMD_START_SCHED_SCAN because max_sched_scan_reqs is a non zero
value, but actually ath10k not support it, then it leads a mismatch result
for sched scan of cfg80211, then application shill found the mismatch and
stop running case of MAC random address scan and then the case fail.
After remove max_sched_scan_reqs value, it keeps match for sched scan and
case of MAC random address scan pass.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029.
Tested with QCA6174 PCIe with firmware WLAN.RM.4.4.1-00110-QCARMSWP-1.
ath10k: Avoid override CE5 configuration for QCA99X0 chipsets
As the exisiting CE configurations are defined in global, there
are the chances of QCA99X0 family chipsets CE configurations
are getting changed by the ath10k_pci_override_ce_config()
function.
The override will be hit and CE5 configurations will be changed,
when the user bring up the QCA99X0 chipsets along with QCA6174
or QCA9377 chipset. (Bring up QCA99X0 family chipsets after
QCA6174 or QCA9377).
Hence, fixing this issue by moving the global CE configuration
to radio specific CE configuration.
brcmfmac: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
In doing this, make brcmf_debugfs_add_entry() return void as no one was
even paying attention to the return value.
Cc: Arend van Spriel <arend.vanspriel@broadcom.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Chi-Hsien Lin <chi-hsien.lin@cypress.com> Cc: Wright Feng <wright.feng@cypress.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafał Miłecki" <rafal@milecki.pl> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list.pdl@broadcom.com Cc: brcm80211-dev-list@cypress.com Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200429101526.GA2094124@kroah.com
Chi-Hsien Lin [Mon, 27 Apr 2020 07:00:02 +0000 (02:00 -0500)]
brcmfmac: only generate random p2p address when needed
P2p spec mentioned that the p2p device address should be the globally
administered address with locally administered bit set. Therefore,
follow this guideline by default.
When the primary interface is set to a locally administered address, the
locally administered bit cannot be set again. Generate a random locally
administered address for this case.
brcmfmac: remove arp_hostip_clear from brcmf_netdev_stop
The firmware does not respond ARP request and causes ping failure with
following steps:
1. Bring up interface
ifconfig wlan0 up or start wpa_supplicant
2. Set the IP address
ifconfig wlan0 192.168.100.10
3. Bring down interface or
ifconfig wlan0 down or kill wpa_supplicant
4. Bring up interface again and set the same IP address
5. Connect to AP(192.168.100.1) and ping to AP will be failed.
FMAC clears arp_hostip when bringing down the interface, but not set it
back if setting the same IP address. We are able to see the IP address
in interface info(inconfig wlan0) but the ping still cannot work because
the firmware ARP offload does not respond the ARP request.
Because of that, we remove "arp_hostip_clear" from function
"brcmf_netdev_stop"
brcmfmac: keep apsta enabled when AP starts with MCHAN feature
When starting station mode on wlan0 and AP mode on wlan1, the apsta will
be disabled and cause data stall on wlan0(station). The apsta feature
with MCHAN(Multi-Channel Concurrent) or RSDB(Real Simultaneous
Dual-Band) can make STA+AP work on two bands concurrently.
Because of that, we keep apsta enabled if firmware supports MCHAN or
RSDB features
ath11k: fix mgmt_tx_wmi cmd sent to FW for deleted vdev
In Multi-AP VAP scenario with frequent interface up-down, there is a
chance that ath11k_mgmt_over_wmi_tx_work() will dequeue a skb
corresponding to currently deleted/stopped vdev.
FW will assert on receiving mgmt_tx_wmi cmd for already deleted vdev.
Hence adding validation checks for arvif present on the corresponding
ar before sending mgmt_tx_wmi cmd.
Kalle Valo [Mon, 4 May 2020 08:45:47 +0000 (11:45 +0300)]
Merge tag 'iwlwifi-next-for-kalle-2020-04-24-2' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
First set of iwlwifi patches intended for v5.8
* TX queue debugfs improvements;
* Support for a few new FW API versions;
* Remove deprecated scan FW API version;
* New hw configs and other related changes;
* Support for NPK buffers in debugging;
* More debugging fetures;
* Some other small fixes and clean-ups;
# gpg: Signature made Fri 24 Apr 2020 04:39:43 PM EEST using RSA key ID 1A3CC5FA
# gpg: Good signature from "Luciano Roth Coelho (Luca) <luca@coelho.fi>"
# gpg: aka "Luciano Roth Coelho (Intel) <luciano.coelho@intel.com>"
This patch only effect SDIO chip, ath10k_mac_sta_get_peer_stats_info
has check for bitrate_statistics of hw_params, it is enabled only for
"qca6174 hw3.2 sdio".
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042.
Wen Gong [Mon, 27 Apr 2020 08:04:15 +0000 (16:04 +0800)]
ath10k: add bitrate parse for peer stats info
The rate code and rate kbps report by WMI_TLV_PEER_STATS_INFO_EVENTID
from firmware contains all the bitrate info which include OFDM, CCK,
HT/VHT, and mac80211 need the struct rate_info which include below
parameters:
flags: bitflag of flags from &enum rate_info_flags
mcs: mcs index if struct describes an HT/VHT/HE rate
legacy: bitrate in 100kbit/s for 802.11abg
nss: number of streams (VHT & HE only)
bw: bandwidth (from &enum rate_info_bw)
For OFDM/CCK, its rate kbps indicate the bitrate, for HT/VHT, mac80211
need the above 5 parameters to cacluate the bitrate and show by iw.
After parse the bitrate info, iw show the correct rx bitrate:
Wen Gong [Mon, 27 Apr 2020 08:04:14 +0000 (16:04 +0800)]
ath10k: add rx bitrate report for SDIO
For SDIO chip, its rx indication is struct htt_rx_indication_hl, which
does not include the bitrate info as well as PCIe, for PCIe, it use
function ath10k_htt_rx_h_rates to parse the bitrate info in struct
rx_ppdu_start and then report it to mac80211 via ieee80211_rx_status.
SDIO does not have the same info as PCIe, then iw command can not get
the rx bitrate by "iw wlan0 station dump".
for example, it always show 6.0 MBit/s
localhost ~ # iw wlan0 link
Connected to 3c:28:6d:96:fd:69 (on wlan0)
SSID: kukui_test
freq: 5180
RX: 111800 bytes (595 packets)
TX: 35419 bytes (202 packets)
signal: -41 dBm
rx bitrate: 6.0 MBit/s
This patch is to send WMI_TLV_REQUEST_PEER_STATS_INFO_CMDID to firmware
for ath10k_sta_statistics and save the rx bitrate for WMI event
WMI_TLV_PEER_STATS_INFO_EVENTID.
This patch only effect SDIO chip, ath10k_mac_sta_get_peer_stats_info
has check for bitrate_statistics of hw_params, this patch only enable
it for "qca6174 hw3.2 sdio".
Tested with QCA6174 SDIO firmware WLAN.RMH.4.4.1-00042.
Wen Gong [Mon, 27 Apr 2020 08:04:13 +0000 (16:04 +0800)]
ath10k: enable firmware peer stats info for wmi tlv
For wmi tlv type, firmware disable peer stats info by default, after
enable it, firmware will report WMI_TLV_PEER_STATS_INFO_EVENTID if
ath10k send WMI_TLV_REQUEST_PEER_STATS_INFO_CMDID to firmware.
Enable it will only set a flag in firmware, firmware will not report
it without receive request WMI command.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042.
ADC & I/Q calibrations could take infinite time to comple, since they
depend on received frames. In particular the I/Q mismatch calibration
requires receiving of OFDM frames for completion. But in the 2.4GHz
band, a station could receive only CCK frames for a very long time.
And while we wait for the completion of one of the mentioned
calibrations, the NF calibration is blocked. Moreover, in some
environments, I/Q calibration is unable to complete until a correct
noise calibration will be performed due to AGC behaviour.
In order to avoid delaying NF calibration on forever, limit the maximum
duration of ADCs & I/Q calibrations. If the calibration is not completed
within the maximum time, it will be interrupted and a next calibration
will be performed. The code that selects the next calibration has been
reworked to the loop so incompleted calibration will be respinned later.
Ð\90 maximum calibration time of 30 seconds was selected to give the
calibration enough time to complete and to not interfere with the long
(NF) calibration.
Previously after the calibration validity period is over,
calibrations are invalidated in a one at time manner. So, for AR9002
family, which has three calibrations, the full recalibration interval
becomes 3 x ATH_RESTART_CALINTERVAL. And each next calibration will be
separated by the ATH_RESTART_CALINTERVAL time from a previous one.
It seems like it is better to do whole recalibration at once. Also, this
change makes the driver behaviour a little simpler. So, invalidate all
calibrations at once at the end of the calibration validity interval.
This change affects only AR9002 chips family, since the AR9003 utilize
only a single calibration.
NF calibration and other elements of long calibration are usually faster
than ADCs & I/Q calibrations due to independence of receiption of the
OFDM signal. Moreover sometime I/Q calibration can not be completed at
all without preceding NF calibration. This is due to AGC, which has a
habit to block a weak signal without regular NF calibration. Thus, we do
not need to deferr the long calibration forever.
So, if the long calibration is requested, then deferr the ADCs & I/Q
calibration(s) and run the longcal (the NF calibration in particular) to
obtain fresh noise data.
Each of AGC & I/Q calibrations can take a long time. Long calibration
and NF calibration in particular are forbiden for parallel run with
ADC & I/Q calibrations. So, the chip could not be ready to perform the
long calibration at the time of request. And a request to perform the
long calibration may be lost.
In order to fix this, preserve the long calibration request as a
calibration state flag and restore the long calibration request each
time the calibration function is called again (i.e. on each subsequent
ivocation of the short calibration).
This feature will be twice useful after the next change, which will
make it possible to start the long calibration before all ADCs & I/Q
calibrations are completed.
The NFCAL_PENDING flag is set by the ath9k_hw_start_nfcal() routine,
so there is no reason to set it manually after calling it during the
AR9002 calibrations initialization.
ADC calibration is only required for a 80 MHz sampling rate (i.e. for
40 MHz channels), when the chip utilizes the pair of ADCs in interleved
mode. Calibration on a 20 MHz channel will never be completed.
Previous channel check is trying to exclude all channels where the
calibration will get stuck. It effectively blocks the calibration run
for HT20 channels, but fails to exclude 20 MHz channels without HT (e.g.
legacy mode channels).
Fix this issue by reworking the channel check to explicitly allow ADCs
gain & DC offset calibrations for HT40 channels only. Also update the
complicated comment to make it clear that these calibrations are for
multi-ADC mode only.
Stuck ADCs calibration blocks the NF calibration, what could make it
impossible to work in a noisy evironment: too big Rx attentuation,
invalid RSSI value, etc. So this change is actually more of a NF
calibration fix rather then the ADC calibration fix.
rtw88: fix sparse warnings for download firmware routine
sparse warnings: (new ones prefixed by >>)
>> drivers/net/wireless/realtek/rtw88/mac.c:653:5: sparse: sparse:
symbol '__rtw_download_firmware' was not declared. Should it be static?
>> drivers/net/wireless/realtek/rtw88/mac.c:817:5: sparse: sparse:
symbol '__rtw_download_firmware_legacy' was not declared. Should it be
static?
Fixes: 15d2fcc6b2de ("rtw88: add legacy firmware download for 8723D devices") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200424101255.28239-1-yhchuang@realtek.com
Wen Gong [Thu, 23 Apr 2020 02:41:34 +0000 (10:41 +0800)]
ath10k: add statistics of tx retries and tx failed when tx complete disable
When tx complete is disabled, all tx status will be set with status
HTT_TX_COMPL_STATE_ACK and indicate to mac80211 by ieee80211_tx_status,
then it does not have the statistics for retries and failed packets.
count of tx retries and tx failed of command "iw wlan0 station dump"
are both 0. If tx complete is not disabled, then firmware report the
tx status and ath10k indicate the status to mac80211, then mac80211
save the statistics and command "iw wlan0 station dump" show them.
for example:
localhost ~ # iw dev wlan0 station dump
Station 3c:28:6d:96:fd:69 (on wlan0)
inactive time: 5 ms
rx bytes: 1325012
rx packets: 6477
tx bytes: 85264
tx packets: 518
tx retries: 0
tx failed: 0
This patch only effect chips with tx complete disabled, e.g. SDIO.
with this patch, output of command "iw dev wlan0 station dump":
Station c4:04:15:5d:97:22 (on wlan0)
inactive time: 608 ms
rx bytes: 180366
rx packets: 991
tx bytes: 98765577
tx packets: 64624
tx retries: 14682
tx failed: 47086
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042.
Wen Gong [Thu, 23 Apr 2020 02:27:58 +0000 (10:27 +0800)]
ath10k: enable rx duration report default for wmi tlv
When run command "iw dev wlan0 station dump", the rx duration is 0.
When firmware indicate WMI_UPDATE_STATS_EVENTID, extended flag of
statsis not set by default, so firmware do not report rx duration.
one sample:
localhost # iw wlan0 station dump
Station c4:04:15:5d:97:22 (on wlan0)
inactive time: 48 ms
rx bytes: 21670
rx packets: 147
tx bytes: 11529
tx packets: 100
tx retries: 88
tx failed: 36
beacon loss: 1
beacon rx: 31
rx drop misc: 47
signal: -72 [-74, -75] dBm
signal avg: -71 [-74, -75] dBm
beacon signal avg: -71 dBm
tx bitrate: 54.0 MBit/s MCS 3 40MHz
rx bitrate: 1.0 MBit/s
rx duration: 0 us
This patch enable firmware's extened flag of stats by setting flag
WMI_TLV_STAT_PEER_EXTD of ar->fw_stats_req_mask which is set in
ath10k_core_init_firmware_features via WMI_REQUEST_STATS_CMDID.
After apply this patch, rx duration show value with the command:
Station c4:04:15:5d:97:22 (on wlan0)
inactive time: 883 ms
rx bytes: 44289
rx packets: 265
tx bytes: 10838
tx packets: 93
tx retries: 899
tx failed: 103
beacon loss: 0
beacon rx: 78
rx drop misc: 46
signal: -71 [-74, -76] dBm
signal avg: -70 [-74, -76] dBm
beacon signal avg: -70 dBm
tx bitrate: 54.0 MBit/s MCS 3 40MHz
rx bitrate: 1.0 MBit/s
rx duration: 358004 us
This patch do not have side effect for all chips, because function
ath10k_debug_fw_stats_request is already exported to debugfs
"fw_stats" and WMI_REQUEST_STATS_CMDID is safely sent after condition
checked by ath10k_peer_stats_enabled in ath10k_sta_statistics.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042.
we are sending the reo flush command for the deleted peer
tid after the ageout period reaches 1 second. This handling
causes reo ring get full when more than 128 clients are
disconnected continuously. so added the count for flush list
and reo flush command is triggered after the list count reaches
the threshold value, it is configured as 64 (half of the reo ring).
This will avoid the situation where reo ring get full.
iwlwifi: pcie: add new structs for So devices with long latency
Some So devices have a longer wake latency. To support this properly,
add new cfg structs for them so the driver will inform the FW about
the need to use another xtal and use a higher wait value during state
transitions.
iwlwifi: pcie: add new structure for Qu devices with medium latency
Some Qu devices require an intermediate amount of time to wake up and
for LTR notifications, so add a new structure with the correct values
for them and change the corresponding devices to use it.
iwlwifi: acpi: read TAS table from ACPI and send it to the FW
Read the Time Averaged SAR (TAS) table from ACPI and if TAS
feature is enabled in the FW send the black list countries
which TAS is disabled in to the FW
Gil Adam [Sat, 18 Apr 2020 08:08:47 +0000 (11:08 +0300)]
iwlwifi: mvm: add framework for specific phy configuration
Add framework for supporting specific PHY filter configuration,
which allows for application of various FW defined PHY filters
(one per antenna). Change phy_cfg_cmd to the new API (ver3).
Reading of configuration from platform's ACPI tables to be added
later when tables are defined.
Johannes Berg [Fri, 17 Apr 2020 10:21:40 +0000 (13:21 +0300)]
iwlwifi: pcie: gen2: minor code cleanups in byte table update
One line should be indented less, otherwise it looks like it
belongs into the parentheses, which clearly it doesn't; also
some variables can move into their respective if branches.
Johannes Berg [Fri, 17 Apr 2020 10:21:38 +0000 (13:21 +0300)]
iwlwifi: pcie: use seq_file for tx_queue debugfs file
On newer hardware, the tx_queue debugfs file would need to
allocate 37.5kib data since there are 512 queues, which is
too much. Rather than resorting to kludges like kvmalloc(),
use the seq_file API to print out the data.
While at it, also fix a NULL pointer dereference here, the
txq pointer from trans_pcie->txqs[] may be NULL if that
queue hasn't been allocated.
iwlwifi: support version 9 of WOWLAN_GET_STATUS notification
Add support for the new WOWLAN_GET_STATUS notification that contains a
new element that informs the driver of TIDs whose BA sessions were
closed during suspend.
Note that the new functionality of handling these closed sessions is not
implemented in this patch it. It only aligns to the new API version.
The fw already supports scan api v14 and the firmware version that
supports only v13 was not published, so we can remove support for v13 in
the driver.
Wen Gong [Wed, 22 Apr 2020 08:47:19 +0000 (16:47 +0800)]
ath10k: drop the TX packet which size exceed credit size for sdio
sdio chip use DMA buffer to receive TX packet from ath10k, and it has
limitation of each buffer, if the packet size exceed the credit size,
it will trigger error in firmware.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00017-QCARMSWP-1.
ath10k: Fix the invalid tx/rx chainmask configuration
The driver is allowing the invalid tx/rx chainmask configuration
(other than 1,3,7,15) set by the user. It causes the firmware
crash due to the invalid chainmask values.
Hence, reject the invalid chainmask values in the driver by not
sending the pdev set command to the firmware.
Implement rtw_chip_ops::phy_set_param and ::mac_init to initialize
mac/bb/rf, and they are used during interface up. The procedure contains
power on sequence registers, download firmware, load predefined parameters,
mac/bb/rf specific register and etc.
TX FIFO size is 32k and it was divided into 256 pages with 128 bytes.
A boundary is used to split pages into two parts, head part is used to
store TX packets coming from host, and tail part is reserved for special
purposes, such as beacon packet, null data packet and so on.
The TX packets coming from host have many categories, such as VO, VI, BE,
BK, MG and etc. When going into head part of TX FIFO, they are classified
to four priority queue named low, normal, high and extra priority queues.
Each priority queue occupies predefined number of page, if a certain
priority queue is full, TX packet will store into PUB priority queue.
Similarly, RX FIFO is 16k and split into two parts, head part is used to
store RX packets, and tail part is 128 bytes and used to store report.
Thus, we fill this boundary to register as well.
The txagc table is used to map rate_id and txagc register address and
mask, and ops set_tx_power_index uses this table to write TX power to
corresponding registers. Since 8723D is a 1x1 2.4G 11n chip, only CCK, OFDM
and HT_MCS 0-7 are listed in the table.
H2C queue is used to send command to firmware. Since 8723D doesn't support
this queue, this commit check wlan_cpu flag to avoid to set H2C related
registers.
rtw88: decompose while(1) loop of power sequence polling command
The power polling command is one kind of power sequence commands. It's used
to check hardware situation, and subsequent comamnds will be executed if
hardware is ready. A special case is PCIE must toggle BIT_PFM_WOWL and try
again if first try is failed.
In order to reduce indentation to understand the code easier, move polling
part to a separate function. Then, the 'while (1)...loop' is replaced by
two statements to do first try and retry.