- 09 Jul, 2012 40 commits
-
-
Gabor Juhos authored
Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Acked-by:
Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Gabor Juhos authored
Signed-off-by:
-
Gabor Juhos authored
Signed-off-by:
-
Gabor Juhos authored
Signed-off-by:
-
Gabor Juhos authored
Signed-off-by:
-
Gabor Juhos authored
Signed-off-by:
-
Gabor Juhos authored
Signed-off-by:
-
Oskar Schirmer authored
In the list of commands CMD_802_11_EEPROM_ACCESS had been defined twice, unnecessarily, luckily with same value. Remove one occurence. Signed-off-by:
Oskar Schirmer <oskar@scara.com> Cc: Marcelo Tosatti <marcelo@kvack.org> Cc: Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Amitkumar Karwar authored
This enables user to set mode of Tx/Rx path using "iw set antenna" command. For non MIMO chips, the command will be used for selecting specific antenna or configuring antenna diversity mode. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Rajkumar Manoharan authored
On full reset, mci reset will put LNA update on 2G mode. And Whenever 2g5g_switch is forced at the end of full reset, lna update should not be skipped. Not doing so, is affecting WLAN rx and causing beacon loss when BTCOEX is enabled on AR9462. Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
-
Rajkumar Manoharan authored
The chip is waken up for every 45ms in btcoex timer cycle to for sharing the radio between BT and WLAN. Whenever the wlan interface is in network sleep mode, do not schedule hw timers. This could reduce power consumption on idle associated state. Signed-off-by:
-
Rajkumar Manoharan authored
As soon as the interface brought up, btcoex timer starts running eventhough the interface is in idle state and WLAN chip is moved to full sleep mode. There is no point in running btcoex timer when the wlan interface is in sleep mode and also it might consumes more power on WLAN idle unassociated state. So lets stop the btcoex when wlan is idle state. Signed-off-by:
-
Rajkumar Manoharan authored
Noise floor calibration is performed on longcal interval and the reading will be updated in history buffer. On rare occasions, the previous noisefloor calibration might not be completed within the period and trying to load nf reading will be failed. In such situation, postpone the nf cabliration to next cycle to give enough time to complete the calibration. This was already taken care for ar9002 chips. Signed-off-by:
-
Rajkumar Manoharan authored
noisefloor calibration has to be loaded and started after chip reset completion and restoring chainmask. Right now it is being started before MCI reset completion on full reset. Fix that. Signed-off-by:
-
Hauke Mehrtens authored
This is based on code from brcmsmac. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Hauke Mehrtens authored
This function is needed by brcmsmac. This code is based on code from the Broadcom SDK. Signed-off-by:
-
Hauke Mehrtens authored
The list of devices where nothing has to be done in bcma_pmu_resources_init() and bcma_pmu_workarounds() is longer as all the SoCs are missing there and some new devices will be added in some time later. This patch changes the default case to just log on debug level and also let the other devices which do not need any special handling into the default case, instead of adding the missing 8 SoC chip ids. Signed-off-by:
-
Hauke Mehrtens authored
These functions are doing nothing in the current code. I do not think we will need these function in the future as the corresponding functions in the Broadcom SDK are just doing something useful on chips supported by ssb or fullmac chips. Signed-off-by:
-
Hauke Mehrtens authored
This code is based on the Broadcom SDK and brcmsmac. Signed-off-by:
-
Hauke Mehrtens authored
This ID was found on the PCIe wireless card on the board of a Netgear WNDR3400 using a bcm4716. The device with this ID is identified by b43 as "Broadcom 43224 WLAN". Signed-off-by:
-
Hauke Mehrtens authored
There is not core id with 0x4329, but at the same place in the open source part of the Broadcom SDK is a check for some device with the chip id of 0x4329. The device with a chip id of 0x4329 is a full mac device, so it will never be supported by bcma, this part is running in the firmware of the device and not on the host CPU. This code is wrong and will never be used, so just remove it. Signed-off-by:
-
Hauke Mehrtens authored
The chip IDs are used all over bcma and no constants where defined. This patch adds the constants and makes bcma use them. Acked-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Hauke Mehrtens authored
This patch is based on a recent version of the Broadcom SDK. Signed-off-by:
-
Thomas Huehn authored
Some register values of bit shifts are corrected in order to support the upcoming transmission power control (tpc) for control packets as well. Signed-off-by:
Thomas Huehn <thomas@net.t-labs.tu-berlin.de> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
BTCOEX flags are set/cleared by atomic operations. We got to do the same in ath9k_btcoex_timer_resume, while clearing those BTCOEX flags. Acked-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
-
Avinash Patil authored
Parse WPS IEs from start_ap as well as change_beacon handlers and set them to FW. Beacon IEs, Probe Response IEs and Assoc Response IEs are parsed from beacon_data and set to FW with related masks. Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
Kiran Divekar <dkiran@marvell.com> Signed-off-by:
-
Avinash Patil authored
Being a fullmac driver, mwifiex takes care of populating beacon, probe response, association response WPS IEs to firmware. And firmware is responsible for constructing these frames. Advertise this to cfg80211. Signed-off-by:
-
Avinash Patil authored
This patch adds support for change_beacon handler which is needed for setting modified management IEs to driver and FW. Signed-off-by:
-
Avinash Patil authored
All IE buffers are freshly supplied. In such case, there is no need to preserve earlier buffers with same management mask and index. Signed-off-by:
-
Avinash Patil authored
While Head/Tail IEs may contain RSN/WPA IEs which needs to be set for all mgmt subtypes, beacon_ies, probe_resp_ies, assoc_resp_ies are for specific mgmt subtypes. Move them to separate function. Signed-off-by:
-
Avinash Patil authored
Pass cfg80211_beacon_data pointer instead of cfg80211_ap_settings. While setting management IEs we only need cfg80211_beacon_data of cfg80211_ap_settings which has Tail IE, Head IE and other IE elements. Signed-off-by:
-
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wirelessJohn W. Linville authored
Conflicts: net/mac80211/mlme.c
-
Emmanuel Grumbach authored
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. Reported-by:
Paul Bolle <pebolle@tiscali.nl> Cc: stable@vger.kernel.org Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Stanislaw Gruszka authored
This is iwlegacy version of: commit 342bbf3f Author: Johannes Berg <johannes.berg@intel.com> Date: Sun Mar 4 08:50:46 2012 -0800 iwlwifi: always monitor for stuck queues 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 Cc: stable@vger.kernel.org Signed-off-by:
-
Stanislaw Gruszka authored
On rt2x00_dmastart() we increase index specified by Q_INDEX and on rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries between Q_INDEX_DONE and Q_INDEX are those we currently process in the hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can submit to the hardware. According to that fix rt2x00usb_kick_queue(), as we need to submit RX entries that are not processed by the hardware. It worked before only for empty queue, otherwise was broken. Note that for TX queues indexes ordering are ok. We need to kick entries that have filled skb, but was not submitted to the hardware, i.e. started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set. From practical standpoint this fixes RX queue stall, usually reproducible in AP mode, like for example reported here: https://bugzilla.redhat.com/show_bug.cgi?id=828824Reported-and-tested-by:
Franco Miceli <fmiceli@plan.ceibal.edu.uy> Reported-and-tested-by:
Tom Horsley <horsley1953@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Bing Zhao authored
> *. CID 709078: Resource leak (RESOURCE_LEAK) > - drivers/net/wireless/mwifiex/cfg80211.c, line: 935 > Assigning: "bss_cfg" = storage returned from "kzalloc(132UL, 208U)" > - but was not free > drivers/net/wireless/mwifiex/cfg80211.c:935 Signed-off-by:
-
Eliad Peller authored
If association failed due to internal error (e.g. no supported rates IE), we call ieee80211_destroy_assoc_data() with assoc=true, while we actually reject the association. This results in the BSSID not being zeroed out. After passing assoc=false, we no longer have to call sta_info_destroy_addr() explicitly. While on it, move the "associated" message after the assoc_success check. Cc: stable@vger.kernel.org [3.4+] Signed-off-by:
Eliad Peller <eliad@wizery.com> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Sasha Levin authored
llcp_sock_getname can be called without a device attached to the nfc_llcp_sock. This would lead to the following BUG: [ 362.341807] BUG: unable to handle kernel NULL pointer dereference at (null) [ 362.341815] IP: [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0 [ 362.341818] PGD 31b35067 PUD 30631067 PMD 0 [ 362.341821] Oops: 0000 [#627] PREEMPT SMP DEBUG_PAGEALLOC [ 362.341826] CPU 3 [ 362.341827] Pid: 7816, comm: trinity-child55 Tainted: G D W 3.5.0-rc4-next-20120628-sasha-00005-g9f23eb7 #479 [ 362.341831] RIP: 0010:[<ffffffff836258e5>] [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0 [ 362.341832] RSP: 0018:ffff8800304fde88 EFLAGS: 00010286 [ 362.341834] RAX: 0000000000000000 RBX: ffff880033cb8000 RCX: 0000000000000001 [ 362.341835] RDX: ffff8800304fdec4 RSI: ffff8800304fdec8 RDI: ffff8800304fdeda [ 362.341836] RBP: ffff8800304fdea8 R08: 7ebcebcb772b7ffb R09: 5fbfcb9c35bdfd53 [ 362.341838] R10: 4220020c54326244 R11: 0000000000000246 R12: ffff8800304fdec8 [ 362.341839] R13: ffff8800304fdec4 R14: ffff8800304fdec8 R15: 0000000000000044 [ 362.341841] FS: 00007effa376e700(0000) GS:ffff880035a00000(0000) knlGS:0000000000000000 [ 362.341843] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 362.341844] CR2: 0000000000000000 CR3: 0000000030438000 CR4: 00000000000406e0 [ 362.341851] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 362.341856] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 362.341858] Process trinity-child55 (pid: 7816, threadinfo ffff8800304fc000, task ffff880031270000) [ 362.341858] Stack: [ 362.341862] ffff8800304fdea8 ffff880035156780 0000000000000000 0000000000001000 [ 362.341865] ffff8800304fdf78 ffffffff83183b40 00000000304fdec8 0000006000000000 [ 362.341868] ffff8800304f0027 ffffffff83729649 ffff8800304fdee8 ffff8800304fdf48 [ 362.341869] Call Trace: [ 362.341874] [<ffffffff83183b40>] sys_getpeername+0xa0/0x110 [ 362.341877] [<ffffffff83729649>] ? _raw_spin_unlock_irq+0x59/0x80 [ 362.341882] [<ffffffff810f342b>] ? do_setitimer+0x23b/0x290 [ 362.341886] [<ffffffff81985ede>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 362.341889] [<ffffffff8372a539>] system_call_fastpath+0x16/0x1b [ 362.341921] Code: 84 00 00 00 00 00 b8 b3 ff ff ff 48 85 db 74 54 66 41 c7 04 24 27 00 49 8d 7c 24 12 41 c7 45 00 60 00 00 00 48 8b 83 28 05 00 00 <8b> 00 41 89 44 24 04 0f b6 83 41 05 00 00 41 88 44 24 10 0f b6 [ 362.341924] RIP [<ffffffff836258e5>] llcp_sock_getname+0x75/0xc0 [ 362.341925] RSP <ffff8800304fde88> [ 362.341926] CR2: 0000000000000000 [ 362.341928] ---[ end trace 6d450e935ee18bf3 ]--- Signed-off-by:
Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
-
