- 13 Aug, 2015 2 commits
-
-
Johannes Berg authored
According to firmware engineers, the firmware has never required these fields and the values have always been calculated, they were just leftovers from a previous implementation. Therefore remove the unnecessary calculation. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Geert Uytterhoeven authored
The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer functionality only, can still be compiled if GPIOLIB is not enabled. Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where appropriate. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 17 Jul, 2015 38 commits
-
-
Denys Vlasenko authored
With this .config: http://busybox.net/~vda/kernel_config, after deinlining these functions have sizes and callsite counts as follows: rate_control_rate_init: 554 bytes, 8 calls rate_control_rate_update: 1596 bytes, 5 calls Total size reduction: about 11 kbytes. Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> CC: John Linville <linville@tuxdriver.com> CC: Michal Kazior <michal.kazior@tieto.com> CC: Johannes Berg <johannes.berg@intel.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org CC: linux-kernel@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Denys Vlasenko authored
With this .config: http://busybox.net/~vda/kernel_config, after deinlining the function size is 3132 bytes and there are 7 callsites. Total size reduction: about 20 kbytes. Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> CC: John Linville <linville@tuxdriver.com> CC: Michal Kazior <michal.kazior@tieto.com> Cc: Johannes Berg <johannes.berg@intel.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org CC: linux-kernel@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Bob Copeland authored
Instead of using peer link id for AID, generate a new AID when creating mesh STAs in the kernel peering manager. This enables smaller TIM elements and more closely follows the standard, and it also enables mesh to work on drivers that require a valid AID when the STA is inserted (ath10k firmware has this requirement, for example). In the case of userspace-managed stations, we use the AID from NL80211_CMD_NEW_STATION. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Bob Copeland authored
According to 802.11-2012 13.3.1, a mesh STA should assign an AID upon receipt of a mesh peering open frame rather than using the link id of the peer. Using the peer link id has two potential issues: it may not be unique among the peers, and by its nature it is random, so the TIM may not compress well. In preparation for allocating it properly, use sta->sta.aid, but keep the existing behavior of using the plid in the aid we send. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Bob Copeland authored
Move mesh_plink_frame_tx() above the first caller to remove the forward declaration. Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Eliad Peller authored
Currently, mac80211 calls drv_resume() on wowlan resume, but drops any incoming frame until local->suspended is cleared later on. This requires the low-level driver to support a new state, in which it is expected to fully work (as it was resumed) but not passing rx frames yet (as they will be dropped). iwlwifi (and probably other drivers as well) has issues supporting such mode. Since in the wowlan case we already short-circuit ieee80211_reconfig, there's nothing that prevents us from clearing local->suspend before calling drv_resume(), and letting the low-level driver work normally. 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>
-
Arik Nemtsov authored
If a TDLS station is not allowed to beacon on a channel, don't accept a channel switch request to this channel. Move channel building code up to avoid lockdep violations - reg_can_beacon needs to take the wdev lock. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arik Nemtsov authored
Move TDLS channel-switch Rx handling into an RTNL locked work. This is required to add proper regulatory checking to incoming channel-switch requests. Queue incoming requests in a dedicated skb queue and handle the request in a device-specific work to avoid deadlocking on interface removal. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This is necessary to merge the new TDLS and mesh patches, as they depend on some fixes. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Sara Sharon authored
Add support for declaring MU-MIMO beamformee capability for relevant hardware. When sending association request, the capability is included if both hardware and the AP support it, and no other virtual interface is using it. This is in order to avoid multiple interfaces using MU-MIMO in parallel which might lead to contradictions in the group-id mechanism. Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If an SKB will be segmented by the driver, count it for multiple MSDUs that are being transmitted rather than just a single. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
John Linville authored
Commit eeca9fce ('cfg80211: Schedule timeout for all CRDA calls') left behind a superfluous check after it removed some earlier code. In reg_process_hint, the test of "treatment == REG_REQ_IGNORE || treatment == REG_REQ_ALREADY_SET" is superfluous because the code in the if-then branch is identical to the code after the if statement. Coverity CID #1295939 I also removed the unnecessary assignment of treatment in this case, and added a comment reminding any future patch authors to ensure that treatment is properly assigned before it is used after the switch. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This callback is currently not allowed to sleep, which makes it more difficult to implement proper driver methods in mac80211 than it has to be. Instead of doing asynchronous work here in mac80211, make it possible for the callback to sleep by doing some asynchronous work in cfg80211. This also enables improvements to other drivers, like ath6kl, that would like to sleep in this callback. While at it, also fix the code to call the driver on the implicit unregistration when an interface is removed, and do that also when a P2P-Device wdev is destroyed (otherwise we leak the structs.) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Most of the fields in this struct use too wide types, change that to shrink the struct from 64 to 48 bytes (on 64-bit.) This results in a total saving of 64 bytes for each interface. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This value is only used in mesh, so move it into the new mesh sub-struct of the station info. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Some drivers may need to store data per key, for example for PN validation. Allow this by adding a pointer to the struct that the driver can assign. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There's no reason not to support this, allow it to test those code paths. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Krishna Chaitanya authored
In case of Dynamic SMPS enable RTS/CTS for all rates. Signed-off-by: Chaitanya T K <chaitanya.mgit@gmail.com> [change comment] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Chun-Yeow Yeoh authored
This patch does the following: - Remove unnecessary flags field used by PERR element - Use the per target flags defined in <linux/ieee80211.h> - Process the target only subfield based on case E2 of IEEE802.11-2012 13.10.9.3 Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arik Nemtsov authored
The IEEE802.11-2012 specification is vague regarding SMPS operation during TDLS. It does not define a clear way to transition between SMPS states. To avoid interop issues, set SMPS to off when TDLS peers are connected. Accomplish this by extending the definition of the AUTOMATIC state. If the driver forces a state other than OFF, disconnect all TDLS peers. While at it, avoid changing the SMPS state of the peer STA. We have no way to control it, so try and behave correctly towards it. Move the TDLS peer-teardown function to where the rest of the TDLS code resides. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Bob Copeland authored
We already set a station to be associated when peering completes, both in user space and in the kernel. Thus we should always have an associated sta before sending data frames to that station. Failure to check assoc state can cause crashes in the lower-level driver due to transmitting unicast data frames before driver sta structures (e.g. ampdu state in ath9k) are initialized. This occurred when forwarding in the presence of fixed mesh paths: frames were transmitted to stations with whom we hadn't yet completed peering. Cc: stable@vger.kernel.org Reported-by: Alexis Green <agreen@cococorp.com> Tested-by: Jesse Jones <jjones@cococorp.com> Signed-off-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Jesse Jones authored
When processing a PREQ or PREP it's critical to use the incoming SN. If that is improperly done routing loops and other types of badness can happen. But the code was always processing path messages for deactivated paths. This path fixes that so that if we have a valid SN then we use it to verify that it is a message we can accept. For reference the relevant section of the standard is 13.10.8.4 which doesn't address the deactivated path case at all. I also included a special case for when our peer reboots or restarts networking. This is an important case because without it there can be a very long delay before we accept path messages from that peer. It's also a simple case and intimately associated with processing messages for deactivated paths so I used one patch instead of two. Signed-off-by: Alexis Green <agreen@cococorp.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Jesse Jones authored
The 2012 spec mentions that path SNs can be invalid when created (see section 13.10.8.4 table 13-9) but AFAICT never talks about invalidating SNs. Which makes sense: if we have figured out the path to a target at a certain SN then we want to remember that fact. Failing to do so can lead to routing loops because if we don't have a valid SN then we have no way of knowing whether an incoming path message leads to or away from the target. However currently when discovery fails we zero out mpath->flags which clears MESH_PATH_SN_VALID. This patch fixes that so that only the discovery relevant flags are cleared. Signed-off-by: Alexis Green <agreen@cococorp.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Alexis Green authored
When the nexthop is unable to resolve its own nexthop it will send back a PERR with a zero target_sn. According to section 13.10.11.4.3 step b in the 2012 standard that perr should be forwarded and the associated mpath->sn should be incremented. Neither one of those was happening which is rather bad because the originator was not told that packets are black holing. Signed-off-by: Alexis Green <agreen@cococorp.com> CC: Jesse Jones <jjones@cococorp.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arik Nemtsov authored
Define a station chandef, to be used for wider-bw TDLS peers. When both peers support the feature, upgrade the channel bandwidth to the maximum allowed by both peers and regulatory. Currently widths up to 80MHz are supported in the 5GHz band. When a TDLS peer connects/disconnects recalculate the channel type of the current chanctx. Make the chanctx width calculation consider wider-bw TDLS peers and similarly fix the max_required_bw calculation for the chanctx min_def. Since the sta->bandwidth is calculated only later on, take bss_conf.chandef.width as the minimal width for station interface. Set the upgraded channel width in the VHT-operation set during TDLS setup. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Arik Nemtsov authored
Allow a device to specify support for the TDLS wider-bandwidth feature. Indicate this support during TDLS setup in the ext-capab IE and set an appropriate station flag when our TDLS peer supports it. This feature gives TDLS peers the ability to use a wider channel than the base width of the BSS. For instance VHT capable TDLS peers connected on a 20MHz channel can extend the channel to 80MHz, if regulatory considerations allow it. Do not cap the bandwidth of such stations by the current BSS channel width in mac80211. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Eliad Peller authored
If reconfiguration fails, local->in_reconfig is never cleaned, resulting in rx frames being dropped next time the device is started. 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>
-
Johannes Berg authored
Simply return NULL in this case, instead of crashing. This can simplify callers that would otherwise have to check for this explicitly. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Wojciech Dubowik authored
The beacon struct is already available in many contexts that are also already in an RCU read-locked section. Avoid that by using the existing beacon struct pointer directly. Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> [rewrite subject/add commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The code was always a bit awkward due to the 80-col restriction and got worse in the previous patch. Refactor it a bit into its own function to make it read nicer. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There are now a fairly large number of mesh fields that really aren't needed in any other modes; move those into their own structure and allocate them separately. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There's a long-standing TODO item to use this flag in the cooked monitor RX, but clearly it was never needed and now this hasn't been used by userspace for a long time, so no userspace changes could require it now. Remove the unused flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Currently, the station hash table lookup (or iteration) must access two cachelines for each station - the one with the hash table node, and the one with the MAC address. Duplicate the MAC address next to the hash node to get rid of this. Since the MAC address is static there's no consistency problem introduced by this. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When there are multiple RX queues, the PN checks in mac80211 cannot be used since packets might be processed out of order on different CPUs. Allow the driver to report that the PN has been checked, drivers that will use multi-queue RX will have to set this flag. For now, the flag is only valid when the frame has been decrypted, in theory that restriction doesn't have to be there, but in practice the hardware will have decrypted the frame already. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This counter is inherently racy (since it can be incremented by RX as well as by concurrent TX) and only available in debugfs. Instead of fixing it to be per-CPU or similar, remove it for now. If needed it should be added without races and with proper nl80211, perhaps even addressing the threshold reporting TODO item that's been there since the code was originally added. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
As there's no driver using this capability and reporting zero-length A-MPDU subframes for radiotap monitoring, remove the capability to free up two RX flags. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When introducing multiple RX queues, a single NAPI struct will not be sufficient. Instead of trying to store multiple, simply change the API to have the NAPI struct passed to the RX function. This of course means that drivers using rx_irqsafe() cannot use NAPI, but that seems a reasonable trade-off, particularly since only two of all drivers are currently using it at all. While at it, we can now remove the IEEE80211_RX_REORDER_TIMER flag again since this code path cannot have a napi struct anyway. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There are no RX queues in mac80211 (yet), the comment should refer to the TID (including one slot for non-QoS) rather than 'RX queue'. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-