- 20 Dec, 2018 7 commits
-
-
Sara Sharon authored
In iwl_mvm_tx_skb_non_sta(), in case of managed interface, the AP station was supposed to be used for multicast frames instead of the auxiliary station to avoid frames possibly sent to an absent P2P GO. However, when moving to DQA mode, this was broken as no valid queue was assigned. This is fixed by a recent patch that directs all non-offchannel traffic to ap station earlier in the TX path. However, the broken, and now dead code, remained. Remove it. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Sara Sharon authored
When building AMSDU for gen2, code uses iwl_tx_cmd. The only updated field is len, which is in the same location, so it is not a bug. However, it is a bit confusing and error prone, so change it. Signed-off-by:
-
YueHaibing authored
Fix smatch warning: drivers/net/wireless/intel/ipw2x00/ipw2100.c:5606 shim__set_security() warn: always true condition '(sec->active_key <= 3) => (0-3 <= 3)' drivers/net/wireless/intel/ipw2x00/ipw2200.c:10725 shim__set_security() warn: always true condition '(sec->active_key <= 3) => (0-3 <= 3)' Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Jia-Ju Bai authored
The function cw1200_bss_info_changed() and cw1200_hw_scan() can be concurrently executed. The two functions both access a possible shared variable "frame.skb". This shared variable is freed by dev_kfree_skb() in cw1200_upload_beacon(), which is called by cw1200_bss_info_changed(). The free operation is protected by a mutex lock "priv->conf_mutex" in cw1200_bss_info_changed(). In cw1200_hw_scan(), this shared variable is accessed without the protection of the mutex lock "priv->conf_mutex". Thus, concurrency use-after-free bugs may occur. To fix these bugs, the original calls to mutex_lock(&priv->conf_mutex) and mutex_unlock(&priv->conf_mutex) are moved to the places, which can protect the accesses to the shared variable. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
-
Stefan Wahren authored
Since commit 1204aa17 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag") the Raspberry Pi 3 A+ (BCM43455) isn't able to operate in AP mode with hostapd (device_ap_sme=1 use_monitor=0): brcmfmac: brcmf_cfg80211_stop_ap: setting AP mode failed -52 So add the missing mgmt_stypes for AP mode to fix this. Fixes: 1204aa17 ("brcmfmac: set WIPHY_FLAG_HAVE_AP_SME flag") Suggested-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Acked-by:
-
Stijn Tintel authored
When the update_connect_param callback is set, nl80211 expects the flag WIPHY_FLAG_SUPPORTS_FW_ROAM to be set as well. However, this flag is only set when modparam roamoff=0, while the callback is set unconditionally. Since commit 7f9a3e15 this causes a warning in wiphy_register, which breaks brcmfmac. Disable the update_connect_param callback when roamoff=0 to fix this. Fixes: 7f9a3e15 ("nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS") Cc: Stable <stable@vger.kernel.org> # 4.19+ Signed-off-by:
Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by:
Stijn Tintel <stijn@linux-ipv6.be> Signed-off-by:
-
Yangtao Li authored
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by:
Yangtao Li <tiny.windzz@gmail.com> Signed-off-by:
-
- 14 Dec, 2018 16 commits
-
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2018-12-14' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Third batch of iwlwifi patches intended for v4.21 * Some cleanups in the HW configuration structures; * More work on the debugging infrastructure; * Fixes related to 802.11ax; * Other cleanups and small fixes;
-
Emmanuel Grumbach authored
We used to have many versions of statistics notification coming from the firmware. In one of the cleanup patches, we forgot to clean the code that checks if data->general is set. Since it is always set, remove the check. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Sara Sharon authored
command len is set too early in the code, since when building AMSDU, the size changes. This causes the byte count table to have the wrong size. Fixes: a0ec0169 ("iwlwifi: support new tx api") Signed-off-by:
-
Shaul Triebitz authored
UL_DL is irrelevant to HE TRIG_BASED PPDU. Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
-
Shaul Triebitz authored
We may have the L-SIG length depending on the phy_data info type; add it to radiotap when we do. Move getting the phy_data out one layer up and the info type into it so we can use this data more generically. We need to call the iwl_mvm_rx_he() function for other reasons as well, so can't just combine all of that into something like iwl_mvm_parse_phy_data(). Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Shaul Triebitz authored
The firmware changed the PHY data API, so follow suit. Some data is now available even for HT/VHT frames, so the info type in the metadata was changed. This change isn't backwards compatible, but 1) the firmware with the old API was never released; 2) the only overlap in the info type field is from the old type of TB to the new of HT, so this basically just means that with older FW and newer driver the data will be considered missing. While at it, remove the extra code to set the LTF syms corresponding to the streams and use the data from the device instead - we don't really need this in any case other than when we have it from the device. As the new API gives use the spatial reuse 1-4 fields for trigger-based PPDUs, also expose that to radiotap. Signed-off-by: -
Sara Sharon authored
When removing the driver, the following flow can happen: 1. host command is in progress, for example at index 68. 2. RX interrupt is received with the response. 3. Before it is processed, the remove flow kicks in, and calls iwl_pcie_txq_unmap. The function cleans all DMA, and promotes the read pointer to 69. 4. RX thread proceeds with the processing, and is calling iwl_pcie_cmdq_reclaim, which will print this error: iwl_pcie_cmdq_reclaim: Read index for DMA queue txq id (0), index 4 is out of range [0-256] 69 69. Detect this situation, and avoid the print. Change it to warning while at it, to make such issues more noticeable in the future. Signed-off-by:
-
Avraham Stern authored
When traffic load is not low or low latency is active, TCM schedules re-evaluation work so in case traffic stops TCM will detect that traffic load has become low or that low latency is no longer active. However, if TCM is paused when the re-evaluation work runs, it does not re-evaluate and the re-evaluation work is no longer scheduled. As a result, TCM will not indicate that low latency is no longer active or that traffic load is low when traffic stops. Fix this by forcing TCM re-evaluation when TCM is resumed in case low latency is active or traffic load is not low. Signed-off-by:
Avraham Stern <avraham.stern@intel.com> Signed-off-by:
-
Luca Coelho authored
Now that nvm_calib_ver is not checked in opmodes other than dvm, we can remove it from all irrelevant configurations. Signed-off-by: -
Luca Coelho authored
This function is only half-used by mvm (i.e. only the nvm_version part matters, since the calibration version is irrelevant), so it's pointless to export it from iwlwifi. If mvm uses this function, it has the additional complexity of setting the calib version to a bogus value on all cfg structs. To avoid this, move the function to dvm and make a simple comparison of the nvm_version in mvm instead. Signed-off-by: -
Luca Coelho authored
These macros are useless because each one of them is used only once and the element they are assigned to is already pretty clear about what they mean, "nvm_hw_section_num". Signed-off-by: -
Luca Coelho authored
Using OTP_LOW_IMAGE_SIZE_FAMILY_8000/9000/22000 only obfuscates the actual values, since these 3 are the same. Redefine the values per size so it's easier to understand and compare the different configurations. Signed-off-by: -
Sara Sharon authored
Call the previously introduced apply points entry point when reaching an apply point. Signed-off-by:
-
Sara Sharon authored
Add support for ini triggers. Signed-off-by:
-
Sara Sharon authored
When ini TLVs are loaded, dump data according to the stored configuration. Signed-off-by:
-
Luca Coelho authored
The ht_params, nvm_ver, nvm_calib_ver and max_ht_ampdu_exponent elements in 9000 devices are always the same. Move them to the common macro. Signed-off-by:
-
- 13 Dec, 2018 17 commits
-
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.c: In function 'translate_rx_signal_stuff': drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.c:309:6: warning: variable 'type' set but not used [-Wunused-but-set-variable] It never used since commit 21e4b072 ("rtlwifi: rtl8821ae: Move driver from staging to regular tree") Signed-off-by:
-
Pan Bian authored
entry is released via usb_put_urb just after calling usb_submit_urb. However, entry is used if the submission fails, resulting in a use after free bug. The patch fixes this. Signed-off-by:
Pan Bian <bianpan2016@163.com> ACKed-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/broadcom/b43/phy_n.c: In function 'b43_nphy_op_recalc_txpower': drivers/net/wireless/broadcom/b43/phy_n.c:5898:7: warning: variable 'tx_pwr_state' set but not used [-Wunused-but-set-variable] drivers/net/wireless/broadcom/b43/phy_n.c:6047:20: warning: variable 'tmp2' set but not used [-Wunused-but-set-variable] 'tx_pwr_state' never used since introduction in commit 8615eb28 ("b43: N-PHY: support setting custom TX power") 'tmp2' not used any more since commit c002831a ("b43: N-PHY: use helper for checking IPA") Signed-off-by:
-
Arnd Bergmann authored
When CONFIG_NO_AUTO_INLINE is set, we get a false-postive warning for the brcmf_fw_request_nvram_done() function, after gcc figures out that brcmf_fw_nvram_from_efi() might not set the 'data_len' variable, but fails to notice that it always returns NULL: drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c: In function 'brcmf_fw_request_nvram_done': drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c:560:11: error: 'data_len' may be used uninitialized in this function [-Werror=maybe-uninitialized] Mark it 'inline' to force gcc to understand this. Fixes: ce2e6db5 ("brcmfmac: Add support for getting nvram contents from EFI variables") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Wright Feng authored
AOS is a part of the SDIOD core that becomes active when the rest of SDIOD is sleeping to keep SDIO bus alive responding to reduced set of commands. Transaction between AOS and SDIOD is not protected, and if cmd 52 is received in AOS and in the middle of response state changed from AOS to SDIOD, response is corrupted and it causes to SDIO Host controller to hang. Command decode for below chips are disabled in this commit: - 4339 - 4345 - 4354 - 4373 Reviewed-by:
Wright Feng <wright.feng@cypress.com> Signed-off-by:
Double Lo <double.lo@cypress.com> Signed-off-by:
Madhan Mohan R <madhanmohan.r@cypress.com> Signed-off-by:
Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by:
-
Chi-Hsien Lin authored
Use chipcommon sr_control0 register to check 4373 sr support. Reviewed-by:
-
Naveen Gupta authored
The number of words that the read FIFO has to contain except the end of frame before sends data back to the host. Max watermark = (512B - 2* (BurstLength))/4 = (512 - 128)/4 = 384/4 = 0x60 so if burst length (i.e. BurstLength = 64) is increased, watermark has to be reduced. This is the optimal setting for this chip. Reviewed-by:
Naveen Gupta <naveen.gupta@cypress.com> Signed-off-by:
-
Chi-Hsien Lin authored
GCI core is needed for ULP operation. Allow GCI core enumuration with below changes: - Allow GCI to be added to core list even when it doesn't have a wrapper. - Allow 8K address space size. - Don't overwrite the address value when an additional size descriptor is in place. Reviewed-by:
-
Chi-Hsien Lin authored
CYW43012 is a 1x1 802.11a/b/g/n Dual-Band HT20, 256-QAM/Turbo QAM. It is an Ultra Low Power WLAN+BT combo chip. Reviewed-by:
Praveen Babu C <praveen.chandran@cypress.com> Signed-off-by:
-
Madhan Mohan R authored
Along with F2 watermark (existing) configuration, F1 MesBusyCtrl should be enabled & sdio device RX FIFO watermark should be configured to avoid overflow errors. Reviewed-by:
-
Wright Feng authored
We got SDIO_CRC_ERROR with 4373 on SDR104 when doing bi-directional throughput test. Enable watermark to 256 to guarantee the operation stability. Reviewed-by:
-
Winnie Chang authored
Add the raw 4354 PCIe device ID for unprogrammed Cypress boards. Reviewed-by:
Arend Van Spriel <arend@broadcom.com> Signed-off-by:
Winnie Chang <winnie.chang@cypress.com> Signed-off-by:
-
Chung-Hsien Hsu authored
Firmware inform the driver about tx status by normal tx status signal or compressed tx status signal. This patch adds support to handle the compressed tx status signal. Signed-off-by:
Chung-Hsien Hsu <stanley.hsu@cypress.com> Signed-off-by:
-
Wright Feng authored
The frameburst feature can enable per-packet framebursting in firmware side and get higher TX throughput in High Throughput(HT) mode. To enhance TX throughput, we enable frameburst mode in default firmware setting. Signed-off-by:
-
Wright Feng authored
The credit numbers are static and tunable per chip in firmware side. However the credit number may be changed that is based on packet pool length and will send BRCMF_E_FIFO_CREDIT_MAP event to notify host driver updates the credit numbers during interface up. The purpose of this patch is making host driver has ability of updating the credit numbers when receiving the BRCMF_E_FIFO_CREDIT_MAP event. Signed-off-by:
-
Brian Norris authored
Comparing the existing TX_BITRATE parsing code (in mwifiex_parse_htinfo()) with the RX bitrate histograms in debugfs.c, it appears that the rxpd_rate and rxpd_htinfo fields have the same format. At least, they give reasonable results when I parse them this way. So this patch adds support for RX_BITRATE to our station info dump. Along the way, I add legacy bitrate parsing into the same function, using the debugfs code (mwifiex_histogram_read() and mwifiex_adjust_data_rate()) as reference. Additionally, to satisfy the requirements of NL80211_STA_INFO_RX_BITRATE, I skip logging the bitrate of multicast packets. This shouldn't add a lot of overhead to the RX path, as there are already several similar 802.3 header checks in this same codepath. We can also bias the branch behavior to favor unicast, as that's the common performance-sensitive case. I'd consider this support somewhat experimental, as I have zero documentation from Marvell. But the existing driver code gives me good reason to think this is correct. I've tested this on a few different 802.11{a,b,g,n,ac} networks, and the reported bitrates look good to me. Signed-off-by:Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Brian Norris authored
This function converts some firmware-specific parameters into cfg80211 'rate_info' structures. It currently assumes it's dealing only with TX bitrate, but the RX bitrate looks to be the same, so refactor this function to be reusable. Signed-off-by:
-
