- 01 Feb, 2019 6 commits
-
-
Bernd Edlinger authored
This re-introduces the function rtl8723e_dm_refresh_rate_adaptive_mask. This function was present in a previous version of the code base, it works just fine for me -- as long as it is not using stale data. Unlike the original version of this function it avoids using dm.undec_sm_pwdb when no beacon was received. Fixed a style nit in rtl8723e_dm_init_rate_adaptive_mask. Signed-off-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Bernd Edlinger authored
When no beacon was received, the value in dm.undec_sm_pwdb is most likely out of date and should not be used to adjust the input path. Assume instead that the signal level is low. Fix the state machine in rtl8723e_dm_cck_packet_detection_thresh which did not clear pre_cck_fa_state when changing cur_cck_pd_state from CCK_PD_STAGE_LOWRSSI/CCK_FA_STAGE_LOW to CCK_PD_STAGE_HIGHRSSI and back again to CCK_PD_STAGE_LOWRSSI/CCK_FA_STAGE_LOW, the register RCCK0_CCA not written to 0x83 on the second change. Explicitly initialize pre_cck_fa_state/cur_cck_fa_state in rtl_dm_diginit. Signed-off-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Bernd Edlinger authored
This appears to trigger a firmware bug and causes severe problems with rtl8723ae PCI devices. When the power save mode is activated for longer periods of time the firmware stops to receive any packets. This problem was exposed by commit 873ffe15 ("rtlwifi: Fix logic error in enter/exit power-save mode"). Previously the power save mode was only active rarely and only for a short time so that the problem was not noticeable. Signed-off-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Kangjie Lu authored
sysfs_create_group() could fail. The fix checkes its return values and issue error messages if it fails. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Tomislav Požega authored
Current implementation of RT6352 support provides too high tx power at least on iPA/eLNA devices. Reduce amplification of variable gain amplifier by 6dB to match board target power of 17dBm. Transmited signal strength with this patch is similar to that of stock firmware or pandorabox firmware. Throughput measured with iperf improves. Device tested: Xiaomi Miwifi Mini. Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 31 Jan, 2019 1 commit
-
-
Luca Coelho authored
A call to iwl_mvm_add_rtap_sniffer_config() was missing due to a merge damage when I submitted the patch mentioned below. And this causes the following compilation warning: drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:195:13: warning: 'iwl_mvm_add_rtap_sniffer_config' defined but not used [-Wunused-function] static void iwl_mvm_add_rtap_sniffer_config(struct iwl_mvm *mvm, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix it by adding the if block that calls this function. Fixes: 9bf13bee ("iwlwifi: mvm: include configured sniffer AID in radiotap") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 30 Jan, 2019 2 commits
-
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2019-01-29' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Second batch of iwlwifi patches intended for v5.1 * A bunch of fixes for issues found with static analyzers; * Relicense the pcie submodule to dual GPL/BSD; * Reworked the TOF/CSI implementation; * Work on new debugging infra continues; * Some product name updates in the human-readable strings * Some more cleanups for the device configuration refactoring; * General bugfixes; * Other cleanups and small fixes;
-
https://github.com/nbd168/wirelessKalle Valo authored
first batch of mt76 patches for 5.1 * fixes for mt76x0/mt76x2 * energy detect regulatory compliance fixes * tx status handling fixes * preparation for MT7603 support * channel switch announcement support
-
- 29 Jan, 2019 31 commits
-
-
Shahar S Matityahu authored
The monitor buffer register address is wrong. Set the right address Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Fixes: c2d20201 ("iwlwifi: pcie: add firmware monitor capabilities") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Shahar S Matityahu authored
The driver sets dump_mask value instead of BIT(value). fix it by updating dump_mask correctly. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Fixes: 7a14c23d ("iwlwifi: dbg: dump data according to the new ini TLVs") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Shahar S Matityahu authored
The driver uses ignore_consec instead of dump_delay. Fix it by using dump_delay as expected. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Fixes: fe1b7d6c ("iwlwifi: add support for triggering ini triggers") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Shahar S Matityahu authored
in case of a user trigger while ini is enable we change FW_DBG_TRIGGER_USER to IWL_FW_TRIGGER_ID_USER_TRIGGER in iwl_fw_dbg_collect and then again we attempt to do so in _iwl_fw_error_ini_dump which causes to abort the dump. Fix it by removing the second check in _iwl_fw_error_ini_dump. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Fixes: 7a14c23d ("iwlwifi: dbg: dump data according to the new ini TLVs") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Shahar S Matityahu authored
Use the same flags we use in the legacy buffer allocation. Missing __GFP_NOWARN will cause an unwanted warning incase we fail to allocate. Missing __GFP_ZERO will give a buffer initially filled with garbage which can make debug difficult in case our wrap count is zero. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Fixes: d47902f9 ("iwlwifi: dbg: add apply point logic") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Shaul Triebitz authored
When MU EDCA params change, resend the STA_HE_CTXT command updating the MU EDCA params. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Shahar S Matityahu authored
In the regular flow, when we receive an assert, ieee80211_reconfig is called which reconfig the driver using iwl_mvm_mac_start. iwl_mvm_mac_start is clearing the restart bit and does dump collection. Prior to setting the device up, ieee80211_reconfig does not call iwl_mvm_mac_start since there is nothing to reconfig and we miss the dump collection of the assert. solve it by checking the restart bit before we stop the device and trigger a dump collection in case it is set. note that we don't need to do it in the fmac case since in fmac assert flow in iwl_fmac_nic_error we call iwl_fw_dbg_collect_desc so we can be sure that there will a dump collection in iwl_fmac_stop_device. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
In order to make more sense out of the captured radiotap data e.g. when the configured AID changes, add the currently configured AID to the radiotap data as a vendor extension field. This is made race-free by updating the included value from inside the RX path (using a notification wait) for the command response from the firmware, which thus means it's serialized with frame RX. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
The reorder buffer is bypassed because the firmware won't have any BA sessions, document this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Ihab Zhaika authored
update the product name for the some of the cards from the series of 9260 and 9560 Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Mordechay Goodstein authored
We introduce a new state for latency, force mode, in force mode you can enable always to be in low latency or always to be in non low latency. This is required for test mode in max TpT test. Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Emmanuel Grumbach authored
We maintain a timer for each Tx queue to detect stalls and be able to recover / debug. When we work in AP mode, we can freeze the Tx queue timer if a station goes to sleep, because we don't want to warn about stalls that are caused by faulty clients that don't wake up on time. This mechanism was applied to the queues of the clients, but the management queue was omitted. Fix that. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
David Spinadel authored
Change iwl_fw_channel_info structure so it can have channel number greater than 255. This is needed for 6 GHz channel numbers. Change all relevant structs and member accesses accordingly. The new API is indicated by a TLV capability bit. Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Implement CSI (channel estimation matrix) reporting in the mvm driver, if the firmware has the capability. Currently only a debugfs API is provided as the API is still under discussion. For now, RX aggregation must be disabled to use this feature on data frames as we haven't found a good way to attach the data to A-MPDUs, given complexities with multi-queue. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Add the location/time-of-flight/FTM APIs that we'll use in follow-up patches to implement FTM responder and initiator. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Andrei Otcheretianski authored
Some buggy APs stop sending beacons, but continue to ack our null data packets or even run some traffic. It's better not to stick connected to such an AP forever, so disconnect after some larger beacon loss threshold is crossed. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
That's what we pass, and we don't want/need any negative values. Found by sparse/smatch. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
If we're in the else branch of checking "tt->state == IWL_TI_CT_KILL" so there's no point in checking "tt->state != IWL_TI_CT_KILL" again. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
This is an ancient (~2015) implementation that no longer matches the firmware in any way, and most likely never worked. Remove all of it so it can be reintroduced properly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Sara Sharon authored
TX path lock was introduced in order to prevent out of order invocations of TX. This can happen in the following flow: TX path invoked from net dev Packet dequeued TX path invoked from RX path Packet dequeued Packet TXed Packet TXed However, we don't really need a lock. If TX path is already invoked from some location, other paths can simply abort their execution, instead of waiting to the first path to finish, and then discover queue is (likely) empty or stopped. Replace the lock with an atomic variable to track TX ownership. This simplifies the locking dependencies between RX and TX paths, and should improve performance. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
The current code assigns the reference, and then goes to increment it if the toggle bit has changed. That way, we get Toggle 0 0 0 0 1 1 1 1 ID 1 1 1 1 1 2 2 2 Fix that by assigning the post-toggle ID to get Toggle 0 0 0 0 1 1 1 1 ID 1 1 1 1 2 2 2 2 Reported-by: Danny Alexander <danny.alexander@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: fbe41127 ("iwlwifi: mvm: update mpdu metadata API") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Sara Sharon authored
Currently whenever we get firmware notification with mac id, we iterate over all the interfaces to find the ID. This is a bit cumbersome. Instead, adding an array of RCU pointers, like we have for station IDs. This is not expensive space wise since we have only up to 4 active MACs, and not complicated code wise, since we have a clear point to init and de-init it. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Shahar S Matityahu authored
Since we use a dumping mask, checking if only monitor was requested is redundant. Remove the unneeded code. Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Liad Kaufman authored
If WEP is used, no one removes the STA key upon STA removal, leading to a situation where after 16 connect/disconnects - the AP could no longer decrypt incoming data frames since iwl_mvm_set_fw_key_idx() called from iwl_mvm_set_sta_key() during association returns STA_KEY_IDX_INVALID, thus not setting the key for that connecting STA. Fix this by removing the key in the driver when the STA is removed. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
Harden the fwrt->fw->img array access by making sure the cur_fw_img value doesn't go out of bounds. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
The out_cmd structure starts with a header, so there's no need to use &out_cmd->hdr, out_cmd alone is enough. We use this when calculating other addresses and klocwork gets confused with that because it thinks we are trying to access hdr (as an array) beyond its size. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
The function we pass to the wait alive notification procedure may may not even get called if the timeout occurs before the function is called. To prevent accessing unitialized data in alive_data, pre-set it to zero in the declaration. Found by static analyzers. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
These inlines just check the module parameters, so they don't need a configuration parameter and can move to a better place. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
This function is supposed to be used as an inline function and is in a header file, so make it inline. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
Sometimes we want to debug issues related to the regulatory blob in the NVM. To make that easier, add a debugfs entry to export it together with the other nvm blobs we export. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Clean up the LDBG config command to not be called "continuous recording", and while at it actually remove the continuous recording implementation completely since it was only used for store & forward architectures. This also fixes a bug at least in iwl_fw_dbg_buffer_allocation() because what's now "__le32 type" (matching the firmware) used to be "__le16 enable_recording", so the buffer allocation config sub-struct would erroneously have started at the wrong offset. In the other cases this didn't actually lead to a bug as other bytes in pad[] were all zeroes, so accessing the 16-bit value as a 32-bit value wouldn't make a difference (in little endian.) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-