- 23 Jun, 2017 15 commits
-
-
Emmanuel Grumbach authored
In case we need to move the scheduler write pointer by steps of 0x40, 0x80 or 0xc0, the scheduler gets stuck. This leads to hardware error interrupts with status: 0x5A5A5A5A or alike. In order to work around this, detect in the transport layer that we are going to hit this case and tell iwlmvm to increment the sequence number of the packets. This allows to keep the requirement that the WiFi sequence number is in sync with the index in the scheduler Tx queue and it also allows to avoid the problematic sequence. This means that from time to time, we will start a queue from ssn + 1, but that shouldn't be a problem since we don't switch to new queues for AMPDU now that we have DQA which allows to keep the same queue while toggling the AMPDU state. This bug has been fixed on 9000 devices and up. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Emmanuel Grumbach authored
A TID may not have traffic but still have a BA agreement active (or being setup / torn down) since a BA agreement can be triggered by a debugfs hook. Just avoid to consider such a TID as inactive to make the logic safer. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
If the hardware is stuck, we can't read any of the memory we need to dump it, so we end up printing only 0xa5a5a5a5, which is useless. To solve this, poke the hardware by triggering a reset and re-enabling the clocks if we detect a HW error. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
When we started using threaded irqs, all the opmode calls were changed to be called with local_bh disabled. The reason for this was it was that mac80211 needs that. When we are handling FW errors, mac80211 is not involved, so we don't need it. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Emmanuel Grumbach authored
In BSS mode in the disconnection flow, mac80211 removes the AP station before the vif is set to unassociated. Our firmware wants it the other way around: first set the vif as unassociated, and then remove the AP station. In order to bridge between those two different behaviors, iwlmvm doesn't remove the station from the firmware when mac80211 removes it, but only after the vif is set to unassociated. The implementation is in iwl_mvm_bss_info_changed_station: if (assoc state was modified && mvmvif->ap_sta_id is VALID && assoc state is now UNASSC) remove_the_station_from_the_firmware() During the recovery flow, mac80211 re-adds the AP station and then reconfigures the vif. Since the vif is not associated, and then, we enter the if above (which was intended to be taken in the disconnection flow only) and remove the station we just added. This defeats the recovery flow. Fix this by not removing the AP station in this flow if we are in recovery flow. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
We allocate nvm_data in iwl_mvm_nvm_get_from_fw(). If something goes wrong after the allocation (i.e. if no valid MAC address is valid), we should free nvm_data before returning an error. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
This function just calls kfree(), so it only obscures the code without bringing any benefits. Remove it. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Properly document the transmit buffer bits using an enum and kernel-doc documentation. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Add kernel-doc documentation for enum iwl_debug_cmds, linking the structures used by the commands. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
This improves documentation, since kernel-doc can't deal with the union well. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Liad Kaufman authored
To stop and start the FW monitor in the 7000 HW family we need to use a different bit, otherwise after stopping it for the first time - it won't get restarted. Use the correct bitmask. Note: This fix is only for DRAM collection mode. For other modes, an additional fix will be needed. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Fix the enum link by adding the missing & and provide the link to the TX response documentation. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
When the command name is printed on command completion, the wrong group is used, leading to the wrong name being printed. Fix this by using the group ID without inappropriately mangling it through iwl_cmd_groupid() - it's already a u8. Also, while at it, use it from the same place as the command ID, everything else is just confusing. Fixes: ab02165c ("iwlwifi: add wide firmware command infrastructure for TX") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
When sending non-linear SKBs that should be included in the regular TX tracing completely (and not be pushed into the tx_data tracing), the (tracing) code didn't correctly take the fact that they were non-linear into account and added only the skb head portion. This probably never really triggered, since those frames we want traced fully are most likely linear anyway, but the code gets easier to understand and we lose an argument to the tracing function, so overall fixing this is better. Fixes: 206eea78 ("iwlwifi: pcie: support frag SKBs") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
There's no need to calculate the data_len outside of the tracepoint, since it's always skb->len - hdr_len, which are both available inside. Simplify the callers and move the calculation in. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
- 22 Jun, 2017 25 commits
-
-
Johannes Berg authored
Show the name of the member (scanned_channels) that provides the length with some better markup. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Use kstrtou32_from_user() in debugfs instead of open-coding it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Liad Kaufman authored
On A000 HW, the SCD rdptr has only 8 bits allocated for it, thus when checking if a queue is full, or when checking if the SSN is equal to the TID's next_reclaimed, A000 HW should trim the SSN. Fix this by "normalizing" the SSN to wrap around 0xFF when comparing to the next_reclaimed on A000 HW. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
We don't actually care about the value at all, just making sure that we can successfully parse a single integer value, but that's entirely pointless - remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
When toggling the RF-kill pin quickly in succession, the driver can get rather confused because it might be in the process of shutting down, expecting all commands to go through quickly due to rfkill, but the transport already thinks the device is accessible again, even though it previously shut it down. This leads to bugs, and I even observed a kernel panic. Avoid this by making the PCIe code only report that the radio is enabled again after the higher layers actually decided to shut it off. This also pulls out this common RF-kill checking code into a common function called by both transport generations and also moves it to the direct method - in the internal helper we don't really care about the RF-kill status anymore since we won't report it up until the stop anyway. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
If we happen to be in or get into the queue sync when RF-kill is asserted, we return from there and warn since there are still queue sync notifications outstanding. These can't ever come though, because we're in RF-kill, so don't WARN then. While at it, also move the warning to the appropriate place, if the request is not synchronous then we shouldn't warn, but currently always will. To make it fast, also trigger the waitq when on rfkill assert. Fixes: 0636b938 ("iwlwifi: mvm: implement driver RX queues sync command") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
In order to debug "hardware" RF-kill flows, add a low-level hook to allow changing the "hardware" RF-kill from debugfs. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
There's no point in duplicating exactly the same code here for legacy and MSI-X interrupts, so pull it out into a new function to call in both places. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Gregory Greenman authored
In case that rate's antenna is wrong at the init stage, it's very hard to say what went wrong. Add debug data to the already existing WARN_ON_ONCE. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Some static checkers (e.g. smatch) complain about the logic, saying that resp_cp might be leaked. Clearly that isn't true, but making the logic easier to follow does not result in any significant code changes and makes the code more readable by moving the NULL check closer to its source. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Mordechai Goodstein authored
The firmware moved the development from a0 MAC to z0. z0 is using the same RFID and device ID as a0 so we only need to switch the name. Signed-off-by: Mordechai Goodstein <mordechay.goodstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
New FW versions require the D0I3_END_CMD to be sent as the first command to the FW in the resume flow. If the TLV is set, send that command first, otherwise keep the original behavior (i.e. send last). Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Luca Coelho authored
There is no need to send D0I3_END_CMD as ASYNC during the system resume flow. Additionally, the other flags used are meaningless in this case (they were just copied from the runtime resume flow), so remove them all. Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Shaul reported that when iwlmvm was sending beacons, it didn't properly also take ownership of the probe responses. This is because the whole mac80211 callback (tx_last_beacon) wasn't implemented. Fix that to make IBSS discovery work better. Reported-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Letting the preprocessor/compiler generate the shift/mask by itself is a win for readability, so use bitfield.h for some registers. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
It's safer to use scnprintf() here because the buffer might be too short for the full format strings. In most cases this isn't true because of external limits on the values. In one case, this fixes a stack data leak. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Avoid one kind of symbol shadowing another in iwl_mvm_flush_sta() by renaming the function parameter. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
The queue ID should never be 512 either, so correct the check to be >= instead of just >. Fixes: 310181ec ("iwlwifi: move to TVQM mode") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Since we exit if buf->num_stored is 0, there's no need to check it again later. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Emmanuel Grumbach authored
When sending a Tx Command with a Tx packet, we allocate the Tx command separately from the payload of the packet. The WiFi MAC header is then copied into the buffer that was allocated for the Tx Command. This means that this buffer needs to be big enough to contain both. This is why it is allocated with iwl_trans_alloc_tx_cmd which returns a pointer to a newly allocated not zeroed struct iwl_device_cmd. The Tx command has a few bit fields and hence it needs to be zeroed, but all the rest of the buffer doesn't need to be zeroed since it will either be memcopy'ed with the MAC header, or not even sent to the device. This means that we don't need to zero all the iwl_device_cmd structure, but rather only the size of the iwl_tx_cmd structure. Since sizeof(iwl_tx_cmd) - sizeof(iwl_tx_cmd) is about 260 bytes, this can avoid touching 4 cache lines for each packet. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
David Spinadel authored
Install GTKs on AP side for new TX API. Don't add IV space, it's added by the HW. While at that fix GCMP abnd GCMP-256 GTK installation which work similarly to the new TX API. Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Liad Kaufman authored
If FW isn't alive, trying to collect debug data will result in errors both in driver and in the collected data, so just warn and leave the collecting function in this case. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Johannes Berg authored
Contrary to what some of the comments say, if rfkill was asserted the transport will return -ERFKILL instead of success, if CMD_WANT_SKB was set, so it's not necessary to check cmd.resp_pkt for being NULL if the return code was success. Validate that this is true in iwl_trans_send_cmd(). Most of the other code modifications were done with the following spatch: @@ struct iwl_host_cmd cmd; identifier pkt; @@ <... ( pkt = cmd.resp_pkt; ... -if (!pkt) { ... } | pkt = cmd.resp_pkt; ... -if (WARN_ON(!pkt)) { ... } | -if (!cmd.resp_pkt) { ... } ) ...> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-
Liad Kaufman authored
In DQA mode, there is no need to wait for the TXQ to clear out after getting a DELBA, since traffic can continue running on the queue. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
-