summaryrefslogtreecommitdiffstats
path: root/net/mac80211/offchannel.c
Commit message (Collapse)AuthorAgeFilesLines
* mac80211: fix CMD_FRAME for AP_VLANMichael Braun2016-10-121-1/+1
| | | | | | | | | | | | | | | | | | When using IEEE 802.11r FT OVER-DS roaming with AP_VLAN, hostapd needs to send out a frame using CMD_FRAME for a station assigned to an AP_VLAN interface. Right now, the userspace needs to give the exact AP_VLAN interface index for CMD_FRAME; hostapd does not do this. Additionally, userspace cannot use GET_STATION to query the AP_VLAN ifidx, as while GET_STATION finds stations assigned to AP_VLAN even if the AP iface is queried, it does not return AP_VLAN ifidx (it returns the queried one). This breaks IEEE 802.11r over_ds with vlans, as the reply frame does not get out. This patch fixes this by using get_sta_bss for CMD_FRAME. Signed-off-by: Michael Braun <michael-dev@fami-braun.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add boilerplate code for start / stop NANAyala Beker2016-09-301-1/+2
| | | | | | | | | | | This code doesn't do much besides allowing to start and stop the vif. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: add start / stop NAN commandsAyala Beker2016-09-301-0/+1
| | | | | | | | | | | | | | | | | This allows user space to start/stop NAN interface. A NAN interface is like P2P device in a few aspects: it doesn't have a netdev associated to it. Add the new interface type and prevent operations that can't be executed on NAN interface like scan. Define several attributes that may be configured by user space when starting NAN functionality (master preference and dual band operation) Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: avoid ROC during hw restartEliad Peller2016-01-141-0/+4
| | | | | | | | | | Defer ROC requests during hw restart, as the driver might not be fully configured in this stage (e.g. channel contexts were not added yet) Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix remain-on-channel cancellationJohannes Berg2016-01-141-2/+4
| | | | | | | | | | | | | Ilan's previous commit 1b894521e60c ("mac80211: handle HW ROC expired properly") neglected to take into account that hw_begun was now always set in the software implementation as well as the offloaded case. Fix hw_begun to only apply to the offloaded case to make the check in Ilan's commit safe and correct. Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: recalculate SW ROC only when neededJohannes Berg2016-01-141-5/+1
| | | | | | | | | | | | | | | | | | | | The current (new) code recalculates the new work timeout for software remain-on-channel whenever any item started. In two of the callers of ieee80211_handle_roc_started(), this is completely pointless since they're for hardware and will skip the recalculation entirely; it's necessary only in the case of having just added a new item to the list, as in the last remaining case the recalculation had just been done. This last case, however, is also problematic - if one of the items on the list actually expires during the recalc the list iteration outside becomes corrupted and crashes. Fix this by moving the recalculation to the only place where it's required. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: handle HW ROC expired properlyIlan Peer2015-12-071-1/+5
| | | | | | | | | | | | | | In case of HW ROC, when the driver reports that the ROC expired, it is not sufficient to purge the ROCs based on the remaining time, as it possible that the device finished the ROC session before the actual requested duration. To handle such cases, in case of ROC expired notification from the driver, complete all the ROCs which are marked with hw_begun, regardless of the remaining duration. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: reject zero cookie in mgmt-tx/roc cancelJohannes Berg2015-12-041-0/+3
| | | | | | | | | | | | | | | When cancelling, you can cancel "any" (first in list) mgmt-tx or remain-on-channel operation by using the value 0 for the cookie along with the *opposite* operation, i.e. * cancel the first mgmt-tx by cancelling roc with 0 cookie * cancel the first roc by cancelling mgmt-tx with 0 cookie This isn't really that bad since userspace should only pass cookies that we gave it, but could lead to hard-to-debug issues so better prevent it and reject zero values since we never hand those out. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: rewrite remain-on-channel logicJohannes Berg2015-12-041-286/+313
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jouni found a bug in the remain-on-channel logic: when a short item is queued, a long item is combined with it extending the original one, and then the long item is deleted, the timeout doesn't go back to the short one, and the short item ends up taking a long time. In this case, this showed as blocking scan when running two test cases back to back - the scan from the second was delayed even though all the remain-on-channel items should long have been gone. Fixing this with the current data structures turns out to be a bit complicated, we just remove the long item from the dependents list right now and don't recalculate the timeouts. There's a somewhat similar bug where we delete the short item and all the dependents go with it; to fix this we'd have to move them from the dependents to the real list. Instead of trying to do that, rewrite the code to not have all this complexity in the data structures: use a single list and allow more than one entry in it being marked as started. This makes the code a bit more complex, the worker needs to understand that it might need to just remove one of the started items, while keeping the device off-channel, but that's not more complicated than the nested data structures. This then fixes both issues described, and makes it easier to also limit the overall off-channel time when combining. TODO: as before, with hardware remain-on-channel, deleting an item after combining results in cancelling them all - we can keep track of the time elapsed and only cancel after that to fix this. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: simplify ack_skb handlingJohannes Berg2015-12-041-5/+3
| | | | | | | | | | Since the cookie is assigned inside ieee80211_make_ack_skb() now, we no longer need to return the ack_skb as the cookie and can simplify the function's return and the callers. Also rename it to ieee80211_attach_ack_skb() to more accurately reflect its purpose. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: move off-channel/mgmt-tx code to offchannel.cJohannes Berg2015-12-041-3/+471
| | | | | | | This is quite a bit of code that logically depends here since it has to deal with all the remain-on-channel logic. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix mgmt-tx abort cookie and leakJohannes Berg2015-12-041-3/+2
| | | | | | | | | | If a mgmt-tx operation is aborted before it runs, the wrong cookie is reported back to userspace, and the ack_skb gets leaked since the frame is freed directly instead of freeing it using ieee80211_free_txskb(). Fix that. Fixes: 3b79af973cf4 ("mac80211: stop using pointers as userspace cookies") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: use bool argument to ieee80211_send_nullfuncJohannes Berg2015-09-291-3/+3
| | | | | | | Instead of int with 0/1, use bool with false/true for the powersave argument to ieee80211_send_nullfunc(). Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: convert HW flags to unsigned long bitmapJohannes Berg2015-06-101-1/+1
| | | | | | | | | | | | | | | As we're running out of hardware capability flags pretty quickly, convert them to use the regular test_bit() style unsigned long bitmaps. This introduces a number of helper functions/macros to set and to test the bits, along with new debugfs code. The occurrences of an explicit __clear_bit() are intentional, the drivers were never supposed to change their supported bits on the fly. We should investigate changing this to be a per-frame flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: let flush() drop packets when possibleEmmanuel Grumbach2015-01-141-2/+2
| | | | | | | | | | | | | | | | When roaming / suspending, it makes no sense to wait until the transmit queues of the device are empty. In extreme condition they can be starved (VO saturating the air), but even in regular cases, it is pointless to delay the roaming because the low level driver is trying to send packets to an AP which is far away. We'd rather drop these packets and let TCP retransmit if needed. This will allow to speed up the roaming. For suspend, the explanation is even more trivial. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: introduce refcount for queue_stop_reasonsLuciano Coelho2014-06-231-2/+4
| | | | | | | | | | | | | Sometimes different vifs may be stopping the queues for the same reason (e.g. when several interfaces are performing a channel switch). Instead of using a bitmask for the reasons, use an integer that holds a refcount instead. In order to keep it backwards compatible, introduce a boolean in some functions that tell us whether the queue stopping should be refcounted or not. For now, use not refcounted for all calls to keep it functionally the same as before. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix on-channel remain-on-channelJohannes Berg2014-05-141-7/+20
| | | | | | | | | | | | | | | | | | | | | | | Jouni reported that if a remain-on-channel was active on the same channel as the current operating channel, then the ROC would start, but any frames transmitted using mgmt-tx on the same channel would get delayed until after the ROC. The reason for this is that the ROC starts, but doesn't have any handling for "remain on the same channel", so it stops the interface queues. The later mgmt-tx then puts the frame on the interface queues (since it's on the current operating channel) and thus they get delayed until after the ROC. To fix this, add some logic to handle remaining on the same channel specially and not stop the queues etc. in this case. This not only fixes the bug but also improves behaviour in this case as data frames etc. can continue to flow. Cc: stable@vger.kernel.org Reported-by: Jouni Malinen <j@w1.fi> Tested-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix software remain-on-channel implementationJohannes Berg2014-04-091-0/+1
| | | | | | | | | | | | | | | | | | | Jouni reported that when doing off-channel transmissions mixed with on-channel transmissions, the on-channel ones ended up on the off-channel in some cases. The reason for that is that during the refactoring of the off- channel code, I lost the part that stopped all activity and as a consequence the on-channel frames (including data frames) were no longer queued but would be transmitted on the temporary channel. Fix this by simply restoring the lost activity stop call. Cc: stable@vger.kernel.org Fixes: 2eb278e083549 ("mac80211: unify SW/offload remain-on-channel") Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Run deferred scan if last roc_list item is not startedJouni Malinen2013-09-301-0/+2
| | | | | | | | | | | | | | | | | mac80211 scan processing could get stuck if roc work for pending, but not started when a scan request was deferred due to such roc item. Normally the deferred scan would be started from ieee80211_start_next_roc(), but ieee80211_sw_roc_work() calls that only if the finished ROC was started. Fix this by calling ieee80211_run_deferred_scan() in the case the last ROC was not actually started. This issue was hit relatively easily in P2P find operations where Listen state (remain-on-channel) and Search state (scan) are repeated in a loop. Signed-off-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge branch 'for-john' of ↵John W. Linville2013-04-101-3/+3
|\ | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Conflicts: drivers/net/wireless/ath/carl9170/debug.c drivers/net/wireless/ath/carl9170/main.c net/mac80211/ieee80211_i.h
| * mac80211: purge remain-on-channel items when suspendingJohannes Berg2013-04-081-3/+3
| | | | | | | | | | | | | | | | | | | | They can't really be executed while suspended and could trigger work warnings, so abort all ROC items. When the system resumes the notifications about this will be delivered to userspace which can then act accordingly (though it will assume they were canceled/finished.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | Merge branch 'master' of ↵John W. Linville2013-04-101-6/+17
|\ \ | |/ |/| | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: drivers/net/wireless/rt2x00/rt2x00pci.c
| * mac80211: fix remain-on-channel cancel crashJohannes Berg2013-03-251-6/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a ROC item is canceled just as it expires, the work struct may be scheduled while it is running (and waiting for the mutex). This results in it being run after being freed, which obviously crashes. To fix this don't free it when aborting is requested but instead mark it as "to be freed", which makes the work a no-op and allows freeing it outside. Cc: stable@vger.kernel.org [3.6+] Reported-by: Jouni Malinen <j@w1.fi> Tested-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: stop queues temporarily for flushingJohannes Berg2013-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | Sometimes queues are flushed in the middle of operation, which can lead to driver issues. Stop queues temporarily, while flushing, to avoid transmitting new packets while they are being flushed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: pass queue bitmap to flush operationJohannes Berg2013-03-181-2/+2
| | | | | | | | | | | | | | | | | | | | There are a number of situations in which mac80211 only really needs to flush queues for one virtual interface, and in fact during this frames might be transmitted on other virtual interfaces. Calculate and pass a queue bitmap to the driver so it knows which queues to flush. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: Allow drivers to differentiate between ROC typesIlan Peer2013-03-061-1/+1
|/ | | | | | | | | | | Some devices can handle remain on channel requests differently based on the request type/priority. Add support to differentiate between different ROC types, i.e., indicate that the ROC is required for sending managment frames. 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>
* mac80211: Add flushes before going off-channelSeth Forshee2013-02-111-0/+5
| | | | | | | | | | | | | | | | | | We've got a couple of races when enabling powersave with an AP for off-channel operation. The first is fairly simple. If we go off-channel before the nullfunc frame to enable PS is transmitted then it may not be received by the AP. Add a flush after enabling off-channel PS to prevent this from happening. The second race is a bit more subtle. If the driver supports QoS and has frames queued when the nullfunc frame is queued, those frames may get transmitted after the nullfunc frame. If PM is not set then the AP is being told that we've exited PS before we go off-channel and may try to deliver frames. To prevent this, add a flush after stopping the queues but before passing the nullfunc frame to the driver. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Fix tx queue handling during scansSeth Forshee2013-02-111-20/+10
| | | | | | | | | | | | | | | | | | | | | | Scans currently work by stopping the netdev tx queues but leaving the mac80211 queues active. This stops the flow of incoming packets while still allowing mac80211 to transmit nullfunc and probe request frames to facilitate scanning. However, the driver may try to wake the mac80211 queues while in this state, which will also wake the netdev queues. To prevent this, add a new queue stop reason, IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL, to be used when stopping the tx queues for off-channel operation. This prevents the netdev queues from waking when a driver wakes the mac80211 queues. This also stops all frames from being transmitted, even those meant to be sent off-channel. Add a new tx control flag, IEEE80211_TX_CTL_OFFCHAN_TX_OK, which allows frames to be transmitted when the queues are stopped only for the off-channel stop reason. Update all locations transmitting off-channel frames to use this flag. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge branch 'master' of ↵John W. Linville2013-01-281-12/+7
|\ | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: drivers/net/wireless/ath/ath9k/main.c drivers/net/wireless/iwlwifi/dvm/tx.c
| * mac80211: synchronize scan off/on-channel and PS statesStanislaw Gruszka2013-01-161-12/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since: commit b23b025fe246f3acc2988eb6d400df34c27cb8ae Author: Ben Greear <greearb@candelatech.com> Date: Fri Feb 4 11:54:17 2011 -0800 mac80211: Optimize scans on current operating channel. we do not disable PS while going back to operational channel (on ieee80211_scan_state_suspend) and deffer that until scan finish. But since we are allowed to send frames, we can send a frame to AP without PM bit set, so disable PS on AP side. Then when we switch to off-channel (in ieee80211_scan_state_resume) we do not enable PS. Hence we are off-channel with PS disabled, frames are not buffered by AP. To fix remove offchannel_ps_disable argument and always enable PS when going off-channel and disable it when going on-channel, like it was before. Cc: stable@vger.kernel.org # 2.6.39+ Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Tested-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: track enable_beacon explicitlyJohannes Berg2013-01-031-6/+9
|/ | | | | | | | | | Instead of calculating in ieee80211_bss_info_change_notify() whether beaconing should be enabled or not, set it in the correct places in the callers. This simplifies the logic in this function at the expense of offchannel, but is also more robust. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge tag 'nfc-fixes-3.7-2' of ↵John W. Linville2012-12-061-2/+0
|\ | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-3.0 This is an NFC LLCP fix for 3.7 and contains only one patch. It fixes a potential crash when receiving an LLCP HDLC frame acking a frame that is not the last sent one. In that case we may dereference an already freed pointer.
| * mac80211: fix remain-on-channel (non-)cancellingJohannes Berg2012-11-261-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Felix Liao reported that when an interface is set DOWN while another interface is executing a ROC, the warning in ieee80211_start_next_roc() (about the first item on the list having started already) triggers. This is because ieee80211_roc_purge() calls it even if it never actually changed the list of ROC items. To fix this, simply remove the function call. If it is needed then it will be done by the ieee80211_sw_roc_work() function when the ROC item that is being removed while active is cleaned up. Cc: stable@vger.kernel.org Reported-by: Felix Liao <Felix.Liao@watchguard.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* | cfg80211: remove remain-on-channel channel typeJohannes Berg2012-11-261-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mwifiex (and mac80211 in the software case) are the only drivers actually implementing remain-on-channel with channel type, userspace can't be relying on it. This is the case, as it's used only for P2P operations right now. Rather than adding a flag to tell userspace whether or not it can actually rely on it, simplify all the code by removing the ability to use different channel types. Leave only the validation of the attribute, so that if we extend it again later (with the needed capability flag), it can't break userspace sending invalid data. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: make remain_on_channel() op pass vif paramEliad Peller2012-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Drivers (e.g. wl12xx) might need to know the vif to roc on (mainly in order to configure the rx filters correctly). Add the vif to the op params, and update the current users (iwlwifi) to use the new api. Signed-off-by: Eliad Peller <eliad@wizery.com> [fix hwsim] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: use a counter for remain-on-channel cookieJohannes Berg2012-10-301-4/+3
| | | | | | | | | | | | | | | | | | | | | | Instead of using the pointer which can be re-used fairly quickly due to allocator patterns and then makes debugging difficult, maintain a counter and use its value. Since it's a 64-bit value it can't really wrap, but catch that case anyway since it most likely points to a bug somewhere. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: use channel contextsJohannes Berg2012-10-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: track whether to use channel contextsJohannes Berg2012-10-161-0/+6
|/ | | | | | | | | | | | | Depending on the driver, channel contexts may be used or not. If they are used, the driver must have support for hardware scan and remain-on-channel; otherwise the driver must not advertise support for multiple channels. Also prohibit WDS type interfaces when channel contexts are to be used as there's no clear definition of which channel they use. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: use list_move instead of list_del/list_addWei Yongjun2012-09-061-2/+1
| | | | | | | | | | Using list_move() instead of list_del() + list_add(). spatch with a semantic match is used to found this problem. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: support P2P Device abstractionJohannes Berg2012-08-201-0/+6
| | | | | | | | | | After cfg80211 got a P2P Device abstraction, add support to mac80211. Whether it really is supported or not will depend on whether or not the driver has support for it, but mac80211 needs to change to be able to support drivers that need a P2P Device. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix use after freeAlan Cox2012-07-131-2/+4
| | | | | | | roc is destroyed then roc->started is referenced. Keep a local cache. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: use wdev in mgmt-tx/ROC APIsJohannes Berg2012-07-091-3/+3
| | | | | | | | | | | The management frame and remain-on-channel APIs will be needed in the P2P device abstraction, so move them over to the new wdev-based APIs. Userspace can still use both the interface index and wdev identifier for them so it's backward compatible, but for the P2P Device wdev it will be able to use the wdev identifier only. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: rename driver-trace fileJohannes Berg2012-06-241-1/+0
| | | | | | | This file will contain more soon, so rename it to just trace. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix double-start of remain-on-channelJohannes Berg2012-06-201-1/+5
| | | | | | | | | | | | | | When a remain-on-channel item is deleted, we remove it from the list and then start the next item. However, if it wasn't actually the first item then calling ieee80211_start_next_roc() is wrong as it will start the first item -- even if that was already started. Fix the two places that do this and add a warning to prevent the problem from reoccurring. Reported-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: cleanup offchannel_ps_enable argumentRajkumar Manoharan2012-06-201-5/+4
| | | | | | | | The 'tell_ap' argument is always true. So that remove it and simplify the function. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove unneeded ieee80211_run_deferred_scan()Johannes Berg2012-06-111-5/+0
| | | | | | | | | | Ilan pointed out to me that ieee80211_start_next_roc() already calls ieee80211_run_deferred_scan() if the list of ROC items is empty, so there's no need to call it again after calling ieee80211_start_next_roc(). Reported-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: unify SW/offload remain-on-channelJohannes Berg2012-06-061-42/+238
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Redesign all the off-channel code, getting rid of the generic off-channel work concept, replacing it with a simple remain-on-channel list. This fixes a number of small issues with the ROC implementation: * offloaded remain-on-channel couldn't be queued, now we can queue it as well, if needed * in iwlwifi (the only user) offloaded ROC is mutually exclusive with scanning, use the new queue to handle that case -- I expect that it will later depend on a HW flag The bigger issue though is that there's a bad bug in the current implementation: if we get a mgmt TX request while HW roc is active, and this new request has a wait time, we actually schedule a software ROC instead since we can't guarantee the existing offloaded ROC will still be that long. To fix this, the queuing mechanism was needed. The queuing mechanism for offloaded ROC isn't yet optimal, ideally we should add API to have the HW extend the ROC if needed. We could add that later but for now use a software implementation. Overall, this unifies the behaviour between the offloaded and software-implemented case as much as possible. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: do remain-on-channel while idleJohannes Berg2012-06-061-4/+0
| | | | | | | | | | | | | | | | | | The IDLE handling in HW off-channel is broken right now since we turn off IDLE only when the off-channel period already started. Therefore, all drivers that use it today (only iwlwifi!) must support off-channel while idle, so playing with idle isn't needed at all. Off-channel in general, since it's no longer used for authentication/association, shouldn't affect PS, so also remove that logic. Also document a small caveat for reporting TX status from off-channel frames in HW remain-on-channel. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: clean up remain-on-channel on interface stopJohannes Berg2012-06-041-0/+16
| | | | | | | | | | | | | | | | | | When any interface goes down, it could be the one that we were doing a remain-on-channel with. We therefore need to cancel the remain-on-channel and flush the related work structs so they don't run after the interface has been removed or even destroyed. It's also possible in this case that an off-channel SKB was never transmitted, so free it if this is the case. Note that this can also happen if the driver finishes the off-channel period without ever starting it. Cc: stable@kernel.org Reported-by: Nirav Shah <nirav.j2.shah@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* mac80211: remove dead codeMohammed Shafi Shajakhan2012-01-041-17/+0
| | | | | | | | | ieee80211_offchannel_enable_all_ps function is no longer used and looks like its logic is extensively handled in ieee80211_offchannel_stop_vifs Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-25 08:01:37 +0000