summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/iwlwifi
AgeCommit message (Collapse)AuthorFilesLines
2014-04-02iwlwifi: fix TX status for aggregated packetsJohannes Berg1-5/+11
commit 143582c6847cb285b361804c613127c25de60ca4 upstream. Only the first packet is currently handled correctly, but then all others are assumed to have failed which is problematic. Fix this, marking them all successful instead (since if they're not then the firmware will have transmitted them as single frames.) This fixes the lost packet reporting. Also do a tiny variable scoping cleanup. Signed-off-by: Johannes Berg <johannes.berg@intel.com> [Add the dvm part] Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> [bwh: Backported to 3.2: - Drop the mvm part - Adjust filename, context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-11-28iwlwifi: pcie: add SKUs for 6000, 6005 and 6235 seriesEmmanuel Grumbach3-0/+17
commit 08a5dd3842f2ac61c6d69661d2d96022df8ae359 upstream. Add some new PCI IDs to the table for 6000, 6005 and 6235 series. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: - Adjust filenames - Drop const from struct iwl_cfg] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-11-28iwlwifi: add new pci id for 6x35 seriesShuduo Sang1-0/+1
commit 20ecf9fd3bebc4147e2996c08a75d6f0229b90df upstream. some new thinkpad laptops use intel chip with new pci id need be added lspci -vnn output: Network controller [0280]: Intel Corporation Centrino Advanced-N 6235 [8086:088f] (rev 24) Subsystem: Intel Corporation Device [8086:5260] Signed-off-by: Shuduo Sang <sangshuduo@gmail.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-11-28iwlwifi: one more sku added to 6x35 seriesWey-Yi Guy1-0/+1
commit 259653d86b80ed01c70d47b7307140ae0ba19420 upstream. Add new sku to 6x35 series Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-11-28iwlwifi: update pci subsystem idWey-Yi Guy3-3/+16
commit 378911233f424d7a1bf4a579587ae71c7d887166 upstream. Update the pci subsystem id and product name for 6005 series devices Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-11-28iwlwifi: remove un-supported SKUsWey-Yi Guy4-54/+0
commit b6cb406a023184733bffc7762a75a2e204fff6b9 upstream. BG only SKUs are no longer supported by 2000 and 1x5 series. Remove it Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-11-28iwlwifi: two more SKUs for 6x05 seriesWey-Yi Guy1-0/+2
commit 75a56eccb01fcc3c1ae8000130f3c9b3c8ec68d9 upstream. Add two more SKUs for 6x05 series of device. First SKU has low 5GHz channels actives, the other SKU has high 5GHz channels actives. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-09-10iwlwifi: dvm: fix calling ieee80211_chswitch_done() with NULLStanislaw Gruszka1-1/+4
commit 9186a1fd9ed190739423db84bc344d258ef3e3d7 upstream. If channel switch is pending and we remove interface we can crash like showed below due to passing NULL vif to mac80211: BUG: unable to handle kernel paging request at fffffffffffff8cc IP: [<ffffffff8130924d>] strnlen+0xd/0x40 Call Trace: [<ffffffff8130ad2e>] string.isra.3+0x3e/0xd0 [<ffffffff8130bf99>] vsnprintf+0x219/0x640 [<ffffffff8130c481>] vscnprintf+0x11/0x30 [<ffffffff81061585>] vprintk_emit+0x115/0x4f0 [<ffffffff81657bd5>] printk+0x61/0x63 [<ffffffffa048987f>] ieee80211_chswitch_done+0xaf/0xd0 [mac80211] [<ffffffffa04e7b34>] iwl_chswitch_done+0x34/0x40 [iwldvm] [<ffffffffa04f83c3>] iwlagn_commit_rxon+0x2a3/0xdc0 [iwldvm] [<ffffffffa04ebc50>] ? iwlagn_set_rxon_chain+0x180/0x2c0 [iwldvm] [<ffffffffa04e5e76>] iwl_set_mode+0x36/0x40 [iwldvm] [<ffffffffa04e5f0d>] iwlagn_mac_remove_interface+0x8d/0x1b0 [iwldvm] [<ffffffffa0459b3d>] ieee80211_do_stop+0x29d/0x7f0 [mac80211] This is because we nulify ctx->vif in iwlagn_mac_remove_interface() before calling some other functions that teardown interface. To fix just check ctx->vif on iwl_chswitch_done(). We should not call ieee80211_chswitch_done() as channel switch works were already canceled by mac80211 in ieee80211_do_stop() -> ieee80211_mgd_stop(). Resolve: https://bugzilla.redhat.com/show_bug.cgi?id=979581 Reported-by: Lukasz Jagiello <jagiello.lukasz@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: adjust context, filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-09-10iwlwifi: add DELL SKU for 5150 HMCEmmanuel Grumbach1-0/+1
commit a1923f1d4723e5757cefdd60f7c7ab30e472007a upstream. This SKU was missing in the list of supported devices https://bugzilla.kernel.org/show_bug.cgi?id=60577 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-09-10iwlwifi: dvm: don't send BT_CONFIG on devices w/o BluetoothJohannes Berg1-1/+1
commit 707aee401d2467baa785a697f40a6e2d9ee79ad5 upstream. The BT_CONFIG command that is sent to the device during startup will enable BT coex unless the module parameter turns it off, but on devices without Bluetooth this may cause problems, as reported in Redhat BZ 885407. Fix this by sending the BT_CONFIG command only when the device has Bluetooth. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> [bwh: Backported to 3.2: - Adjust filename - s/priv->lib/priv->cfg/] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-06-19iwlwifi: dvm: fix zero LQ CMD sending avoidanceEmmanuel Grumbach1-1/+1
commit a87783699b23395c46bbeeb5d28f6db24897bf26 upstream. In 63b77bf489881747c5118476918cc8c29378ee63 iwlwifi: dvm: don't send zeroed LQ cmd I tried to avoid to send zeroed LQ cmd, but I made a (very) stupid mistake in the memcmp. Since this patch has been ported to stable, the fix should go to stable too. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=58341 Reported-by: Hinnerk van Bruinehsen <h.v.bruinehsen@fu-berlin.de> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-05-13iwlwifi: dvm: don't send zeroed LQ cmdEmmanuel Grumbach1-1/+4
commit 63b77bf489881747c5118476918cc8c29378ee63 upstream. When the stations are being restored because of unassoc RXON, the LQ cmd may not have been initialized because it is initialized only after association. Sending zeroed LQ_CMD makes the fw unhappy: it raises SYSASSERT_2078. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> [move zero_lq and make static const] Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-03-20iwlwifi: always copy first 16 bytes of commandsJohannes Berg2-15/+66
commit 8a964f44e01ad3bbc208c3e80d931ba91b9ea786 upstream. 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. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: - Adjust context - Drop the IWL_HCMD_DFL_DUP handling - Fix descriptor addresses and lengths for tracepoint, but otherwise leave it unchanged] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-01-03iwlwifi: handle DMA mapping failuresJohannes Berg1-2/+21
commit 7c34158231b2eda8dcbd297be2bb1559e69cb433 upstream. The RX replenish code doesn't handle DMA mapping failures, which will cause issues if there actually is a failure. This was reported by Shuah Khan who found a DMA mapping framework warning ("device driver failed to check map error"). Reported-by: Shuah Khan <shuah.khan@hp.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: - Adjust filename, context, indentation - Use bus(trans) instead of trans where necessary - Use hw_params(trans).rx_page_order instead of trans_pcie->rx_page_order] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2013-01-03iwlwifi: don't handle masked interruptEmmanuel Grumbach1-2/+10
commit 25a172655f837bdb032e451f95441bb4acec51bb upstream. This can lead to a panic if the driver isn't ready to handle them. Since our interrupt line is shared, we can get an interrupt at any time (and CONFIG_DEBUG_SHIRQ checks that even when the interrupt is being freed). If the op_mode has gone away, we musn't call it. To avoid this the transport disables the interrupts when the hw is stopped and the op_mode is leaving. If there is an event that would cause an interrupt the INTA register is updated regardless of the enablement of the interrupts: even if the interrupts are disabled, the INTA will be changed, but the device won't issue an interrupt. But the ISR can be called at any time, so we ought ignore the value in the INTA otherwise we can call the op_mode after it was freed. I found this bug when the op_mode_start failed, and called iwl_trans_stop_hw(trans, true). Then I played with the RFKILL button, and removed the module. While removing the module, the IRQ is freed, and the ISR is called (CONFIG_DEBUG_SHIRQ enabled). Panic. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: - Adjust context - Pass bus(trans), not trans, to iwl_{read,write}32()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-10-31iwlwifi: fix 6000 series channel switch commandJohannes Berg1-15/+24
commit 8f7b8db6e0557c8437adf9371e020cd89a7e85dc upstream. The channel switch command for 6000 series devices is larger than the maximum inline command size of 320 bytes. The command is therefore refused with a warning. Fix this by allocating the command and using the NOCOPY mechanism. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-09-19iwlwifi: protect SRAM debugfsJohannes Berg1-0/+3
commit 4fc79db178f0a0ede479b4713e00df2d106028b3 upstream. If the device is not started, we can't read its SRAM and attempting to do so will cause issues. Protect the debugfs read. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: - Adjust context - Pass iwl_shared not iwl_priv pointer to iwl_is_ready_rf()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-09-19iwlwifi: fix flow handler debug codeJohannes Berg3-16/+18
commit 94543a8d4fb302817014981489f15cb3b92ec3c2 upstream. iwl_dbgfs_fh_reg_read() can cause crashes and/or BUG_ON in slub because the ifdefs are wrong, the code in iwl_dump_fh() should use DEBUGFS, not DEBUG to protect the buffer writing code. Also, while at it, clean up the arguments to the function, some code and make it generally safer. Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust filenames and context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-08-19iwlwifi: disable greenfield transmissions as a workaroundJohannes Berg1-5/+8
commit 50e2a30cf6fcaeb2d27360ba614dd169a10041c5 upstream. There's a bug that causes the rate scaling to get stuck when it has to use single-stream rates with a peer that can do GF and SGI; the two are incompatible so we can't use them together, but that causes the algorithm to not work at all, it always rejects updates. Disable greenfield for now to prevent that problem. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Tested-by: Cesar Eduardo Barros <cesarb@cesarb.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-07-04iwlwifi: remove log_event debugfs file debugging is disabledJohannes Berg1-0/+6
commit 882b7b7d11d65e8eccce738f1ce97cdfdb998f9f upstream. When debugging is disabled, the event log functions aren't functional in the way that the debugfs file expects. This leads to the debugfs access crashing. Since the event log functions aren't functional then, remove the debugfs file when CONFIG_IWLWIFI_DEBUG is not set. Reported-by: Lekensteyn <lekensteyn@gmail.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-06-20iwlwifi: disable the buggy chain extension feature in HWEmmanuel Grumbach2-0/+6
commit d012d04e4d6312ea157b6cf19e9689af934f5aa7 upstream. This feature has been reported to be buggy and enabled by default. We therefore need to disable it manually. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2 as instructed: pass bus(trans) to iwl_write_prph()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-06-20iwlwifi: use correct supported firmware for 6035 and 6000g2Meenakshi Venkataraman1-2/+20
commit d2c8b15d0cb486f4938ba7f2af349d9d1220cb10 upstream. My patch iwlwifi: use correct released ucode version did not correctly report supported firmware for the 6035 device. This patch fixes it. The minimum supported firmware version for 6035 is v6. Also correct the minimum supported firmware version for the 6000g2 series of devices. Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: - adjust context - make IWL_DEVICE_6035 identical for IWL_DEVICE_6030 except for the ucode_api_* fields] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-06-20iwlwifi: unregister LEDs if mac80211 registration failsJohannes Berg1-0/+1
commit 0e1fa7ef25004b9c1a14147bce61c15c2f1c6744 upstream. Otherwise the LEDs stick around and cause issues the next time around since they're still there but not really hooked up. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-06-20iwlwifi: disable WoWLAN if !CONFIG_PM_SLEEPJohannes Berg1-0/+2
commit fcb6ff5e2cb83e1de10631f6621f45ca3401bf61 upstream. If CONFIG_PM_SLEEP is disabled, then iwlwifi doesn't support suspend/resume handlers and thus mac80211 (correctly) refuses advertising WoWLAN. Disable WoWLAN in the driver in this case. Reported-by: Sebastian Kemper <sebastian_ml@gmx.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-06-20iwlwifi: don't mess up the SCD when removing a keyEmmanuel Grumbach1-1/+1
commit d6ee27eb13beab94056e0de52d81220058ca2297 upstream. When we remove a key, we put a key index which was supposed to tell the fw that we are actually removing the key. But instead the fw took that index as a valid index and messed up the SRAM of the device. This memory corruption on the device mangled the data of the SCD. The impact on the user is that SCD queue 2 got stuck after having removed keys. The message is the log that was printed is: Queue 2 stuck for 10000ms This doesn't seem to fix the higher queues that get stuck from time to time. Reviewed-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-06-10iwlwifi: do not use shadow registers by defaultMeenakshi Venkataraman2-5/+5
commit 66a770729a5cdd24efed8afa5258f81232d8bba2 upstream. Shadow registers in the device are meant to allow the driver to update certain device registers without needing to wake up all components of the device. However, using this feature in the device causes communication between the driver and the device to become unreliable, resulting in host command timeouts. Disable this feature by default till a fix is available for the bug. Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-06-10iwlwifi: update BT traffic load states correctlyMeenakshi Venkataraman1-0/+1
commit 882dde8eb0d49ce0f853f8f4084dde56a21fe55f upstream. When BT traffic load changes from its previous state, a new LQ command needs to be sent down to the firmware. This needs to be done only once per change. The state variable that keeps track of this change is last_bt_traffic_load. However, it was not being updated when the change had been handled. Not updating this variable was causing a flood of advanced BT config commands to be sent to the firmware. Fix this. Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-11iwlwifi: use 6000G2B for 6030 device seriesWey-Yi Guy1-2/+2
commit 1ed2ec37b44e86eaa8e0a03b908a39c80f65ee45 upstream. "iwlwifi: use correct released ucode version" change the ucode api ok from 6000G2 to 6000G2B, but it shall belong to 6030 device series, not the 6005 device series. Fix it Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-11iwlwifi: use correct released ucode versionMeenakshi Venkataraman4-18/+27
commit 78cbcf2b9dbe0565820dc7721316f9c401000a68 upstream. Report correctly the latest released version of the iwlwifi firmware for all iwlwifi-supported devices. Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-11iwlagn: allow up to uCode API 6 for 6000 devicesJohannes Berg1-2/+5
commit b914811524fbe9e91fe50845f5d7bd4316b8a6ee upstream. Since the uCode hasn't been released (yet?), warn only if using older than API 4, but load anything up to API 6. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-11iwlwifi: fix hardware queue programmingJohannes Berg2-8/+43
commit 5ef4acd58ab2abd0dd0c8e3cacd61a0dc5d73646 upstream. Newer devices have 20 (5000 series) or 30 (6000 series) hardware queues, rather than the 16 that 4965 had. This was added to the driver a long time ago, but improperly: the queue registers for the higher queues aren't just continuations of the registers for the first 16 queues, they are in other places. Therefore, the hardware would lock up when trying to activate queue 16 or above and the device would have to be restarted. Thanks goes to Emmanuel who identified this and told me how the queue programming should be done. Note that we don't use queues 20 and higher today and doing so needs more work than this. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-05-11iwlwifi: do not nulify ctx->vif on resetStanislaw Gruszka2-4/+9
commit 8db4c7e25d153fb049e81715d72fa3be3a0c3b69 upstream. ctx->vif is dereferenced in different part of iwlwifi code, so do not nullify it. This should address at least one of the possible reasons of WARNING at iwlagn_mac_remove_interface, and perhaps some random crashes when firmware reset is performed. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: - Change filename iwl-mac80211.c to iwl-core.c - Change context in iwlagn_prepare_restart()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2012-04-02iwlwifi: always monitor for stuck queuesJohannes Berg1-14/+4
commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912 upstream. If we only monitor while associated, the following can happen: - we're associated, and the queue stuck check runs, setting the queue "touch" time to X - we disassociate, stopping the monitoring, which leaves the time set to X - almost 2s later, we associate, and enqueue a frame - before the frame is transmitted, we monitor for stuck queues, and find the time set to X, although it is now later than X + 2000ms, so we decide that the queue is stuck and erroneously restart the device It happens more with P2P because there we can go between associated/unassociated frequently. Reported-by: Ben Cahill <ben.m.cahill@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-12iwlwifi: fix key removalJohannes Berg1-1/+9
commit 5dcbf480473f6c3f06ad2426b7517038a2a18911 upstream. When trying to remove a key, we always send key flags just setting the key type, not including the multicast flag and the key ID. As a result, whenever any key was removed, the unicast key 0 would be removed, causing a complete connection loss after the second rekey (the first doesn't cause a key removal). Fix the key removal code to include the key ID and multicast flag, thus removing the correct key. Reported-by: Alexander Schnaidt <alex.schnaidt@googlemail.com> Tested-by: Alexander Schnaidt <alex.schnaidt@googlemail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-03iwlwifi: fix PCI-E transport "inta" raceJohannes Berg1-2/+2
commit b49ba04a3a0382e7314d990707c21094c410425a upstream. When an interrupt comes in, we read the reason bits and collect them into "trans_pcie->inta". This happens with the spinlock held. However, there's a bug resetting this variable -- that happens after the spinlock has been released. This means that it is possible for interrupts to be missed if the reset happens after some other interrupt reasons were already added to the variable. I found this by code inspection, looking for a reason that we sometimes see random commands time out. It seems possible that this causes such behaviour, but I can't say for sure right now since it happens extremely infrequently on my test systems. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-01-26iwlagn: check for SMPS modeWey-Yi Guy2-0/+4
commit b2ccccdca46273c7b321ecf5041c362cd950da20 upstream. Check and report WARN only when its invalid Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=42621 https://bugzilla.redhat.com/show_bug.cgi?id=766071 Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-12iwlagn: fix (remove) use of PAGE_SIZEJohannes Berg2-44/+31
commit 106671369e6d046c0b3e1e72b18ad6dd9cb298b0 upstream. The ICT code erroneously uses PAGE_SIZE. The bug is that PAGE_SIZE isn't necessarily 4096, so on such platforms this code will not work correctly as we'll try to attempt to read an index in the table that the device never wrote, it always has 4096-byte pages. Additionally, the manual alignment code here is unnecessary -- Documentation/DMA-API-HOWTO.txt states: The cpu return address and the DMA bus master address are both guaranteed to be aligned to the smallest PAGE_SIZE order which is greater than or equal to the requested size. This invariant exists (for example) to guarantee that if you allocate a chunk which is smaller than or equal to 64 kilobytes, the extent of the buffer you receive will not cross a 64K boundary. Just use appropriate new constants and get rid of the alignment code. Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-12iwlagn: fix TID use bugJohannes Berg1-1/+1
commit 9a215e40d70ae63762963ab3ccc7f31dd966dc6a upstream. The driver everywhere uses max TID count as 9, which is wrong, it should be 8. I think the reason it uses 9 here is off-by-one confusion by whoever wrote this. We do use the value IWL_MAX_TID_COUNT for "not QoS/no TID" but that is completely correct even if it is 8 and not 9 since 0-7 are only valid. As a side effect, this fixes the following bug: Open BA session requested for 00:23:cd:16:8a:7e tid 8 ------------[ cut here ]------------ kernel BUG at drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h:350! ... when you do echo "tx start 8" > /sys/kernel/debug/ieee80211/*/*/*/*/agg_status Reported-by: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-12-21Merge branch 'master' of ↵John W. Linville1-3/+1
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
2011-12-19iwlwifi: update SCD BC table for all SCD queuesEmmanuel Grumbach1-3/+1
Since we configure all the queues as CHAINABLE, we need to update the byte count for all the queues, not only the AGGREGATABLE ones. Not doing so can confuse the SCD and make the fw assert. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-15Merge branch 'master' of ↵John W. Linville3-3/+12
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
2011-12-14iwlwifi: allow to switch to HT40 if not associatedWey-Yi Guy1-2/+2
My previous patch 34a5b4b6af104cf18eb50748509528b9bdbc4036 iwlwifi: do not re-configure HT40 after associated Fix the case of HT40 after association on specified AP, but it break the association for some APs and cause not able to establish connection. We need to address HT40 before and after addociation. CC: stable@vger.kernel.org #3.0+ Reported-by: Andrej Gelenberg <andrej.gelenberg@udo.edu> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Tested-by: Andrej Gelenberg <andrej.gelenberg@udo.edu> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-14iwlwifi: tx_sync only on PAN contextJohannes Berg1-0/+6
Ted reported that he couldn't connect to some APs and bisected it to the tx_sync implementation. Disable it for the BSS context to fix this issue. Reported-by: Ted Ts'o <tytso@mit.edu> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-12iwlwifi: do not set the sequence control bit is not neededWey-Yi Guy1-1/+4
Check the IEEE80211_TX_CTL_ASSIGN_SEQ flag from mac80211, then decide how to set the TX_CMD_FLG_SEQ_CTL_MSK bit. Setting the wrong bit in BAR frame whill make the firmware to increment the sequence number which is incorrect and cause unknown behavior. CC: stable@vger.kernel.org #3.0+ Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-05Merge branch 'master' of ↵John W. Linville9-42/+65
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
2011-12-02iwlwifi: change the default behavior of watchdog timerWey-Yi Guy6-9/+26
The current default watchdog timer is enabled, but we are seeing issues on legacy devices. So change the default setting of watchdog timer to per device based. But user still can use the "wd_disable" module parameter to overwrite the system setting Cc: stable@vger.kernel.org #3.0+ Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-02iwlwifi: do not re-configure HT40 after associatedWey-Yi Guy3-28/+28
The ht40 setting should not change after association unless channel switch This fix a problem we are seeing which cause uCode assert because driver sending invalid information and make uCode confuse Here is the firmware assert message: kernel: iwlagn 0000:03:00.0: Microcode SW error detected. Restarting 0x82000000. kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301 kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump: kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6 kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1 kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2 kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1 kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2 kernel: iwlagn 0000:03:00.0: 0x01008035 | data1 kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2 kernel: iwlagn 0000:03:00.0: 0x000005A7 | line kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1 kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2 kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3 kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version kernel: iwlagn 0000:03:00.0: 0x00480303 | board version kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd kernel: iwlagn 0000:03:00.0: CSR values: kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG) kernel: iwlagn 0000:03:00.0: CSR_HW_IF_CONFIG_REG: 0X00480303 kernel: iwlagn 0000:03:00.0: CSR_INT_COALESCING: 0X0000ff40 kernel: iwlagn 0000:03:00.0: CSR_INT: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_INT_MASK: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_FH_INT_STATUS: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_GPIO_IN: 0X00000030 kernel: iwlagn 0000:03:00.0: CSR_RESET: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_GP_CNTRL: 0X080403c5 kernel: iwlagn 0000:03:00.0: CSR_HW_REV: 0X000000b0 kernel: iwlagn 0000:03:00.0: CSR_EEPROM_REG: 0X07d60ffd kernel: iwlagn 0000:03:00.0: CSR_EEPROM_GP: 0X90000001 kernel: iwlagn 0000:03:00.0: CSR_OTP_GP_REG: 0X00030001 kernel: iwlagn 0000:03:00.0: CSR_GIO_REG: 0X00080044 kernel: iwlagn 0000:03:00.0: CSR_GP_UCODE_REG: 0X000093bb kernel: iwlagn 0000:03:00.0: CSR_GP_DRIVER_REG: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP1: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_UCODE_DRV_GP2: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_LED_REG: 0X00000078 kernel: iwlagn 0000:03:00.0: CSR_DRAM_INT_TBL_REG: 0X88214dd2 kernel: iwlagn 0000:03:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200 kernel: iwlagn 0000:03:00.0: CSR_ANA_PLL_CFG: 0X00000000 kernel: iwlagn 0000:03:00.0: CSR_HW_REV_WA_REG: 0X0001001a kernel: iwlagn 0000:03:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0010 kernel: iwlagn 0000:03:00.0: FH register values: kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0 kernel: iwlagn 0000:03:00.0: FH_RSCSR_CHNL0_WPTR: 0X00000060 kernel: iwlagn 0000:03:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X07030000 kernel: iwlagn 0000:03:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001 kernel: iwlagn 0000:03:00.0: FH_TSSR_TX_ERROR_REG: 0X00000000 kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries kernel: ------------[ cut here ]------------ WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407() kernel: Hardware name: 4290W4H kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2 kernel: Call Trace: kernel: [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87 kernel: [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407 kernel: [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32 kernel: [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87 kernel: [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3 kernel: [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b kernel: [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b kernel: [<ffffffff8104ba97>] ? kthread+0x7a/0x82 kernel: [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10 kernel: [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11 kernel: [<ffffffff813d21b0>] ? gs_change+0xb/0xb Cc: <stable@kernel.org> 3.1+ Reported-by: Udo Steinberg <udo@hypervisor.org> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-02iwlagn: fix HW crypto for TX-only keysJohannes Berg2-5/+11
Group keys in IBSS or AP mode are not programmed into the device since we give the key to it with every TX packet. However, we do need mac80211 to create the MMIC & PN in all cases. Move the code around to set the key flags all the time. We set them even when the key is removed again but that is obviously harmless. Cc: stable@vger.kernel.org Reported-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-11Merge branch 'master' of ↵John W. Linville1-16/+17
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
2011-11-11iwlwifi: avoid a panic when unloading the module with RF KillEmmanuel Grumbach1-16/+17
When HW RF kill switch is set to kill the radio, our NIC issues an interrupt after we stop the APM module. When we unload the module, the driver disables and cleans the interrupts before stopping the APM. So we have a real interrupt (inta not zero) pending. When this interrupts pops up the tasklet has already been killed and we crash. Here is a logical description of the flow: disable and clean interrupts synchronize interrupts kill the tasklet stop the APM <<== creates an RF kill interrupt free_irq <<== somehow our ISR is called here and we crash Here is the panic message: [ 201.313636] BUG: unable to handle kernel paging request at ffff8800911b7150 [ 201.314541] IP: [<ffffffff8106d652>] tasklet_action+0x62/0x130 [ 201.315149] PGD 1c06063 PUD db37f067 PMD db408067 PTE 80000000911b7160 [ 201.316456] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC [ 201.317324] CPU 1 [ 201.317495] Modules linked in: arc4 iwlwifi(-) mac80211 cfg80211 netconsole configfs binfmt_misc i915 drm_kms_helper drm uvcvideo i2c_algo_bit videodev dell_laptop dcdbas intel_agp dell_wmi intel_ips psmouse intel_gtt v4l2_compat_ioctl32 asix usbnet mii serio_raw video sparse_keymap firewire_ohci sdhci_pci sdhci firewire_core e1000e crc_itu_t [last unloaded: configfs] [ 201.323839] [ 201.324015] Pid: 2061, comm: modprobe Not tainted 3.1.0-rc9-wl #4 Dell Inc. Latitude E6410/0667CC [ 201.324736] RIP: 0010:[<ffffffff8106d652>] [<ffffffff8106d652>] tasklet_action+0x62/0x130 [ 201.325128] RSP: 0018:ffff88011bc43ea0 EFLAGS: 00010286 [ 201.325338] RAX: ffff88008ae70000 RBX: ffff8800911b7150 RCX: ffff88008ae70028 [ 201.325555] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88008ae70000 [ 201.325775] RBP: ffff88011bc43ec0 R08: 0000000000000000 R09: 0000000000000000 [ 201.325994] R10: 0000000000000002 R11: 0000000000000001 R12: 0000000000000001 [ 201.326212] R13: 0000000000000006 R14: 0000000000000100 R15: ffff88008e259fd8 [ 201.326431] FS: 00007f4b90ea9700(0000) GS:ffff88011bc40000(0000) knlGS:0000000000000000 [ 201.326657] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 201.326864] CR2: ffff8800911b7150 CR3: 000000008fd6d000 CR4: 00000000000006e0 [ 201.327083] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 201.327302] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 201.327521] Process modprobe (pid: 2061, threadinfo ffff88008e258000, task ffff88008ae70000) [ 201.327747] Stack: [ 201.330494] 0000000000000046 0000000000000030 0000000000000001 0000000000000006 [ 201.333870] ffff88011bc43f30 ffffffff8106cd8a ffffffff811e1016 ffff88011bc43f08 [ 201.337186] 0000000100000046 ffff88008e259fd8 0000000a10be2160 0000000000000006 [ 201.340458] Call Trace: [ 201.342994] <IRQ> [ 201.345656] [<ffffffff8106cd8a>] __do_softirq+0xca/0x250 [ 201.348185] [<ffffffff811e1016>] ? pde_put+0x76/0x90 [ 201.350730] [<ffffffff8131aeae>] ? do_raw_spin_unlock+0x5e/0xb0 [ 201.353261] [<ffffffff811e1016>] ? pde_put+0x76/0x90 [ 201.355776] [<ffffffff8163ccfc>] call_softirq+0x1c/0x30 [ 201.358287] [<ffffffff8101531d>] do_softirq+0x9d/0xd0 [ 201.360823] [<ffffffff8106cb05>] irq_exit+0xd5/0xf0 [ 201.363330] [<ffffffff8163d5d6>] do_IRQ+0x66/0xe0 [ 201.365819] [<ffffffff81632673>] common_interrupt+0x73/0x73 [ 201.368257] <EOI> Cc: <stable@kernel.org> 3.1+ Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-29 17:54:18 +0300