summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'master' of ↵John W. Linville2011-12-0230-91/+210
|\ | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: drivers/net/wireless/iwlwifi/iwl-agn.c drivers/net/wireless/libertas/cfg.c
| * iwlwifi: change the default behavior of watchdog timerWey-Yi Guy2011-12-026-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>
| * iwlwifi: do not re-configure HT40 after associatedWey-Yi Guy2011-12-023-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>
| * iwlagn: fix HW crypto for TX-only keysJohannes Berg2011-12-022-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>
| * Revert "mac80211: clear sta.drv_priv on reconfiguration"John W. Linville2011-12-011-1/+0
| | | | | | | | | | | | | | | | This reverts commit f785d83a19bca326f79d127a413e35769afc0105. This was provoking WARNINGs from the iwlegacy drivers. Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: fill rate filter for internal scan requestsSimon Wunderlich2011-11-301-0/+6
| | | | | | | | | | | | | | | | | | | | The rates bitmap for internal scan requests shoud be filled, otherwise there will be probe requests with zero rates supported. Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * cfg80211: amend regulatory NULL dereference fixLuis R. Rodriguez2011-11-301-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Johannes' patch for "cfg80211: fix regulatory NULL dereference" broke user regulaotry hints and it did not address the fact that last_request was left populated even if the previous regulatory hint was stale due to the wiphy disappearing. Fix user reguluatory hints by only bailing out if for those regulatory hints where a request_wiphy is expected. The stale last_request considerations are addressed through the previous fixes on last_request where we reset the last_request to a static world regdom request upon reset_regdomains(). In this case though we further enhance the effect by simply restoring reguluatory settings completely. Cc: stable@vger.kernel.org Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * cfg80211: fix race on init and driver registrationLuis R. Rodriguez2011-11-301-16/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a theoretical race that if hit will trigger a crash. The race is between when we issue the first regulatory hint, regulatory_hint_core(), gets processed by the workqueue and between when the first device gets registered to the wireless core. This is not easy to reproduce but it was easy to do so through the regulatory simulator I have been working on. This is a port of the fix I implemented there [1]. [1] https://github.com/mcgrof/regsim/commit/a246ccf81f059cb662eee288aa13100f631e4cc8 Cc: stable@vger.kernel.org Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: fix race between the AGG SM and the Tx data pathEmmanuel Grumbach2011-11-281-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a packet is supposed to sent be as an a-MPDU, mac80211 sets IEEE80211_TX_CTL_AMPDU to let the driver know. On the other hand, mac80211 configures the driver for aggregration with the ampdu_action callback. There is race between these two mechanisms since the following scenario can occur when the BA agreement is torn down: Tx softIRQ drv configuration ========== ================= check OPERATIONAL bit Set the TX_CTL_AMPDU bit in the packet clear OPERATIONAL bit stop Tx AGG Pass Tx packet to the driver. In that case the driver would get a packet with TX_CTL_AMPDU set although it has already been notified that the BA session has been torn down. To fix this, we need to synchronize all the Qdisc activity after we cleared the OPERATIONAL bit. After that step, all the following packets will be buffered until the driver reports it is ready to get new packets for this RA / TID. This buffering allows not to run into another race that would send packets with TX_CTL_AMPDU unset while the driver hasn't been requested to tear down the BA session yet. This race occurs in practice and iwlwifi complains with a WARN_ON when it happens. Cc: stable@kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: fix race condition caused by late addBA responseNikolay Martynov2011-11-281-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If addBA responses comes in just after addba_resp_timer has expired mac80211 will still accept it and try to open the aggregation session. This causes drivers to be confused and in some cases even crash. This patch fixes the race condition and makes sure that if addba_resp_timer has expired addBA response is not longer accepted and we do not try to open half-closed session. Cc: stable@vger.kernel.org Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com> [some adjustments] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * ath9k: Revert change that broke AR928X on Acer Ferrari OneRafael J. Wysocki2011-11-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Revert a hunk in drivers/net/wireless/ath/ath9k/hw.c introduced by commit 2577c6e8f2320f1d2f09be122efef5b9118efee4 (ath9k_hw: Add support for AR946/8x chipsets) that caused a nasty regression to appear on my Acer Ferrari One (the box locks up entirely at random times after the wireless has been started without any way to get debug information out of it). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * rtlwifi: fix lps_lock deadlockStanislaw Gruszka2011-11-281-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rtl_lps_leave can be called from interrupt context, so we have to disable interrupts when taking lps_lock. Below is full lockdep info about deadlock: [ 93.815269] ================================= [ 93.815390] [ INFO: inconsistent lock state ] [ 93.815472] 2.6.41.1-3.offch.fc15.x86_64.debug #1 [ 93.815556] --------------------------------- [ 93.815635] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 93.815743] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes: [ 93.815832] (&(&rtlpriv->locks.lps_lock)->rlock){+.?...}, at: [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi] [ 93.815947] {SOFTIRQ-ON-W} state was registered at: [ 93.815947] [<ffffffff8108e10d>] __lock_acquire+0x369/0xd0c [ 93.815947] [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e [ 93.815947] [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79 [ 93.815947] [<ffffffffa025de34>] rtl_swlps_rf_awake+0x5a/0x76 [rtlwifi] [ 93.815947] [<ffffffffa025aec0>] rtl_op_config+0x12a/0x32a [rtlwifi] [ 93.815947] [<ffffffffa01d614b>] ieee80211_hw_config+0x124/0x129 [mac80211] [ 93.815947] [<ffffffffa01e0af3>] ieee80211_dynamic_ps_disable_work+0x32/0x47 [mac80211] [ 93.815947] [<ffffffff81075aa5>] process_one_work+0x205/0x3e7 [ 93.815947] [<ffffffff81076753>] worker_thread+0xda/0x15d [ 93.815947] [<ffffffff8107a119>] kthread+0xa8/0xb0 [ 93.815947] [<ffffffff814f3184>] kernel_thread_helper+0x4/0x10 [ 93.815947] irq event stamp: 547822 [ 93.815947] hardirqs last enabled at (547822): [<ffffffff814ea1a7>] _raw_spin_unlock_irqrestore+0x45/0x61 [ 93.815947] hardirqs last disabled at (547821): [<ffffffff814e9987>] _raw_spin_lock_irqsave+0x22/0x8e [ 93.815947] softirqs last enabled at (547790): [<ffffffff810623ed>] _local_bh_enable+0x13/0x15 [ 93.815947] softirqs last disabled at (547791): [<ffffffff814f327c>] call_softirq+0x1c/0x30 [ 93.815947] [ 93.815947] other info that might help us debug this: [ 93.815947] Possible unsafe locking scenario: [ 93.815947] [ 93.815947] CPU0 [ 93.815947] ---- [ 93.815947] lock(&(&rtlpriv->locks.lps_lock)->rlock); [ 93.815947] <Interrupt> [ 93.815947] lock(&(&rtlpriv->locks.lps_lock)->rlock); [ 93.815947] [ 93.815947] *** DEADLOCK *** [ 93.815947] [ 93.815947] no locks held by swapper/0. [ 93.815947] [ 93.815947] stack backtrace: [ 93.815947] Pid: 0, comm: swapper Not tainted 2.6.41.1-3.offch.fc15.x86_64.debug #1 [ 93.815947] Call Trace: [ 93.815947] <IRQ> [<ffffffff814dfd00>] print_usage_bug+0x1e7/0x1f8 [ 93.815947] [<ffffffff8101a849>] ? save_stack_trace+0x2c/0x49 [ 93.815947] [<ffffffff8108d55c>] ? print_irq_inversion_bug.part.18+0x1a0/0x1a0 [ 93.815947] [<ffffffff8108dc8a>] mark_lock+0x106/0x220 [ 93.815947] [<ffffffff8108e099>] __lock_acquire+0x2f5/0xd0c [ 93.815947] [<ffffffff810152af>] ? native_sched_clock+0x34/0x36 [ 93.830125] [<ffffffff810152ba>] ? sched_clock+0x9/0xd [ 93.830125] [<ffffffff81080181>] ? sched_clock_local+0x12/0x75 [ 93.830125] [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi] [ 93.830125] [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e [ 93.830125] [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi] [ 93.830125] [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79 [ 93.830125] [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi] [ 93.830125] [<ffffffff81422467>] ? skb_dequeue+0x62/0x6d [ 93.830125] [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi] [ 93.830125] [<ffffffffa025f677>] _rtl_pci_ips_leave_tasklet+0xe/0x10 [rtlwifi] [ 93.830125] [<ffffffff8106281f>] tasklet_action+0x8d/0xee [ 93.830125] [<ffffffff810629ce>] __do_softirq+0x112/0x25a [ 93.830125] [<ffffffff814f327c>] call_softirq+0x1c/0x30 [ 93.830125] [<ffffffff81010bf6>] do_softirq+0x4b/0xa1 [ 93.830125] [<ffffffff81062d7d>] irq_exit+0x5d/0xcf [ 93.830125] [<ffffffff814f3b7e>] do_IRQ+0x8e/0xa5 [ 93.830125] [<ffffffff814ea533>] common_interrupt+0x73/0x73 [ 93.830125] <EOI> [<ffffffff8108b825>] ? trace_hardirqs_off+0xd/0xf [ 93.830125] [<ffffffff812bb6d5>] ? intel_idle+0xe5/0x10c [ 93.830125] [<ffffffff812bb6d1>] ? intel_idle+0xe1/0x10c [ 93.830125] [<ffffffff813f8d5e>] cpuidle_idle_call+0x11c/0x1fe [ 93.830125] [<ffffffff8100e2ef>] cpu_idle+0xab/0x101 [ 93.830125] [<ffffffff814c6373>] rest_init+0xd7/0xde [ 93.830125] [<ffffffff814c629c>] ? csum_partial_copy_generic+0x16c/0x16c [ 93.830125] [<ffffffff81d4bbb0>] start_kernel+0x3dd/0x3ea [ 93.830125] [<ffffffff81d4b2c4>] x86_64_start_reservations+0xaf/0xb3 [ 93.830125] [<ffffffff81d4b140>] ? early_idt_handlers+0x140/0x140 [ 93.830125] [<ffffffff81d4b3ca>] x86_64_start_kernel+0x102/0x111 Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=755154 Reported-by: vjain02@students.poly.edu Reported-and-tested-by: Oliver Paukstadt <pstadt@sourcentral.org> Cc: stable@vger.kernel.org Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: don't stop a single aggregation session twiceJohannes Berg2011-11-281-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Nikolay noticed (by code review) that mac80211 can attempt to stop an aggregation session while it is already being stopped. So to fix it, check whether stop is already being done and bail out if so. Also move setting the STOPPING state into the lock so things are properly atomic. Cc: stable@vger.kernel.org Reported-by: Nikolay Martynov <mar.kolya@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * nl80211: fix MAC address validationEliad Peller2011-11-281-2/+2
| | | | | | | | | | | | | | | | | | | | MAC addresses have a fixed length. The current policy allows passing < ETH_ALEN bytes, which might result in reading beyond the buffer. Cc: stable@vger.kernel.org Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * Revert "rt2800pci: handle spurious interrupts"John W. Linville2011-11-221-6/+1
| | | | | | | | | | | | | | | | | | This reverts commit 4ba7d9997869d25bd223dea7536fc1ce9fab3b3b. The original patch was a misguided attempt to improve performance on some hardware that is apparently prone to spurious interrupt generation. Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * Revert "rt2x00: handle spurious pci interrupts"John W. Linville2011-11-223-3/+3
| | | | | | | | | | | | | | | | | | This reverts commit 23085d5796561625db4143a671f1de081f66ef08. The original patch was a misguided attempt to improve performance on some hardware that is apparently prone to spurious interrupt generation. Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * prism54: potential memory corruption in prism54_get_essid()Dan Carpenter2011-11-211-1/+1
| | | | | | | | | | | | | | "dwrq->length" is the capped version of "essid->length". Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * cfg80211: fix regulatory NULL dereferenceJohannes Berg2011-11-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | By the time userspace returns with a response to the regulatory domain request, the wiphy causing the request might have gone away. If this is so, reject the update but mark the request as having been processed anyway. Cc: Luis R. Rodriguez <lrodriguez@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: Fix endian bug in radiotap header generationHelmut Schaa2011-11-211-4/+4
| | | | | | | | | | | | | | | | | | I intoduced this bug in commit a2fe81667410723d941a688e1958a49d67ca3346 "mac80211: Build TX radiotap header dynamically" Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: Fix AMSDU rate printout in debugfs.Ben Greear2011-11-211-2/+2
| | | | | | | | | | | | | | | | | | It was flipped. See section 7.3.2.56 of the 802.11n spec for details. Signed-off-by: Ben Greear <greearb@candelatech.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * p54spi: Fix workqueue deadlockMichael Büsch2011-11-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | priv->work must not be synced while priv->mutex is locked, because the mutex is taken in the work handler. Move cancel_work_sync down to after the device shutdown code. This is safe, because the work handler checks fw_state and bails out early in case of a race. Signed-off-by: Michael Buesch <m@bues.ch> Cc: <stable@vger.kernel.org> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * p54spi: Add missing spin_lock_initMichael Büsch2011-11-171-0/+1
| | | | | | | | | | | | | | | | | | The tx_lock is not initialized properly. Add spin_lock_init(). Signed-off-by: Michael Buesch <m@bues.ch> Cc: <stable@vger.kernel.org> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * rt2x00: Fix efuse EEPROM reading on PPC32.Gertjan van Wingerde2011-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Fix __le32 to __le16 conversion of the first word of an 8-word block of EEPROM read via the efuse method. Reported-and-tested-by: Ingvar Hagelund <ingvar@redpill-linpro.com> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> CC: <stable@vger.kernel.org> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * rt2x00: handle spurious pci interruptsStanislaw Gruszka2011-11-173-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have documented case of very bad performance issue on rt2800pci device, because it generate spurious interrupt, what cause irq line is disabled: https://bugzilla.redhat.com/show_bug.cgi?id=658451 We already address that problem in separate patch by returning IRQ_HANDLED from interrupt handler. We think similar fix is needed for other rt2x00 PCI devices, because users report performance problems on these devices too. Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * rt2800pci: handle spurious interruptsStanislaw Gruszka2011-11-171-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some devices may generate spurious interrupts, we have to handle them otherwise interrupt line will be disabled with below message and driver will not work: [ 2052.114334] irq 17: nobody cared (try booting with the "irqpoll" option) [ 2052.114339] Pid: 0, comm: swapper Tainted: P 2.6.35.6-48.fc14.x86_64 #1 [ 2052.114341] Call Trace: [ 2052.114342] <IRQ> [<ffffffff810a6e2b>] __report_bad_irq.clone.1+0x3d/0x8b [ 2052.114349] [<ffffffff810a6f93>] note_interrupt+0x11a/0x17f [ 2052.114352] [<ffffffff810a7a73>] handle_fasteoi_irq+0xa8/0xce [ 2052.114355] [<ffffffff8100c2ea>] handle_irq+0x88/0x90 [ 2052.114357] [<ffffffff8146f034>] do_IRQ+0x5c/0xb4 [ 2052.114360] [<ffffffff81469593>] ret_from_intr+0x0/0x11 [ 2052.114361] <EOI> [<ffffffff8102b7f9>] ? native_safe_halt+0xb/0xd [ 2052.114366] [<ffffffff81010f03>] ? need_resched+0x23/0x2d [ 2052.114367] [<ffffffff8101102a>] default_idle+0x34/0x4f [ 2052.114370] [<ffffffff81008325>] cpu_idle+0xaa/0xcc [ 2052.114373] [<ffffffff81461f2a>] start_secondary+0x24d/0x28e [ 2052.114374] handlers: [ 2052.114375] [<ffffffff81332944>] (usb_hcd_irq+0x0/0x7c) [ 2052.114378] [<ffffffffa00697da>] (rt2800pci_interrupt+0x0/0x18d [rt2800pci]) [ 2052.114384] Disabling IRQ #17 Resolve: https://bugzilla.redhat.com/show_bug.cgi?id=658451 Reported-and-tested-by: Amir Hedayaty <hedayaty@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * Net, libertas: Resolve memory leak in if_spi_host_to_card()Jesper Juhl2011-11-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | If we hit the default case in the switch in if_spi_host_to_card() we'll leak the memory we allocated for 'packet'. This patch resolves the leak by freeing the allocated memory in that case. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Acked-by: Dan Williams <dcbw@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * rt2x00: Fix sleep-while-atomic bug in powersaving code.Gertjan van Wingerde2011-11-152-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The generic powersaving code that determines after reception of a frame whether the device should go back to sleep or whether is could stay awake was calling rt2x00lib_config directly from RX tasklet context. On a number of the devices this call can actually sleep, due to having to confirm that the sleeping commands have been executed successfully. Fix this by moving the call to rt2x00lib_config to a workqueue call. This fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=731672 Tested-by: Tomas Trnka <tomastrnka@gmx.com> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Cc: <stable@vger.kernel.org> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * rt2x00: Add USB device ID of Buffalo WLI-UC-GNHP.Gertjan van Wingerde2011-11-151-0/+1
| | | | | | | | | | | | | | | | | | This is reported to be an RT3070 based device. Reported-by: Teika Kazura <teika@lavabit.com> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mwifiex: fix association issue with AP configured in hidden SSID modeAmitkumar Karwar2011-11-111-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Firmware expects 'max_ssid_length' field in 'struct mwifiex_ie_types_wildcard_ssid_params' to be '0' for performing SSID specific scan. Currently driver updates it with an actual SSID length. Hence UUT is not able to find the AP configured in hidden SSID mode in scan results and association fails. max_ssid_length is filled with '0' to fix the issue. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * iwlwifi: avoid a panic when unloading the module with RF KillEmmanuel Grumbach2011-11-111-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>
| * mac80211: fix race between connection monitor & suspendJohannes Berg2011-11-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the connection monitor timer fires right before suspend, the following will happen: timer fires -> monitor_work gets queued suspend calls ieee80211_sta_quiesce ieee80211_sta_quiesce: - deletes timer - cancels monitor_work synchronously, running it [note wrong order of these steps] monitor_work runs, re-arming the timer later, timer fires while system should be quiesced This causes a warning: WARNING: at net/mac80211/util.c:540 ieee80211_can_queue_work+0x35/0x40 [mac80211]() but is otherwise harmless. I'm not completely sure this is the scenario Thomas stumbled across, but it is the only way I can right now see the warning in a scenario like the one he reported. Reported-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * wireless: libertas: fix unaligned le64 accessesSteven Miao2011-11-091-1/+1
| | | | | | | | | | | | | | | | use get_unaligned_le64() to get timestamp Signed-off-by: Steven Miao <realmz6@gmail.com> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * cfg80211: fix bug on regulatory core exit on access to last_requestLuis R. Rodriguez2011-11-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4d9d88d1 by Scott James Remnant <keybuk@google.com> added the .uevent() callback for the regulatory device used during the platform device registration. The change was done to account for queuing up udev change requests through udevadm triggers. The change also meant that upon regulatory core exit we will now send a uevent() but the uevent() callback, reg_device_uevent(), also accessed last_request. Right before commiting device suicide we free'd last_request but never set it to NULL so platform_device_unregister() would lead to bogus kernel paging request. Fix this and also simply supress uevents right before we commit suicide as they are pointless. This fix is required for kernels >= v2.6.39 $ git describe --contains 4d9d88d1 v2.6.39-rc1~468^2~25^2^2~21 The impact of not having this present is that a bogus paging access may occur (only read) upon cfg80211 unload time. You may also get this BUG complaint below. Although Johannes could not reproduce the issue this fix is theoretically correct. mac80211_hwsim: unregister radios mac80211_hwsim: closing netlink BUG: unable to handle kernel paging request at ffff88001a06b5ab IP: [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211] PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU 0 Modules linked in: cfg80211(-) [last unloaded: mac80211] Pid: 2279, comm: rmmod Tainted: G W 3.1.0-wl+ #663 Bochs Bochs RIP: 0010:[<ffffffffa030df9a>] [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211] RSP: 0000:ffff88001c5f9d58 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0 RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0 R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001 FS: 00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780) Stack: ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2 000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820 ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189 Call Trace: [<ffffffff812ff7e5>] dev_uevent+0xc5/0x170 [<ffffffff81241dc7>] kobject_uevent_env+0x1f7/0x490 [<ffffffff81040189>] ? sub_preempt_count+0x29/0x60 [<ffffffff814cab1a>] ? _raw_spin_unlock_irqrestore+0x4a/0x90 [<ffffffff81305307>] ? devres_release_all+0x27/0x60 [<ffffffff8124206b>] kobject_uevent+0xb/0x10 [<ffffffff812fee27>] device_del+0x157/0x1b0 [<ffffffff8130377d>] platform_device_del+0x1d/0x90 [<ffffffff81303b76>] platform_device_unregister+0x16/0x30 [<ffffffffa030fffd>] regulatory_exit+0x5d/0x180 [cfg80211] [<ffffffffa032bec3>] cfg80211_exit+0x2b/0x45 [cfg80211] [<ffffffff8109a84c>] sys_delete_module+0x16c/0x220 [<ffffffff8108a23e>] ? trace_hardirqs_on_caller+0x7e/0x120 [<ffffffff814cba02>] system_call_fastpath+0x16/0x1b Code: <all your base are belong to me> RIP [<ffffffffa030df9a>] reg_device_uevent+0x1a/0x50 [cfg80211] RSP <ffff88001c5f9d58> CR2: ffff88001a06b5ab ---[ end trace 147c5099a411e8c0 ]--- Reported-by: Johannes Berg <johannes@sipsolutions.net> Cc: Scott James Remnant <keybuk@google.com> Cc: stable@vger.kernel.org Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: fix bug in ieee80211_build_probe_reqJohannes Berg2011-11-091-0/+4
| | | | | | | | | | | | | | | | | | | | ieee80211_probereq_get() can return NULL in which case we should clean up & return NULL in ieee80211_build_probe_req() as well. Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * mac80211: fix NULL dereference in radiotap codeJohannes Berg2011-11-091-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When receiving failed PLCP frames is enabled, there won't be a rate pointer when we add the radiotap header and thus the kernel will crash. Fix this by not assuming the rate pointer is always valid. It's still always valid for frames that have good PLCP though, and that is checked & enforced. This was broken by my commit fc88518916793af8ad6a02e05ff254d95c36d875 Author: Johannes Berg <johannes.berg@intel.com> Date: Fri Jul 30 13:23:12 2010 +0200 mac80211: don't check rates on PLCP error frames where I removed the check in this case but didn't take into account that the rate info would be used. Reported-by: Xiaokang Qin <xiaokang.qin@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k_hw: add default chainmask for AR9462Mohammed Shafi Shajakhan2011-11-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | the default tx/rx chainmask for AR9462 is 0x3. this patch helps to assign 0x3 rather than 0x7 for AR9462 with the help of fix_chainmask module if something goes wrong in reading tx/rx chain mask from OTP/EEPROM card(though its very unlikely) Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k_hw: Fix TX IQ calibration for AR9003Mohammed Shafi Shajakhan2011-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | only for AR9485 (or) later chipsets TxIQ calibration runs as part of AGC calibration. without this patch TX IQ cal completion i.e. ar9003_hw_tx_iq_cal_run won't be executed for AR9003 Reviewed-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | NFC: pn533: Staticise pn533_data_exchange()Axel Lin2011-11-301-1/+1
| | | | | | | | | | | | | | It is not used outside this driver so no need to make the symbol global. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | brcm80211: fmac: small memory leak on errorDan Carpenter2011-11-301-1/+3
| | | | | | | | | | | | | | | | We should free "bus_if" here, it's a small leak but it makes the static checkers happy. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k: minor cleanupMohammed Shafi Shajakhan2011-11-301-1/+0
| | | | | | | | | | Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k: fix a typoMohammed Shafi Shajakhan2011-11-301-1/+1
| | | | | | | | | | | | | | | | Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k: MCI state machine based on MCI interruptMohammed Shafi Shajakhan2011-11-305-1/+359
| | | | | | | | | | | | | | | | Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k_hw: Add MCI related changes in chip resetMohammed Shafi Shajakhan2011-11-301-0/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | here we check for BT state and if BT calibration has started, give 25ms for BT Calibration to finish. we also take care of 2G/5G switch and LNA transfer incase WLAN is operating in 5G. in case the BT state is awake when we do WLAN calibration re-calibrate and we reset the message exchange between WLAN and BT. BT is given preference when simultaneous CAL request happens. calibration for WLAN/BT is done assuming that the other co-existing module is in awake state, if not we continue to do calibration while if the other module's state changes we need to do restart the calibration handshake Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k_hw: Add support for MCI WLAN calibrationMohammed Shafi Shajakhan2011-11-301-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | WLAN communicates with BT for its calibration by sending WLAN_CAL_REQ, waits for BT_CAL_GRANT. This is done with the help of GPM messages. also WLAN_CAL_DONE messages is sent once WLAN calibration is done. Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k_hw: MCI related changes in set_reset_regMohammed Shafi Shajakhan2011-11-301-3/+11
| | | | | | | | | | | | | | | | Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k_hw: MCI related changes in chip managementMohammed Shafi Shajakhan2011-11-302-0/+26
| | | | | | | | | | | | | | | | | | | | | | send halt BT GPM if the chip is in network sleep and BT state is awake Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k: Add functions to allocate/free buffers for MCIMohammed Shafi Shajakhan2011-11-303-0/+81
| | | | | | | | | | | | | | | | | | | | | | required buffers and dma allocation is done for GPM and SCHED messages Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k: add MCI specific definitions and structuresMohammed Shafi Shajakhan2011-11-301-0/+17
| | | | | | | | | | | | | | | | Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k_hw: check for MCI interrupt in get_isrMohammed Shafi Shajakhan2011-11-301-2/+34
| | | | | | | | | | | | | | | | | | | | | | | | check for the condition of MCI interrupt being triggered and appropriately obtain the values of MCI_INTERRUPT_RX_MSG_RAW and MCI_INTERRUPT_RAW Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | ath9k_hw: check for asynchronous MCI interrupt pendingMohammed Shafi Shajakhan2011-11-301-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | MCI interrupt is an asynchronous one, so take care of it by having a check in ath9k_hw_intrpend, which actually decides whether the interrupt is really for the driver from ath_isr Cc: Wilson Tsao <wtsao@qca.qualcomm.com> Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
OpenPOWER on IntegriCloud