summaryrefslogtreecommitdiffstats
path: root/include/net/mac80211.h
Commit message (Collapse)AuthorAgeFilesLines
* mac80211: stop modifying HT SMPS capabilityJohannes Berg2013-02-151-0/+2
| | | | | | | | | | 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>
* mac80211: add ieee80211_vif_change_bandwidthJohannes Berg2013-02-151-0/+4
| | | | | | | | | | | | | | | 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>
* mac80211: handle VHT operating mode notificationJohannes Berg2013-02-151-0/+3
| | | | | | | | Handle the operating mode notification action frame. When the supported streams or the bandwidth change let the driver and rate control algorithm know. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: track number of spatial streamsJohannes Berg2013-02-151-0/+5
| | | | | | | | | | With VHT, a station can change the number of spatial streams it can receive on the fly, not unlike spatial multiplexing in HT. Prepare for that by tracking the maximum number of spatial streams it can receive when the connection is established. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: stop toggling IEEE80211_HT_CAP_SUP_WIDTH_20_40Johannes Berg2013-02-151-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | For VHT, many more bandwidth changes are possible. As a first step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag in the HT capabilities and instead introduce a bandwidth field indicating the currently usable bandwidth to transmit to the station. Of course, make all drivers use it. To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get the station as an argument, rather than the new capabilities, so it can set up the new bandwidth field. If the station is a VHT station and VHT bandwidth is in use, also set the bandwidth accordingly. Doing this allows us to get rid of the supports_40mhz flag as the HT capabilities now reflect the true capability instead of the current setting. While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not ignore HT cap overrides when MCS TX isn't supported (not that it really happens...) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add radar detection command/eventSimon Wunderlich2013-02-151-0/+14
| | | | | | | | | | | | | | | | Add command to trigger radar detection in the driver/FW. Once radar detection is started it should continuously monitor for radars as long as the channel active. If radar is detected usermode notified with 'radar detected' event. Scanning and remain on channel functionality must be disabled while doing radar detection/scanning, and vice versa. Based on original patch by Victor Goldenshtein <victorg@ti.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Fix tx queue handling during scansSeth Forshee2013-02-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | 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>
* mac80211: remove IEEE80211_HW_SCAN_WHILE_IDLEJohannes Berg2013-02-111-5/+0
| | | | | | | | | | | | | | There are only a few drivers that use HW scan, and all of those don't need a non-idle transition before starting the scan -- some don't even care about idle at all. Remove the flag and code associated with it. The only driver that really actually needed this is wl1251 and it can just do it itself in the hw_scan callback -- implement that. Acked-by: Luciano Coelho <coelho@ti.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove dynamic PS driver interfaceJohannes Berg2013-02-111-39/+0
| | | | | | | | The functions were added for some sort of Bluetooth coexistence, but aren't used, so remove them again. Reviewed-by: Luciano Coelho <coelho@ti.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: introduce beacon-only timing dataJohannes Berg2013-02-111-1/+13
| | | | | | | | | | | | | | In order to be able to predict the next DTIM TBTT in the driver, add the ability to use timing data from beacons only with the new hardware flag IEEE80211_HW_TIMING_BEACON_ONLY and the BSS info value sync_dtim_count which is only valid if the timing data came from a beacon. The data can only come from a beacon, and if no beacon was received before association it is updated later together with the DTIM count notification. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add vif debugfs driver callbacksAlexander Bondar2013-02-111-0/+18
| | | | | | | | | | | | | Add debugfs driver callbacks so drivers can add debugfs entries for interfaces. Note that they _must_ remove the entries again as add/remove in the driver doesn't correspond to add/remove in debugfs; the former is up/down while the latter is netdev create/destroy. Signed-off-by: Alexander Bondar <alexander.bondar@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: always allow calling ieee80211_connection_loss()Johannes Berg2013-02-041-0/+2
| | | | | | | | | | | | | With multi-channel, there's a corner case where a driver doesn't receive a beacon soon enough to be able to sync its timers with the AP. In this case, the only recovery (after trying again) is to disconnect from the AP. Allow calling ieee80211_connection_loss() for such cases. To make that possible, modify the work function to not rely on the IEEE80211_HW_CONNECTION_MONITOR flag but use new state kept in the interface instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: start auth/assoc timeout on frame statusJohannes Berg2013-01-311-1/+4
| | | | | | | | | | | | | | | | | | | When sending authentication/association frames they might take a bit of time to go out because we may have to synchronise with the AP, in particular in the case where it's really a P2P GO. In this case the 200ms fixed timeout could potentially be too short if the beacon interval is relatively large. For drivers that report TX status we can do better. Instead of starting the timeout directly, start it only when the frame status arrives. Since then the frame was out on the air, we can wait shorter (the typical response time is supposed to be 30ms, wait 100ms.) Also, if the frame failed to be transmitted try again right away instead of waiting. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: inform the driver about update of dtim_periodEmmanuel Grumbach2013-01-311-7/+9
| | | | | | | | | | | | | | | | | | | | | | | Currently, when the driver requires the DTIM period, mac80211 will wait to hear a beacon before association. This behavior is suboptimal since some drivers may be able to deal with knowing the DTIM period after the association, if they get it at all. To address this, notify the drivers with bss_info_changed with the new BSS_CHANGED_DTIM_PERIOD flag when the DTIM becomes known. This might be when changing to associated, or later when the entire association was done with only probe response information. Rename the hardware flag for the current behaviour to IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC to more accurately reflect its behaviour. IEEE80211_HW_NEED_DTIM_PERIOD is no longer accurate as all drivers get the DTIM period now, just not before association. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211/mac80211: support reporting wakeup reasonJohannes Berg2013-01-311-0/+12
| | | | | | | | | When waking up from WoWLAN, it is useful to know what triggered the wakeup. Support reporting the wakeup reason(s) in cfg80211 (and a pass-through in mac80211) to allow userspace to know. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILStanislaw Gruszka2013-01-291-5/+0
| | | | | | | | | | | | | | | | | | | | | | This is basically a revert of: commit 5b632fe85ec82e5c43740b52e74c66df50a37db3 Author: Stanislaw Gruszka <sgruszka@redhat.com> Date: Mon Dec 3 12:56:33 2012 +0100 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL We do not need this flag any longer, rt2x00 BAR/BA problem was fixed correctly by wireless-testing commit: commit 84e9e8ebd369679a958200a8baca96aafb2393bb Author: Helmut Schaa <helmut.schaa@googlemail.com> Date: Thu Jan 17 17:34:32 2013 +0100 rt2x00: Improve TX status handling for BlockAckReq frames Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: provide the vif in rssi_callbackEmmanuel Grumbach2013-01-241-0/+1
| | | | | | | | | Since drivers can support several BSS / P2P Client interfaces, the rssi callback needs to inform the driver about the interface teh rssi event relates to. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: allow drivers to access IPv6 informationJohannes Berg2013-01-181-0/+9
| | | | | | | | | | | | | | To be able to implement NS response offloading (in regular operation or while in WoWLAN) drivers need to know the IPv6 addresses assigned to interfaces. Implement an IPv6 notifier in mac80211 to call the driver when addresses change. Unlike for IPv4, implement it as a callback rather than as a list in the BSS configuration, that is more flexible. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove ARP filter enable/disable logicJohannes Berg2013-01-181-7/+4
| | | | | | | | | | | | Depending on the driver, having ARP filtering for some addresses may be possible. Remove the logic that tracks whether ARP filter is enabled or not and give the driver the total number of addresses instead of the length of the list so it can make its own decision. Reviewed-by: Luciano Coelho <coelho@ti.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add op to configure default key idYoni Divinsky2013-01-181-0/+10
| | | | | | | | | | | | | | | There are hardwares which support offload of data packets for example when auto ARP is enabled the hw will send the ARP response. In such cases if WEP encryption is configured the hw must know the default WEP key in order to encrypt the packets correctly. When hw_accel is enabled and encryption type is set to WEP, the driver should get the default key index from mac80211. Signed-off-by: Yoni Divinsky <yoni.divinsky@ti.com> [cleanups, fixes, documentation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: call restart complete at wowlan resume timeJohannes Berg2013-01-161-1/+4
| | | | | | | | | | | | When the driver's resume function can't completely restore the configuration in the device, it returns 1 from the callback which will be treated like a HW restart request, but done directly. In this case, also call the driver's restart_complete() function so it can finish the reconfiguration there. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* {cfg,mac}80211.h: fix some kernel-doc warningsYacine Belkadi2013-01-161-14/+60
| | | | | | | | | | | | | | | | When building the 80211 DocBook, scripts/kernel-doc reports the following type of warnings: Warning(include/net/cfg80211.h:334): No description found for return value of 'cfg80211_get_chandef_type' These warnings are only reported when scripts/kernel-doc runs in verbose mode. To fix these use "Return:" to describe function return values. Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> [adjust for freq_reg_info() change] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wireless: use __alignedJohannes Berg2013-01-031-3/+3
| | | | | | | Use __aligned(...) instead of __attribute__((aligned(...))) in mac80211 and cfg80211. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: split TX aggregation stop actionJohannes Berg2013-01-031-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | When TX aggregation is stopped, there are a few different cases: - connection with the peer was dropped - session stop was requested locally - session stop was requested by the peer - connection was dropped while a session is stopping The behaviour in these cases should be different, if the connection is dropped then the driver should drop all frames, otherwise the frames may continue to be transmitted, aggregated in the case of a locally requested session stop or unaggregated in the case of the peer requesting session stop. Split these different cases so that the driver can act accordingly; however, treat local and remote stop the same way and ask the driver to not send frames as aggregated packets any more. In the case of connection drop, the stop callback the driver is otherwise supposed to call is no longer required. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix channel context iterationJohannes Berg2013-01-031-0/+5
| | | | | | | | | | | | | During suspend/resume channel contexts might be iterated even if they haven't been re-added to the driver, keep track of this and skip them in iteration. Also use the new status for sanity checks. Also clarify the fact that during HW restart all contexts are iterated over (thanks Eliad.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILStanislaw Gruszka2012-12-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit f0425beda4d404a6e751439b562100b902ba9c98 "mac80211: retry sending failed BAR frames later instead of tearing down aggr" caused regression on rt2x00 hardware (connection hangs). This regression was fixed by commit be03d4a45c09ee5100d3aaaedd087f19bc20d01 "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails". But the latter commit caused yet another problem reported in https://bugzilla.kernel.org/show_bug.cgi?id=42828#c22 After long discussion in this thread: http://mid.gmane.org/20121018075615.GA18212@redhat.com and testing various alternative solutions, which failed on one or other setup, we have no other good fix for the issues like just revert both mentioned earlier commits. To do not affect other hardware which benefit from commit f0425beda4d404a6e751439b562100b902ba9c98, instead of reverting it, introduce flag that when used will restore mac80211 behaviour before the commit. Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> [replaced link with mid.gmane.org that has message-id] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Fix typo in mac80211.hSimon Wunderlich2012-12-031-1/+1
| | | | | Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove probe response temporary buffer allocationJohannes Berg2012-11-301-3/+2
| | | | | | | Instead of allocating a temporary buffer to build IEs build them right into the SKB. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: support (partial) VHT radiotap informationJohannes Berg2012-11-271-0/+5
| | | | | | | Add some information that we have about VHT to radiotap. This at least lets one see the MCS and NSS information. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: support VHT rates in TX infoJohannes Berg2012-11-261-3/+33
| | | | | | | | To achieve this, limit the number of retries to 31 (instead of 255) and use the three bits that are then free for VHT flags. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: support drivers reporting VHT RXJohannes Berg2012-11-261-1/+11
| | | | | | | Add support to mac80211 for having drivers report received VHT MCS information. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: convert to channel definition structJohannes Berg2012-11-261-10/+7
| | | | | | | | | | | | | | Convert mac80211 (and where necessary, some drivers a little bit) to the new channel definition struct. This will allow extending mac80211 for VHT, which is currently restricted to channel contexts since there are no drivers using that which makes it easier. As I also don't care about VHT for drivers not using the channel context API, I won't convert the previous API to VHT support. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: remove remain-on-channel channel typeJohannes Berg2012-11-261-1/+0
| | | | | | | | | | | | | | | | | 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: Add debugfs callbacks for station addition/removalSujith Manoharan2012-11-211-0/+18
| | | | | | | | | | | Provide drivers with hooks to create debugfs files when a new station is added. This would help drivers to take advantage of mac80211's station list infrastructure and not maintain tedious station management code internally. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> [ifdef inline wrapper functions] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: make remain_on_channel() op pass vif paramEliad Peller2012-11-191-0/+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: support radiotap vendor namespace RX dataJohannes Berg2012-11-191-0/+12
| | | | | | | | | | | | | | | | In some cases, in particular for experimentation, it can be useful to be able to add vendor namespace data to received frames in addition to the normal radiotap data. Allow doing this through mac80211 by adding fields to the RX status descriptor that describe the data while the data itself is prepended to the frame. Also add some example code to hwsim, but don't enable it because it doesn't use a proper OUI identifier. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: support RX_FLAG_MACTIME_ENDThomas Pedersen2012-11-131-2/+6
| | | | | | | | | | | Allow drivers to indicate their mactime is at RX completion and adjust for this in mac80211. Also rename the existing RX_FLAG_MACTIME_MPDU to RX_FLAG_MACTIME_START to clarify its intent. Based on similar code by Johannes Berg. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> [fix docs, atheros drivers] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: clarify interface iteration and make it configurableJohannes Berg2012-11-091-2/+21
| | | | | | | | | | | | | | | | During hardware restart, all interfaces are iterated even though they haven't been re-added to the driver, document this behaviour. The same also happens during resume, which is even more confusing since all of the interfaces were previously removed from the driver. Make this optional so drivers relying on the current behaviour can still use it, but to let drivers that don't want this behaviour disable it. Also convert all API users, keeping the old semantics except in hwsim, where the new normal ones are desired. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: call driver method when restart completesJohannes Berg2012-11-091-0/+6
| | | | | | | | | | When the driver requests a restart (reconfiguration) it gets all the normal method calls, but can't really tell why they're happening. Call a new restart_complete op in the driver when the restart completes, so it could keep its own state about the restart and clear it there. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: pass P2P powersave parameters to driverJohannes Berg2012-11-061-0/+7
| | | | | | | | While connected to a GO, parse the P2P NoA attribute and pass the CT Window and opportunistic powersave parameters to the driver. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: handle TX power per virtual interfaceJohannes Berg2012-10-301-1/+6
| | | | | | | | | | | | | | | | | | | Even before channel contexts/multi-channel, having a single global TX power limit was already problematic, in particular if two managed interfaces connected to two APs with different power constraints. The channel context introduction completely broke this though and in fact I had disabled TX power configuration there for drivers using channel contexts. Change everything to track TX power per interface so that different user settings and different channel maxima are treated correctly. Also continue tracking the global TX power though for compatibility with applications that attempt to configure the wiphy's TX power globally. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add explicit AP/GO driver operationsJohannes Berg2012-10-261-0/+10
| | | | | | | | | | Depending on the driver, a lot of setup may be necessary to start operating as an AP, some of which may fail. Add an explicit AP start driver method to make such failures easier to handle, and add an AP stop driver method for symmetry. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: expose AES-CMAC subkey calculationAssaf Krauss2012-10-231-0/+13
| | | | | | | | | | | Expose a function for the AES-CMAC subkey calculation to drivers. This is the first step of the AES-CMAC cipher key setup and may be required for CMAC hardware offloading. Signed-off-by: Assaf Krauss <assaf.krauss@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Notify new IBSS network creationSujith Manoharan2012-10-181-0/+2
| | | | | | | | | | | | | Initialization of beacon transmission in IBSS mode depends on whether a new BSS is being created or joined. When joining an existing IBSS network, beaconing has to start only after a TSF-sync has happened - this is explained in 11.1.4. Introduce a new parameter in the BSS information structure to indicate creator/joiner mode. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: VHT peer STA capsMahesh Palivela2012-10-171-0/+3
| | | | | | | | | | | | | | Save the AP's VHT capabilities (in managed mode) and make them available to the driver in the station information. Unlike HT capabilities, they aren't restricted to the common capabilities, so drivers must be aware of their own capabilities. Signed-off-by: Mahesh Palivela <maheshp@posedge.com> [fix endian conversion bug ...] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add channel context iteratorJohannes Berg2012-10-171-0/+21
| | | | | | | | | Drivers may need to iterate the active channel contexts, export an iterator function to allow that. To make it possible, use RCU-safe list functions. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: track needed RX chains for channel contextsJohannes Berg2012-10-171-1/+14
| | | | | | | | | | | | | | | | | On each channel that the device is operating on, it may need to listen using one or more chains depending on the SMPS settings of the interfaces using it. The previous channel context changes completely removed this ability (before, it was available as the SMPS mode). Add per-context tracking of the required static and dynamic RX chains and notify the driver on changes. To achieve this, track the chains and SMPS mode used on each virtual interface and update the channel context whenever this changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: introduce new ieee80211_opsMichal Kazior2012-10-161-0/+24
| | | | | | | | | Introduce channel context driver methods. The channel on a context channel is immutable, but the channel type and other properties can change. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: introduce channel context skeleton codeMichal Kazior2012-10-161-0/+36
| | | | | | | | | | | | | | | Channel context are the foundation for multi-channel operation. They are are immutable and are re-created (or re-used if other interfaces are bound to a certain channel and a compatible channel type) on channel switching. This is an initial implementation and more features will come in separate patches. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> [some changes including RCU protection] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add key flag for management keysJohannes Berg2012-09-101-2/+10
| | | | | | | | | | | | Mark keys that might be used to receive management frames so drivers can fall back on software crypto for them if they don't support hardware offload. As the new flag is only set correctly for RX keys and the existing IEEE80211_KEY_FLAG_SW_MGMT flag can only affect TX, also rename the latter to IEEE80211_KEY_FLAG_SW_MGMT_TX. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
OpenPOWER on IntegriCloud