- 08 Jul, 2016 28 commits
-
-
Brian Norris authored
The PCIe driver didn't mask the host interrupts before trying to tear down. This causes lockups at reboot or rmmod when using MSI-X on 8997, since the MSI handler gets confused and locks up the system. Also tested on 8897, which does not support MSI-X (and wasn't experiencing this same bug). No regressions seen there. Signed-off-by:
Brian Norris <briannorris@chromium.org> Tested-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Amitkumar Karwar authored
PCIe-USB8997 variant is being used in the product. Let's change default firmware from PCIe-UART to PCIe-USB. So by default PCIe-USB firmware would be downloaded if version register doesn't give any information. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Prasun Maiti authored
The two members min_scan_time and max_scan_time of structure "mwifiex_ie_types_btcoex_scan_time" are of two bytes each. The values are assigned directtly from firmware without endian conversion handling. So, wrong datas will get saved in big-endian systems. This patch converts the values into cpu's byte order before assigning them into the local members. Signed-off-by:
Prasun Maiti <prasunmaiti87@gmail.com> Acked-by:
-
Rafał Miłecki authored
New firmwares (e.g. 10.10.69.36 for BCM4366) support "interface_remove" for removing interfaces. Try to use this method on cfg80211 request. In case of older firmwares (e.g. 7.35.177.56 for BCM43602 as I tested) this will just result in firmware rejecting command and this won't change any behavior. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
So far when receiving event about in-firmware-interface removal our event worker was notifying listener and afterwards it was removing Linux interface. First of all it was resulting in slightly unexpected order. The listener (del_virtual_intf callback) was (usually) returning with success before we even called unregister_netdev(ice). Please note this couldn't be simply fixed by changing order of calls in brcmf_fweh_handle_if_event as unregistering interface earlier could free struct brcmf_if. Another problem of current implementation are possible lockups. Focus on the time slot between calling event handler and removing Linux interface. During that time original caller may leave (unlocking rtnl semaphore) *and* another call to the same code may be done (locking it again). If that happens our event handler will stuck at removing Linux interface, it won't handle another event and will block process holding rtnl lock. This can be simply solved by unregistering interface in a proper callback, right after receiving confirmation event from firmware. This only required modifying worker to don't unregister on its own if there is someone waiting for the event. Signed-off-by:
-
Amitkumar Karwar authored
scan_block flag is used to block scan operation when 4 way handshake is in progress. Sometimes it doesn't get cleared due to incomplete association. An example is assoc request/response is done, but add key operation get canceled in some corner cases. As a result, further association/scan operations are blocked. This patch fixes the problem by clearing scan_block flag. Signed-off-by:
Xinming Hu <huxm@marvell.com> Signed-off-by:
-
Masanari Iida authored
This patch fix spelling typos found in drivers/net/wireless/realtek. Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Reviewed-by:
Julian Calaby <julian.calaby@gmail.com> Signed-off-by:
-
Jes Sorensen authored
This allows the user to specify DMA aggregation timout and block count. Blocks are presumably always 512 bytes, so the minimum block count is 6 for 802.11 packets. Signed-off-by:
Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by:
-
Jes Sorensen authored
gen2 chips as well as 8188eu seems to use this register for setting DMA timeout threshold values, however the 8192cu is using REG_USB_DMA_AGG_TO. Set both to be on the safe side. Signed-off-by:
-
Jes Sorensen authored
Let the default to off until we have more data on the right default tuning values. Signed-off-by:
-
Jes Sorensen authored
This enables aggregation on rtl8192cu and derivative parts. This uses the same parameters as for rtl8723au. Signed-off-by:
-
Jes Sorensen authored
Implement rtl8xxxu_gen1_init_aggregation(). Aggregation should be the same for all gen1 parts. We may want to allow for tuning parameters in the fileopes struct. For now this is based allocating 16KB RX buffers, leaving 16000 bytes for actual packets, and the rest for the skb overhead. Signed-off-by:
-
Jes Sorensen authored
The old allocation didn't leave space for phystats in the buffer, allowing the packet to be rejected if a frame size of size IEEE80211_MAX_FRAME_LEN was received. Signed-off-by:
-
Jes Sorensen authored
This adds support for allocating larger skbs for devices which indicate they support it. Signed-off-by:
-
Jes Sorensen authored
This implements support for demuxing aggregated RX packets on gen1 devices, using the rxdesc16 format. So far this has only been tested with rtl8723au devices. Signed-off-by:
-
Jes Sorensen authored
This corrects the definition of rxdesc16 to correctly specify pkt_cnt for aggregated packets. This is based on the code of the vendor rtl8723au driver, as opposed to the struct definitions they use. Signed-off-by:
-
Jes Sorensen authored
When handling aggregated packets, we'll get a new ieee80211_rx_status for each cloned skb, so passing in the pointer from the outside doesn't make sense. Signed-off-by:
-
Jes Sorensen authored
This is another prepatory patch to be able to handle aggregated RX packets. In order to avoid adding a prototype, this also moves the rtl8723bu_handle_c2h() function. Signed-off-by:
-
Jes Sorensen authored
This needs to be handled locally in the parse_rx_desc() function in order to be able to handle aggregated packets in the future. Signed-off-by:
-
Machani, Yaniv authored
Changed the configuration to support 64bit instead of 32bit this in order to offload the driver from handling a wraparound. Signed-off-by:
Yaniv Machani <yanivma@ti.com> Signed-off-by:
-
Amitkumar Karwar authored
This patch fixes below NULL pointer dereference observed in suspend stress test. When scan is cancelled during system suspend, we may end up aceesing "priv->scan_request" in corner case. [ 3035.304682] BUG: KASAN: null-ptr-deref on address 0000000000000008 [ 3035.304704] Read of size 4 by task ksdioirqd/mmc2/1183 [ 3035.304744] CPU: 0 PID: 1183 Comm: ksdioirqd/mmc2 Tainted: G W 3.18.0 #1169 [ 3035.304772] Call trace: [ 3035.304825] [<ffffffc00020a520>] dump_backtrace+0x0/0x190 [ 3035.304864] [<ffffffc00020a6cc>] show_stack+0x1c/0x28 [ 3035.304901] [<ffffffc000b36db8>] dump_stack+0xa0/0xf8 [ 3035.304940] [<ffffffc00039c494>] kasan_report+0x120/0x4fc [ 3035.304975] [<ffffffc00039b6b4>] __asan_load4+0x20/0x80 [ 3035.305546] [<ffffffbffc1f5aec>] mwifiex_check_next_scan_command+0x1a4/0x588 [mwifiex] [ 3035.306091] [<ffffffbffc1f7aec>] mwifiex_handle_event_ext_scan_report+0x304/0x370 [mwifiex] [ 3035.306735] [<ffffffbffc206bb8>] mwifiex_process_sta_event+0x6c0/0xf10 [mwifiex] [ 3035.307200] [<ffffffbffc1e609c>] mwifiex_process_event+0x2f4/0x358 [mwifiex] [ 3035.307612] [<ffffffbffc1e25c8>] mwifiex_main_process+0x3cc/0x80c [mwifiex] [ 3035.307737] [<ffffffbffc2523a0>] mwifiex_sdio_interrupt+0x198/0x1c0 [mwifiex_sdio] [ 3035.307785] [<ffffffc0008d9250>] process_sdio_pending_irqs+0x15c/0x1d4 [ 3035.307826] [<ffffffc0008d93f0>] sdio_irq_thread+0xd8/0x288 Signed-off-by:
-
Amitkumar Karwar authored
The flag should be cleaned along with other scan operation variables. This was missing at some places. Signed-off-by:
-
Amitkumar Karwar authored
We will derive sta_priv at the beginning of suspend handler. This will be useful for next patch in this series. Signed-off-by:
-
Joe Perches authored
RT_TRACE does not add a newline to the end of a message and always emits at KERN_DEBUG so these are susceptible to message interleaving from other processes without the newline. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
This debugging macro can expand to a lot of code. Make it a function to reduce code size. (x86-64 defconfig w/ all rtlwifi drivers and allyesconfig) $ size drivers/net/wireless/realtek/rtlwifi/built-in.o* text data bss dec hex filename 900083 200499 1907 1102489 10d299 drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.new 1113597 200499 1907 1316003 1414a3 drivers/net/wireless/realtek/rtlwifi/built-in.o.defconfig.old 1746879 453503 8512 2208894 21b47e drivers/net/wireless/realtek/rtlwifi/built-in.o.new 2051965 503311 8512 2563788 271ecc drivers/net/wireless/realtek/rtlwifi/built-in.o.old Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Jes Sorensen authored
USB urbs will return with a status != 0 when rmmod'ing the driver. No need to fill the log with messages from rtl8xxxu_int_complete() Signed-off-by:
-
Luis de Bethencourt authored
reg_eac and reg_ecc are only used if candidate is bigger than 0, and in that case new values will be given to them. Removing the unused assignments. Signed-off-by:
Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by:
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2016-07-06' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next * work on DQA continued * SAR BIOS implementation * some work on debugging capabilities * added support for GCMP encryption * data path rework in preparation for new HW * some cleanup to remove transport dependency on mac80211 * support for MSIx in preparation for new HW * lots of work in preparation for HW support (9000 and a000 series) * general cleanups * general bugfixes
-
- 06 Jul, 2016 12 commits
-
-
Sara Sharon authored
All transports has this structure. By moving it to be shared, we can get rid of casting to the specific transport in probe and remove. Signed-off-by:
Sara Sharon <sara.sharon@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
-
Sara Sharon authored
Centralize the logging of SCD status. The motivation is that for a000 devices we will have new SCD HW, but this code was duplicate anyway, so it is a proper cleanup. Signed-off-by:
-
Luca Coelho authored
Add support for the v4 version of the TX power command. Just add a new version and do the same sizing tricks that were done when support for v3 was introduced. This patch doesn't support the new functionality introduced, but makes the driver work with the new size of the command. Signed-off-by:
-
Sara Sharon authored
Update the firmware load flow for TFH hardware. Signed-off-by:
-
Sara Sharon authored
For a000 device the FH was replaced by the TFH. This is the first patch in a series introducing the changes stemming from this change. This patch initializes the TFQ queue table with the new 64 bit register and the relevant TFH configuration registers. Signed-off-by:
-
Sara Sharon authored
Move the write_prph_64 of pcie to be transport agnostic. Add direct write as well, as it is needed for a000 HW. Signed-off-by:
-
Sara Sharon authored
Currently the scratch buffer is set to 16 bytes and indicates the size of the bi-directional DMA. However, next HW generation will perform additional offloading, and will write the result in the key location of the TX command, so the size of the bi-directional consistent memory should grow accordingly - increase it to 40. Generalize the code to get rid of now irrelevant scratch references. Signed-off-by:
-
Sara Sharon authored
In MQ environment and new architecture in early stages we may encounter DMA issues. Track RXB status and bail out in case we receive index to an RXB that was not mapped and handed over to HW. Signed-off-by:
-
Emmanuel Grumbach authored
Upon firmware load interrupt (FH_TX), the ISR re-enables the firmware load interrupt only to avoid races with other flows as described in the commit below. When the firmware is completely loaded, the thread that is loading the firmware will enable all the interrupts to make sure that the driver gets the ALIVE interrupt. The problem with that is that the thread that is loading the firmware is actually racing against the ISR and we can get to the following situation: CPU0 CPU1 iwl_pcie_load_given_ucode ... iwl_pcie_load_firmware_chunk wait_for_interrupt <interrupt> ISR handles CSR_INT_BIT_FH_TX ISR wakes up the thread on CPU0 /* enable all the interrupts * to get the ALIVE interrupt */ iwl_enable_interrupts ISR re-enables CSR_INT_BIT_FH_TX only /* start the firmware */ iwl_write32(trans, CSR_RESET, 0); BUG! ALIVE interrupt will never arrive since it has been masked by CPU1. In order to fix that, change the ISR to first check if STATUS_INT_ENABLED is set. If so, re-enable all the interrupts. If STATUS_INT_ENABLED is clear, then we can check what specific interrupt happened and re-enable only that specific interrupt (RFKILL or FH_TX). All the credit for the analysis goes to Kirtika who did the actual debugging work. Cc: <stable@vger.kernel.org> [4.5+] Fixes: a6bd005f ("iwlwifi: pcie: fix RF-Kill vs. firmware load race") Signed-off-by:
-
Johannes Berg authored
The PCIe transport needs to store two pointers in each TX SKB, and currently assumes mac80211's ieee80211_tx_info is present in the CB to do that. In order to remove that assumption, have the opmodes pass in the offset to where the pointers can be stored in the CB and use the offset in the PCIe code. To make the disentanglement complete, remove mac80211.h includes from everywhere in the generic iwlwifi code. This required adding an include of cfg80211.h in one place. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
In order to be able to properly record SKBs that didn't come through mac80211, don't rely on the IEEE80211_TX_CTRL_PORT_CTRL_PROTO flag but instead check for ETH_P_PAE directly. Signed-off-by:
-
Johannes Berg authored
In order to reduce reliance on mac80211 structs in the core iwlwifi code, store the cipher schemes in the format given by the firmware and convert it later, rather than storing it in the mac80211 format. Signed-off-by:
-
