- 29 Jun, 2019 38 commits
-
-
Emmanuel Grumbach authored
Otherwise it'll stay set forever which is clearly buggy. Cc: stable@vger.kernel.org Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Emmanuel Grumbach authored
iwl_mvm_send_cmd returns 0 when the command won't be sent because RF-Kill is asserted. Do the same when we call iwl_get_shared_mem_conf since it is not sent through iwl_mvm_send_cmd but directly calls the transport layer. Cc: stable@vger.kernel.org Signed-off-by:
-
Emmanuel Grumbach authored
Sometimes the register status can include interrupts that were masked. We can, for example, get the RF-Kill bit set in the interrupt status register although this interrupt was masked. Then if we get the ALIVE interrupt (for example) that was not masked, we need to *not* service the RF-Kill interrupt. Fix this in the MSI-X interrupt handler. Cc: stable@vger.kernel.org Signed-off-by:
-
Emmanuel Grumbach authored
Newest devices have a new firmware load mechanism. This mechanism is called the context info. It means that the driver doesn't need to load the sections of the firmware. The driver rather prepares a place in DRAM, with pointers to the relevant sections of the firmware, and the firmware loads itself. At the end of the process, the firmware sends the ALIVE interrupt. This is different from the previous scheme in which the driver expected the FH_TX interrupt after each section being transferred over the DMA. In order to support this new flow, we enabled all the interrupts. This broke the assumption that we have in the code that the RF-Kill interrupt can't interrupt the firmware load flow. Change the context info flow to enable only the ALIVE interrupt, and re-enable all the other interrupts only after the firmware is alive. Then, we won't see the RF-Kill interrupt until then. Getting the RF-Kill interrupt while loading the firmware made us kill the firmware while it is loading and we ended up dumping garbage instead of the firmware state. Re-enable the ALIVE | RX interrupts from the ISR when we get the ALIVE interrupt to be able to get the RX interrupt that comes immediately afterwards for the ALIVE notification. This is needed for non MSI-X only. Cc: stable@vger.kernel.org Signed-off-by:
-
Emmanuel Grumbach authored
We added code to restock the buffer upon ALIVE interrupt when MSI-X is disabled. This was added as part of the context info code. This code was added only if the ISR debug level is set which is very unlikely to be related. Move this code to run even when the ISR debug level is not set. Note that gen2 devices work with MSI-X in most cases so that this path is seldom used. Cc: stable@vger.kernel.org Signed-off-by:
-
Johannes Berg authored
In AP (and IBSS) mode, we can only set GTKs to firmware after we have sent down the multicast station, but this we can only do after we've enabled beaconing, etc. However, during rfkill exit, hostapd will configure the keys before starting the AP, and cfg80211/mac80211 accept it happily. On earlier devices, this didn't bother us as GTK TX wasn't really handled in firmware, we just put the key material into the TX cmd and thus it only mattered when we actually transmitted a frame. On newer devices, however, the firmware needs to track all of this and that doesn't work if we add the key before the (multicast) sta it belongs to. To fix this, keep a list of keys to add during AP enable, and call the function there. Cc: stable@vger.kernel.org Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Luca Coelho authored
The FW API was clarified saying that this flag should only be set in BSS client mode. Remove it from the MAC_CTXT command we send in AP and GO modes. Signed-off-by:
-
Shahar S Matityahu authored
The 0xF6 command used to start and stop the recording from 22560 devices was removed. This is causing an assert when the driver tries to alter the recording state. Remove the use of the command. Signed-off-by:
Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by:
-
Shahar S Matityahu authored
From 9000 device family the FW automatically stops the debug recording and the driver should not stop it as well. Signed-off-by:
-
Shahar S Matityahu authored
In ini debug mode the recording does not restart unless legacy monitor configuration is also given. Add dbg_ini_dest field to trans to indicate the debug monitor destination to solve this. Signed-off-by:
-
Emmanuel Grumbach authored
TWT is still very new and we expect issues. Make its usage configurable and disable it by default. Signed-off-by:
-
Emmanuel Grumbach authored
FSEQ TLV should be parsed and read even when FMAC is not compiled. Signed-off-by:
-
Shahar S Matityahu authored
Unite iwl_trans debug related fields under iwl_trans_debug struct to increase readability and keep iwl_trans clean. Signed-off-by:
-
Shahar S Matityahu authored
There are several flows where the driver checks if it runs in ini mode. Some of these flows are no longer used in ini mode or there is another condition that check the ini mode in the same flow. Either way, those conditions are redundant. Remove the redundant conditions. Signed-off-by:
-
Shahar S Matityahu authored
Apply buffer allocation TLV only if it is set to apply point IWL_FW_INI_APPLY_EARLY. Signed-off-by:
-
Shahar S Matityahu authored
The driver should delay only in recording stop flow between writing to DBGC_IN_SAMPLE register and DBGC_OUT_CTRL register. Any other delay is not needed. Change the following: 1. Remove any unnecessary delays in the flow 2. Increase the delay in the stop recording flow since 100 micro is not enough 3. Use usleep_range instead of delay since the driver is allowed to sleep in this flow. Signed-off-by:
-
Luca Coelho authored
Currently we dump only the first 64 bytes of the PCI config space, which leaves out some important things, such as the base address registers. Increase it to 352 for the PCI device and to 524 for the rootport to make sure we include everything we need. Signed-off-by: -
Andrei Otcheretianski authored
In some buggy scenarios we could possible attempt to transmit frames larger than maximum MSDU size. Since our devices don't know how to handle this, it may result in asserts, hangs etc. This can happen, for example, when we receive a large multicast frame and try to transmit it back to the air in AP mode. Since in a legal scenario this should never happen, drop such frames and warn about it. Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
-
Haim Dreyfuss authored
Inform users when SAR status is changing. Signed-off-by:
Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by:
-
Haim Dreyfuss authored
South Korea is adding a more strict SAR limit called "Limb SAR". Currently, WGDS SAR offset group 3 is not used (not mapped to any country). In order to be able to comply with South Korea new restriction: - OEM will use WGDS SAR offset group 3 to South Korea limitation. - OEM will change WGDS revision to 1 (currently latest revision is 0) to notify that Korea Limb SAR applied. - Driver will read the WGDS table and pass the values to FW (as usual) - Driver will pass to FW an indication that Korea Limb SAR is applied in case table revision is 1. Signed-off-by:
-
Johannes Berg authored
When the module fails to initialize for some reason, it doesn't clean up properly. Fix that. Signed-off-by:
-
Shaul Triebitz authored
The AC numbers used by mac80211 differ from those used by the firmware. When setting MU EDCA params for each AC, use the correct FW AC numbers. Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
-
Naftali Goldstein authored
The indexes into the ac array in the iwl_mac_ctx_cmd are from the iwl_ac enum and not the txfs. The current code therefore puts the edca params in the wrong indexes of the array, causing wrong priority for data-streams of different ACs. Fix this. Note that this bug only occurs in NICs that use the new tx api, since in the old tx api the txf number is equal to the corresponding ac in the iwl_ac enum. Signed-off-by:
Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by:
-
Dan Carpenter authored
These pointers are an offset into the "sta" struct. They're assigned like this: const struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap; They're not the first member of the struct (->supp_rates[] is first) so they can't be NULL. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, change the following form: sizeof(*pattern_cmd) + wowlan->n_patterns * sizeof(struct iwlagn_wowlan_pattern) to : struct_size(pattern_cmd, patterns, wowlan->n_patterns) This code was detected with the help of Coccinelle. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, change the following form: sizeof(*pattern_cmd) + wowlan->n_patterns * sizeof(struct iwlagn_wowlan_pattern) to : struct_size(pattern_cmd, patterns, wowlan->n_patterns) This code was detected with the help of Coccinelle. Signed-off-by: -
Shahar S Matityahu authored
Support adaptive dwell high band default number of APs new api. Signed-off-by:
-
Mordechay Goodstein authored
Now that we have per station control over amsdu size no need for multiple entries, especially that the old one is misleading due to not setting it for all protocols as a limit. Signed-off-by:
Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by:
-
Shahar S Matityahu authored
The info struct contains data about the FW, HW, RF and the debug configuration. Signed-off-by:
-
Mordechay Goodstein authored
The current debugfs entry only limits the max AMSDU for TCP. Add a new debugfs entry to allow setting a fixed AMSDU size for all TX packets, including UDP and ICMP Signed-off-by:
-
Shahar S Matityahu authored
Add support to debug info TLV. The TLV contains human readable naming of the FW image and the debug configuration. Signed-off-by:
-
Shahar S Matityahu authored
Use a different barker for ini dump to allow differentiation from legacy dump. Also it allows to remove INI_BIT from dump TLVs. Signed-off-by:
-
Shahar S Matityahu authored
When a dump trigger is fired, the driver sets IWL_FWRT_STATUS_DUMPING and aborts any consecutive dump collection. To allow consecutive triggers firing, use 5 dump workers and allocate them upon incoming dump collection requests. This functionality is needed since in ini debug mode each trigger may have entirely different memory regions to collect unlike the legacy mode in which all the triggers dump the same memory regions. Signed-off-by:
-
Shahar S Matityahu authored
Allows to abort region collection in case the region size is 0. It is needed for future regions that their size might be 0. Signed-off-by:
-
Johannes Berg authored
Update the CSI API to the new version supported by the firmware. Signed-off-by:
-
Shahar S Matityahu authored
Unite dump memory ranges under a single struct and add a specific header for each type of memory. Also, maintain a single version to all dump structures. This cleanup is also needed for the future addition of FW notification regions and others. Signed-off-by:
-
Shahar S Matityahu authored
Improve the robustness of the dump collection flow in case of an early error: 1. in iwl_trans_pcie_sync_nmi, disable and enable interrupts only if they were already enabled 2. attempt to initiate dump collection in iwl_fw_dbg_error_collect only if the device is enabled 3. check Tx command queue was already allocated before trying to collect it Signed-off-by:
-
Jiri Kosina authored
As iwl_mvm_tx_mpdu() is not disabling BH while obtaining iwl_mvm_sta->lock (which is being taken from BH context as well), it has to be always invoked with BH disabled. Make that clear in a comment. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
- 27 Jun, 2019 2 commits
-
-
Zong-Zhe Yang authored
Add a structure for power parameters including base, offset, limit and a function to get tx power parameters. Then, refine flow to get tx power index through the function. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Tzu-En Huang authored
Since this macro definition has different values in different chipset, the current defined macro value is for 8822b. This will cause the settings of 8822c be incorrect. Remove RTW_MAX_POWER_INDEX and use max_power_index in struct rtw_chip_info to make sure the value of different chipset is right. Signed-off-by:
Tzu-En Huang <tehuang@realtek.com> Signed-off-by:
-
