summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2013-03-25wlcore: set max num of Rx BA sessions per chipIgal Chernobelsky7-4/+11
Maximum number of supported RX BA sessions depends on chip type. wl18xx supports 5 RX BA sessions while wl12xx supports 3. Signed-off-by: Igal Chernobelsky <igalc@ti.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
2013-03-25wlcore: enter elp in force ps mode in 5msIgal Chernobelsky1-1/+3
It is requiered to enter sleep mode with smaller delay in forced PS mode. This fixes issue of testing force PS mode during VoIP traffic where packets are sent every 20ms. Chip never enters ps mode with default 30 ms delay in such test. Signed-off-by: Igal Chernobelsky <igalc@ti.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
2013-03-05wl1251: call pm_runtime_put_sync in pm_runtime_get_sync failed caseLi Fei1-1/+3
Even in failed case of pm_runtime_get_sync, the usage_count is incremented. In order to keep the usage_count with correct value and runtime power management to behave correctly, call pm_runtime_put(_sync) in such case. Signed-off-by Liu Chuansheng <chuansheng.liu@intel.com> Signed-off-by: Li Fei <fei.li@intel.com> Signed-off-by: Luciano Coelho <coelho@ti.com>
2013-02-18net: wireless: hostap: hostap_ap.c: Return -ENOMEM instead of -1 for if ↵Kumar Amit Mehta1-1/+1
kmalloc() fails. When memory allocation using, kmalloc() fails, report appropriate error value. Signed-off-by: Kumar Amit Mehta <gmate.amit@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-18net: wireless: orinoco: orinoco_usb.c: fix DMA buffers on stackKumar Amit Mehta1-2/+9
This patch fixes an instance of DMA buffer on stack(being passed to usb_control_msg) for the wireless USB version of the Agere Orinoco card driver. It also fixes the missing audit for the return value of firmware download routine. Found using smatch. Signed-off-by: Kumar Amit Mehta <gmate.amit@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-18rtlwifi: usb: allocate URB control message setup_packet and data buffer ↵Jussi Kivilinna1-16/+28
separately rtlwifi allocates both setup_packet and data buffer of control message urb, using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for allocating is: struct { u8 data[254]; struct usb_ctrlrequest dr; }; Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory corruptions and freezes. Patch changes setup packet to be allocated separately. [v2]: - Use WARN_ON_ONCE instead of WARN_ON Cc: <stable@vger.kernel.org> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-18mwifiex: add 802.11AC supportYogesh Ashok Powar16-42/+830
For STA mode, collect VHT realated IEs from the Beacons or Probe Responses and append similar VHT related IEs to association requests. For AP mode, get VHT related capability information and share it with cfg80211 at the time of wiphy register. This information is further used by cfg80211 and hostapd to start an AP with 802.11AC support. Currently only 8897 supports 802.11AC. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Nishant Sarmukadam <nishants@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Frank Huang <frankh@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-18mwifiex: coding style cleanup in bss parameter updateYogesh Ashok Powar1-10/+5
They all can make one line. Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-18mwifiex: fix empty TX ring check for PCIe8897 while unloading driverAvinash Patil1-4/+1
While unloading driver, we free all pending TX packets by flushing TX ring. There is unhandled case for PCIE8897 while checking for ring empty condition. This patch adds the handling by calling mwifiex_pcie_txbd_empty(). Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-02-18Merge branch 'for-john' of ↵John W. Linville15-334/+309
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
2013-02-18iwlwifi: dvm: improve (again) the prints in reclaim pathEmmanuel Grumbach2-15/+37
I removed a bit too much info last time. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: dvm: fix delayed enter to CT-kill bugEytan Lifshitz1-1/+1
Theoretically, the card may not enter CTKILL: In case the timer that iwl_prepare_ct_kill_task is setting, will expire before tt->state revert to its previous state. Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: Reserve MAC id 0 for managed interfacesIlan Peer1-0/+4
Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: Fix resource allocation for P2P DeviceIlan Peer1-3/+3
The time event data structures are required also for P2P Device interface. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: Set the scan type according to the vif typeIlan Peer1-1/+6
The FW can differentiate between scans, according to the interface type on which the scan was issues. Supply the interfaces type information to the FW. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: fix time event command handling raceJohannes Berg1-1/+6
Occasionally, we would run into this warning: iwlwifi 0000:02:00.0: U iwl_mvm_protect_session extend 0x2601: only 200 ms left iwlwifi 0000:02:00.0: U iwl_mvm_remove_time_event Removing TE 0x2601 iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0925, 60 bytes at 37[5]:9 iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TIME_EVENT_CMD iwlwifi 0000:02:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TIME_EVENT_CMD iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command TIME_EVENT_CMD (#29), seq: 0x0926, 60 bytes at 38[6]:9 iwlwifi 0000:02:00.0: U iwl_mvm_time_event_response TIME_EVENT_CMD response - UID = 0x2601 iwlwifi 0000:02:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TIME_EVENT_CMD iwlwifi 0000:02:00.0: U iwl_mvm_rx_time_event_notif Time event notification - UID = 0x2701 action 1 wlan0: associate with 00:0a:b8:55:a8:30 (try 2/3) ------------[ cut here ]------------ WARNING: at drivers/net/wireless/iwlwifi/mvm/time-event.c:269 iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm]() Modules linked in: [...] Call Trace: [<c1046e42>] warn_slowpath_common+0x72/0xa0 [<c1046e92>] warn_slowpath_null+0x22/0x30 [<f8cad913>] iwl_mvm_time_event_send_add+0x163/0x1a0 [iwlmvm] [<f8cadead>] iwl_mvm_protect_session+0xcd/0x1c0 [iwlmvm] [<f8ca2087>] iwl_mvm_mac_mgd_prepare_tx+0x67/0xa0 [iwlmvm] [<f882a130>] ieee80211_sta_work+0x8f0/0x1070 [mac80211] The reason is a problem with asynchronous vs. synchronous commands, what happens here is the following: * TE 0x2601 is removed, the TIME_EVENT_CMD for that is async * a new TE (will be 0x2701) is created, the TIME_EVENT_CMD for that is sync and also uses a notification wait for the response (to avoid another race condition) * the response for the TE 0x2601 removal comes from the firmware, and is handled by the notification wait handler that's really waiting for the second response, but can't tell the difference, we therefore see the message "TIME_EVENT_CMD response - UID = 0x2601" instead of "TIME_EVENT_CMD response - UID = 0x2701". Fix this issue by making the TE removal synchronous as well, this means that we wait for the response to that command first, before there's any chance of sending a new one. Also, to detect such issues more easily in the future, add a warning to the notification handler that detects them. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: add debug statement to time event addJohannes Berg1-0/+3
This is helpful for debugging the time event warning, but also in general to see what's going on. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: fix GO powersave client manipulationJohannes Berg3-10/+16
All station commands must include a valid MAC ID, the ID 0 is randomly valid in some cases, but we must set the ID properly. Do that by passing the right station and using its mac_id_n_color. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: program DTIM timings properlyJohannes Berg3-3/+38
For the firmware to know when DTIM beacons arrive we have to program the DTIM time in TSF and system time in the MAC context. Since mac80211 now tracks the different times (on demand), this becomes easy. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18iwlwifi: mvm: fix merge errorJohannes Berg1-1/+0
The iwlwifi-next tree removed IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC while the mac80211-next tree removed Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18Merge remote-tracking branch 'wireless-next/master' into iwlwifi-nextJohannes Berg118-1652/+4306
2013-02-18cfg80211: fix station change if TDLS isn't supportedJohannes Berg1-9/+0
Larry noticed (and bisected) that commit df881293c6ba9a12868491a717b25 "cfg80211: Pass TDLS peer's QoS/HT/VHT information during set_station" broke secure connections. This is is the case only for drivers that don't support TDLS, where any kind of change, even just the change of authorized flag that is required for normal operation, was rejected now. To fix this, remove the checks. I have some patches that will add proper verification for all the different cases later. Cc: Jouni Malinen <j@w1.fi> Bisected-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18mac80211: don't spam mesh probe response messagesThomas Pedersen1-1/+0
If mesh plink debugging is enabled, this gets annoying in a crowded environment, fast. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18mac80211: stringify mesh peering eventsThomas Pedersen1-14/+24
Convert mesh peering events into strings and make the debug output a little easier to read. Also stop printing the llid and plid since these don't change across peering states and are random numbers anyway so they just amount to noise. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18mac80211: clean up mesh HT operationThomas Pedersen2-40/+24
ieee80211_ht_cap_ie_to_sta_ht_cap() will clean up the ht_supported flag and station bandwidth field for us if the peer beacon doesn't have an HT capability element (is operating as non-HT). Also, we don't really need a special station ch_width member to track the station operating mode any more so use sta.bandwidth instead. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18mac80211: fix harmless station flush warningJohannes Berg1-2/+3
If an interface is set down while authenticating or associating, there's a station entry that will be removed by the flushing in do_stop() and that will cause a warning. It's otherwise harmless, but avoid the warning by calling ieee80211_mgd_stop() first. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-18cfg80211: add correct docbook entriesJohannes Berg1-2/+2
Update the 802.11 book to list the correct data structures. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: Fix incorrect use of STA_PR_FMT in trace pointsSeth Forshee1-3/+3
Several tracepoints are using STA_PR_FMT where STA_PR_ARG should be used, resulting in messages like "phy0 sta:ARG TYPE NOT FIELD BUT 1". Change these to STA_PR_ARG. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15Merge branch 'for-linville' of git://github.com/kvalo/ath6klJohn W. Linville8-96/+119
2013-02-15Merge branch 'for-john' of ↵John W. Linville65-833/+3160
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
2013-02-15mac80211: enable vif.cab_queue for meshBob Copeland1-1/+2
Since mesh powersaving was added, pending bcast/mcast frames may go out the CAB queue now. Unfortunately, the queue was only set up for AP mode, so we would try to tx on the IEEE80211_INVAL_HW_QUEUE. Allow cab_queue for mesh interfaces as well. Fixes the following warning (or crash without MAC80211_VERBOSE_DEBUG): WARNING: at net/mac80211/tx.c:1223 __ieee80211_tx+0x162/0x35f [mac80211]() Modules linked in: mac80211_hwsim mac80211 cfg80211 [...] Pid: 3085, comm: avahi-daemon Tainted: G W 3.8.0-rc1+ #377 Call Trace: [<ffffffff81045c20>] warn_slowpath_common+0x83/0x9c [<ffffffff81045c53>] warn_slowpath_null+0x1a/0x1c [<ffffffffa083aef0>] __ieee80211_tx+0x162/0x35f [mac80211] [<ffffffffa083cb1d>] ieee80211_tx+0xd3/0xf9 [mac80211] [<ffffffffa083cc0f>] ieee80211_xmit+0xcc/0xd5 [mac80211] [<ffffffffa083db59>] ieee80211_subif_start_xmit+0xc53/0xcd8 [mac80211] [<ffffffff81319acd>] dev_hard_start_xmit+0x259/0x3ce [<ffffffff81333d6b>] sch_direct_xmit+0x74/0x17d [<ffffffff8131a0b1>] dev_queue_xmit+0x230/0x414 [<ffffffff8134877a>] ip_finish_output2+0x348/0x3aa [<ffffffff81349029>] ip_finish_output+0x6c/0x71 [<ffffffff81349046>] NF_HOOK_COND.constprop.44+0x18/0x58 [<ffffffff8134a03a>] ip_mc_output+0x134/0x13c [<ffffffff8134835a>] dst_output+0x18/0x1c [<ffffffff81349a24>] ip_local_out+0x20/0x24 [<ffffffff8134a8cf>] ip_send_skb+0x16/0x3c [<ffffffff8136bfba>] udp_send_skb+0x254/0x2b9 [<ffffffff8136c85e>] udp_sendmsg+0x5a8/0x7d4 Signed-off-by: Bob Copeland <bob@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: clean up mesh codeJohannes Berg10-263/+252
There's various code with strange indentation, questionable loop and locking constructs, etc. The bigger change is moving the "sdata" argument to the first argument of all functions, like all other mac80211 functions that have one. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211_hwsim: ask mac80211 to reserve space for chanctx.drv_privKarl Beldan1-0/+1
Otherwise memory corruption occurs when using channel contexts (ATM when param 'channel' > 1). Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: prevent spurious HT/VHT downgrade messageJohannes Berg1-0/+4
Even when connecting to an AP that doesn't support VHT, and even when the local device doesn't support it either, the downgrade message gets printed. Suppress the message if HT and/or VHT is disabled. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15nl80211: renumber NL80211_FEATURE_FULL_AP_CLIENT_STATEJohannes Berg2-3/+3
Adding the flag to mac80211 already without testing was clearly a mistake, one that we now pay for by having to reserve bit 13 forever. The problem is cfg80211 doesn't allow capability/rate changes for station entries that were added unassociated, so the station entries cannot be set up properly when marked associated. Change the NL80211_FEATURE_FULL_AP_CLIENT_STATE value to make it clear to userspace implementations that all current kernels don't actually support it, even though the previous bit is set, and of course also remove the flag from mac80211 until we test and fix the issues. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15cfg80211: Pass TDLS peer's QoS/HT/VHT information during set_stationJouni Malinen2-11/+85
The information of the peer's capabilities is required for the driver to perform TDLS Peer UAPSD operations. This information of the peer is passed by the supplicant using NL80211_CMD_SET_STATION command. This commit enhances the function nl80211_set_station to pass this information of the peer to the driver in case this command is used with the TDLS peer STA. In addition, make the HT/VHT capability configuration handled more consistently for other STA cases (reject both instead of just HT). Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15cfg80211: Pass station (extended) capability info to kernelJouni Malinen3-0/+54
The information of the peer's capabilities and extended capabilities are required for the driver to perform TDLS Peer UAPSD operations and off channel operations. This information of the peer is passed from user space using NL80211_CMD_SET_STATION command. This commit enhances the function nl80211_set_station to pass the capability information of the peer to the driver. Similarly, there may be need for capability information for other modes, so allow this to be provided with both add_station and change_station. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: advertise operating mode notification capabilityJohannes Berg2-0/+11
Use the new extended capabilities advertising to advertise the fact that operating mode notification is supported. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15cfg80211: advertise extended capabilities to userspaceJohannes Berg3-0/+29
In many cases, userspace may need to know which of the 802.11 extended capabilities ("Extended Capabilities element") are implemented in the driver or device, to include them e.g. in beacons, assoc request/response or other frames. Add a new nl80211 attribute to hold the extended capabilities bitmap for this. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: stop modifying HT SMPS capabilityJohannes Berg11-48/+50
Instead of modifying the HT SMPS capability field for stations, track the SMPS mode explicitly in a new field in the station struct and use it in the drivers that care about it. This simplifies the code using it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: generate mesh probe responsesThomas Pedersen2-2/+63
Mesh interfaces will now respond to any broadcast (or matching directed mesh) probe requests with a probe response. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: cache mesh beaconThomas Pedersen6-65/+171
Previously, the entire mesh beacon would be generated each time the beacon timer fired. Instead generate a beacon head and tail (so the TIM can easily be inserted when mesh power save is on) when starting a mesh or the MBSS parameters change. Also add a mutex for protecting beacon updates and preventing leaks. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: constify IE parsingJohannes Berg9-87/+96
Make all the parsed IE pointers const, and propagate the change to all the users etc. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15nl80211: advertise HT/VHT channel limitationsJohannes Berg3-1/+31
When drivers or regulatory have limitations on 40, 80 or 160 MHz channels, advertise these to userspace via nl80211. Also add a new feature flag to let userspace know this is supported. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15cfg80211: allow drivers to selectively disable 80/160 MHzJohannes Berg3-1/+32
Some drivers might support 80 or 160 MHz only on some channels for whatever reason, so allow them to disable these channel widths. Also maintain the new flags when regulatory bandwidth limitations would disable these wide channels. Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: properly track HT/VHT operation changesJohannes Berg1-68/+168
A while ago, I made the mac80211 station code never change the channel type after association. This solved a number of issues but is ultimately wrong, we should react if the AP changes the HT operation IE and switches bandwidth. One of the issues is that we associate as HT40 capable, but if the AP ever switches to 40 MHz we won't be able to receive such frames because we never set our channel to 40 MHz. This addresses this and VHT operation changes. If there's a change that is incompatible with our setup, e.g. if the AP decides to change the channel entirely (and for some reason we still hear the beacon) we'll just disconnect. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: move ieee80211_determine_chantype functionJohannes Berg1-195/+195
The next patch will need it further up in the file, so move it unchanged now. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: add ieee80211_vif_change_bandwidthJohannes Berg3-0/+57
For HT and VHT the current bandwidth can change, add the function ieee80211_vif_change_bandwidth() to take care of this. It returns a failure if the new bandwidth isn't compatible with the existing channel context, the caller has to handle that. When it happens, also inform the driver that the bandwidth changed for this virtual interface (no drivers would actually care today though.) Changing to/from HT/VHT isn't allowed though. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: clean up channel use in ieee80211_config_ht_txJohannes Berg1-11/+3
The channel use is confusing, some uses the channel context and some the bss_conf.chandef. The latter is fine, so get rid of the channel context part. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2013-02-15mac80211: disable HT/VHT if AP has no HT/VHT capabilityJohannes Berg1-2/+14
Having HT/VHT operation IEs but not capability IEs leads to a strange situation where we configure the channel to an HT or VHT bandwidth and then can't actually use it. Prevent this by checking that the HT and VHT capability IEs are present as well as the operation IEs; if not, disable HT and/or VHT. Signed-off-by: Johannes Berg <johannes.berg@intel.com>