- 28 2月, 2013 4 次提交
-
-
由 Johannes Berg 提交于
Recently in commit 8a964f44 ("iwlwifi: always copy first 16 bytes of commands") we fixed the problem that the hardware writes back to the command and that could overwrite parts of the data that was still needed and would thus be corrupted. Investigating this problem more closely we found that this write-back isn't really ordered very well with respect to other DMA traffic. Therefore, it sometimes happened that the write-back occurred after unmapping the command again which is clearly an issue and could corrupt the next allocation that goes to that spot, or (better) cause IOMMU faults. To fix this, allocate coherent memory for the first 16 bytes of each command, containing the write-back part, and use it for all queues. All the dynamic DMA mappings only need to be TO_DEVICE then. This ensures that even when the write-back happens "too late" it can't hit memory that has been freed or a mapping that doesn't exist any more. Since now the actual command is no longer modified, we can also remove CMD_WANT_HCMD and get rid of the DMA sync that was necessary to update the scratch pointer. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Emmanuel Grumbach 提交于
Supporting 8K A-MSDU means that we need to allocate order 1 pages for every Rx packet. Even when there is no traffic. This adds stress on the memory manager. The handling of compound pages is also less trivial for the memory manager and not using them will make the allocation code run faster although I didn't really measure. Eric also pointed out that having huge buffers with little data in them is not very nice towards the TCP stack since the truesize of the skb is huge. This doesn't allow TCP to have a big Rx window. See https://patchwork.kernel.org/patch/2167711/ for details. Note that very few vendors will actually send A-MSDU. Disable this feature by default. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The IWL_MAX_CMD_TFDS name for this constant is wrong, the constant really indicates how many TBs we can use in the driver for a single command TFD, rename the constant and also add a comment explaining it. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The reason we mapped them bidirectionally was that not doing so had caused IOMMU exceptions, due to the fact that the HW writes back into the command. Now that the first part of the command including the write-back part is always in the first buffer, we don't need to map the remaining buffer(s) bidi and can get rid of the special-casing for commands. This is a requisite patch for another one to fix DMA mapping. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 27 2月, 2013 4 次提交
-
-
由 Dor Shaish 提交于
The PIC was supposed to be a small signature appended to the PhyDB data, but the signature isn't really static and thus attempting to check it just causes the warnings spuriously so remove them. Signed-off-by: NDor Shaish <dor.shaish@intel.com> Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The wakeup packet in the status response is padded out to a multiple of 4 bytes by the firmware for transfer to the host, take that into account when checking the length of the command. Also, the reported wakeup packet includes the FCS but the userspace API doesn't, so remove that. If it is a data packet it is reported as an 802.3 packet but I forgot to take into account and remove the encryption head/tail, fix all of that as well. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
When stations are removed while packets are in the queue, we drain the queues first, and then remove the stations. If this happens in AP mode while the interface is removed the MAC context might be removed from the firmware before we removed the station(s), resulting in a SYSASSERT 3421. This is because we remove the MAC context from the FW in stop_ap(), but only flush the station drain work later in remove_interface(). Refactor the code a bit to have a common MAC context removal preparation first to solve this. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The FH hardware will always write back to the scratch field in commands, even host commands not just TX commands, which can overwrite parts of the command. This is problematic if the command is re-used (with IWL_HCMD_DFL_NOCOPY) and can cause calibration issues. Address this problem by always putting at least the first 16 bytes into the buffer we also use for the command header and therefore make the DMA engine write back into this. For commands that are smaller than 16 bytes also always map enough memory for the DMA engine to write back to. Cc: stable@vger.kernel.org Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 23 2月, 2013 3 次提交
-
-
由 Wei Yongjun 提交于
Add the missing unlock before return from function brcmf_notify_vif_event() in the error handling case. Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Avinash Patil 提交于
Unload sequence for mwifiex PCIE driver is as follows: 1. Invoking cleanup module from kernel results into pci_unregister_driver 2. Kernel invokes PCIE remove() handler which disconnects all interfaces. 3. One step during disconnect is to clean PCIE TX rings. During this we read txbd_rdptr from FW. While loading driver next time, we see pci_enable_device() results into system freeze. This may have happened because we accessed PCI device after unregistering from bus driver. Removing this ioread() operation resolves this bug. Signed-off-by: NAvinash Patil <patila@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Daniel Drake 提交于
If the system suspends with mwifiex wifi powered on, and is then woken by an ICMP ping packet, the ping response is discarded by the kernel because the kernel incorrectly thinks there is no carrier. I can't see any valid reason to want to report loss of carrier here, so remove the offending code. Fixes http://dev.laptop.org/ticket/12554Signed-off-by: NDaniel Drake <dsd@laptop.org> Acked-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 19 2月, 2013 16 次提交
-
-
由 Kumar Amit Mehta 提交于
When memory allocation using, kmalloc() fails, report appropriate error value. Signed-off-by: NKumar Amit Mehta <gmate.amit@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Kumar Amit Mehta 提交于
This patch fixes an instance of DMA buffer on stack(being passed to usb_control_msg) for the wireless USB version of the Agere Orinoco card driver. It also fixes the missing audit for the return value of firmware download routine. Found using smatch. Signed-off-by: NKumar Amit Mehta <gmate.amit@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jussi Kivilinna 提交于
rtlwifi allocates both setup_packet and data buffer of control message urb, using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for allocating is: struct { u8 data[254]; struct usb_ctrlrequest dr; }; Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory corruptions and freezes. Patch changes setup packet to be allocated separately. [v2]: - Use WARN_ON_ONCE instead of WARN_ON Cc: <stable@vger.kernel.org> Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Yogesh Ashok Powar 提交于
For STA mode, collect VHT realated IEs from the Beacons or Probe Responses and append similar VHT related IEs to association requests. For AP mode, get VHT related capability information and share it with cfg80211 at the time of wiphy register. This information is further used by cfg80211 and hostapd to start an AP with 802.11AC support. Currently only 8897 supports 802.11AC. Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: NAvinash Patil <patila@marvell.com> Signed-off-by: NNishant Sarmukadam <nishants@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NFrank Huang <frankh@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Yogesh Ashok Powar 提交于
They all can make one line. Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Avinash Patil 提交于
While unloading driver, we free all pending TX packets by flushing TX ring. There is unhandled case for PCIE8897 while checking for ring empty condition. This patch adds the handling by calling mwifiex_pcie_txbd_empty(). Signed-off-by: NAvinash Patil <patila@marvell.com> Signed-off-by: NYogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Emmanuel Grumbach 提交于
I removed a bit too much info last time. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Eytan Lifshitz 提交于
Theoretically, the card may not enter CTKILL: In case the timer that iwl_prepare_ct_kill_task is setting, will expire before tt->state revert to its previous state. Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Ilan Peer 提交于
Signed-off-by: NIlan Peer <ilan.peer@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Ilan Peer 提交于
The time event data structures are required also for P2P Device interface. Signed-off-by: NIlan Peer <ilan.peer@intel.com> Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Ilan Peer 提交于
The FW can differentiate between scans, according to the interface type on which the scan was issues. Supply the interfaces type information to the FW. Signed-off-by: NIlan Peer <ilan.peer@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Occasionally, we would run into this warning: iwlwifi 0000:02:00.0: U iwl_mvm_protect_session extend 0x2601: only 200 ms left iwlwifi 0000:02:00.0: U iwl_mvm_remove_time_event Removing TE 0x2601 iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0925, 60 bytes at 37[5]:9 iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TIME_EVENT_CMD iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TIME_EVENT_CMD iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0926, 60 bytes at 38[6]:9 iwlwifi 0000:02:00.0: U iwl_mvm_time_event_response TIME_EVENT_CMD response - UID = 0x2601 iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TIME_EVENT_CMD iwlwifi 0000:02:00.0: U iwl_mvm_rx_time_event_notif Time event notification - UID = 0x2701 action 1 wlan0: associate with 00:0a:b8:55:a8:30 (try 2/3) ------------[ cut here ]------------ WARNING: at drivers/net/wireless/iwlwifi/mvm/time-event.c:269 iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]() Modules linked in: [...] Call Trace: [<c1046e42>] warn_slowpath_common+0x72/0xa0 [<c1046e92>] warn_slowpath_null+0x22/0x30 [<f8cad913>] iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm] [<f8cadead>] iwl_mvm_protect_session+0xcd/0x1c0 [iwlmvm] [<f8ca2087>] iwl_mvm_mac_mgd_prepare_tx+0x67/0xa0 [iwlmvm] [<f882a130>] ieee80211_sta_work+0x8f0/0x1070 [mac80211] The reason is a problem with asynchronous vs. synchronous commands, what happens here is the following: * TE 0x2601 is removed, the TIME_EVENT_CMD for that is async * a new TE (will be 0x2701) is created, the TIME_EVENT_CMD for that is sync and also uses a notification wait for the response (to avoid another race condition) * the response for the TE 0x2601 removal comes from the firmware, and is handled by the notification wait handler that's really waiting for the second response, but can't tell the difference, we therefore see the message "TIME_EVENT_CMD response - UID = 0x2601" instead of "TIME_EVENT_CMD response - UID = 0x2701". Fix this issue by making the TE removal synchronous as well, this means that we wait for the response to that command first, before there's any chance of sending a new one. Also, to detect such issues more easily in the future, add a warning to the notification handler that detects them. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
This is helpful for debugging the time event warning, but also in general to see what's going on. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
All station commands must include a valid MAC ID, the ID 0 is randomly valid in some cases, but we must set the ID properly. Do that by passing the right station and using its mac_id_n_color. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
For the firmware to know when DTIM beacons arrive we have to program the DTIM time in TSF and system time in the MAC context. Since mac80211 now tracks the different times (on demand), this becomes easy. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The iwlwifi-next tree removed IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC while the mac80211-next tree removed Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 15 2月, 2013 10 次提交
-
-
由 Karl Beldan 提交于
Otherwise memory corruption occurs when using channel contexts (ATM when param 'channel' > 1). Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Instead of modifying the HT SMPS capability field for stations, track the SMPS mode explicitly in a new field in the station struct and use it in the drivers that care about it. This simplifies the code using it. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
For VHT, many more bandwidth changes are possible. As a first step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag in the HT capabilities and instead introduce a bandwidth field indicating the currently usable bandwidth to transmit to the station. Of course, make all drivers use it. To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get the station as an argument, rather than the new capabilities, so it can set up the new bandwidth field. If the station is a VHT station and VHT bandwidth is in use, also set the bandwidth accordingly. Doing this allows us to get rid of the supports_40mhz flag as the HT capabilities now reflect the true capability instead of the current setting. While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not ignore HT cap overrides when MCS TX isn't supported (not that it really happens...) Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Joe Perches 提交于
Remove the casts of the first argument of memset. Neaten the style by using the sizeof the actual variable being memset not the sizeof the type of variable. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Joe Perches 提交于
These messages don't seem to be errors but notifications that some attribute isn't quite right. Don't mark them as errors. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
This patch check output of pci_map_single() calls. I missed them on my previous patch "iwlegacy: check for dma mapping errors", which fixed only pci_map_page() calls. To handle remaining possible dma mappings errors, we need to rearrange ilXXXX_tx_skb() and il_enqueue_hcmd() functions. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Stanislaw Gruszka 提交于
Check output of dma_map_single functions which nowadays can fail (when IOMMU is used). On write_beacon callbacks just print error, similar like padding error is handled by rt2800_write_beacon. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Avinash Patil 提交于
This patch adds support for handling of PCIe sleep cookie depending upon device properties. Some PCIe devices need sleep cookie probing before accessing HW while some others don't. A new sleep_cookie variable is defined as part of mwifiex_pcie_card_reg strcture and set/reset as per device capability. Sleep cookie is allocated/accessed/freed only when flag sleep_cookie for this particular device is enabled. Signed-off-by: NAvinash Patil <patila@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Larry Finger 提交于
As the number of drivers in the rtlwifi family has grown, the Kconfig section for them has grown unwieldy. This change has two effects: (1) Variable RTLWIFI_DEBUG is documented, and (2) the entries for the drivers that depend on RTLWIFI are indented. Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Dan Carpenter 提交于
ccode is not NUL terminated. Presumably insisting on a terminator makes brcms_c_country_valid() return false when it's not intended. ccode[2] is sprom->leddc_on_time. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 13 2月, 2013 1 次提交
-
-
由 Catalin Iacob 提交于
This partially reverts commit 44ba9736. rate_control_rate_init assumes the rate_init member of struct rate_control_ops is not NULL therefore not initializing it leads to an oops as soon the driver succesfully associates to an AP. The removal of rate_update from 44ba9736 is ok because rate_update is checked for NULL before being called. Signed-off-by: NCatalin Iacob <iacobcatalin@gmail.com> Acked-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 12 2月, 2013 2 次提交
-
-
由 Emmanuel Grumbach 提交于
Make the code more readable, and while at it also add a missing "break" to avoid checking handlers that cannot be used. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
In managed mode, the HT/VHT capabilities aren't set when the station is initially added, so update the station when it is marked associated. In AP/GO mode, the station will typically be added with full capabilities today, but an upcoming change in hostapd may mean a similar scenario as for managed mode, therefore do the update unconditionally. Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-