- 29 Jul, 2019 2 commits
-
-
Sergey Matyukevich authored
When associated BSS completes channel switch procedure, its channel record needs to be updated. The existing mac80211 solution was extended to cfg80211 in commit 5dc8cdce ("mac80211/cfg80211: update bss channel on channel switch"). However that solution still appears to be incomplete as it may lead to duplicated scan entries for associated BSS after channel switch. The root cause of the problem is as follows. Each BSS entry is included into the following data structures: - bss list rdev->bss_list - bss search tree rdev->bss_tree Updating BSS channel record without rebuilding bss_tree may break tree search since cmp_bss considers all of the following: channel, bssid, ssid. When BSS channel is updated, but its location in bss_tree is not updated, then subsequent search operations may fail to locate this BSS since they will be traversing bss_tree in wrong direction. As a result, for scan performed after associated BSS channel switch, cfg80211_bss_update may add the second entry for the same BSS to both bss_list and bss_tree, rather then update the existing one. To summarize, if BSS channel needs to be updated, then bss_tree should be rebuilt in order to put updated BSS entry into a proper location. This commit suggests the following straightforward solution: - if new entry has been already created for BSS after channel switch, then use its IEs to update known BSS entry and then remove new entry completely - use rb_erase/rb_insert_bss reinstall updated BSS in bss_tree - for nontransmit BSS entry, the whole transmit BSS hierarchy is updated Signed-off-by:
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> Link: https://lore.kernel.org/r/20190726163922.27509-3-sergey.matyukevich.os@quantenna.comSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Sergey Matyukevich authored
This patch implements minor refactoring for cfg80211_bss_update function. Code path for updating known BSS is extracted into dedicated cfg80211_update_known_bss function. Signed-off-by:
-
- 26 Jul, 2019 24 commits
-
-
Denis Kenzior authored
Include wiphy address setup in wiphy dumps and new wiphy events. The wiphy permanent address is exposed as ATTR_MAC. If addr_mask is setup, then it is included as ATTR_MAC_MASK attribute. If multiple addresses are available, then their are exposed in a nested ATTR_MAC_ADDRS array. This information is already exposed via sysfs, but it makes sense to include it in the wiphy dump as well. Signed-off-by:
Denis Kenzior <denkenz@gmail.com> Link: https://lore.kernel.org/r/20190722113312.14031-3-denkenz@gmail.com [use just nla_nest_start(), this is new functionality] Signed-off-by:
-
Denis Kenzior authored
Commit 1c38c7f2 ("nl80211: send event when CMD_FRAME duration expires") added the possibility of NL80211_CMD_FRAME_WAIT_CANCEL being sent whenever the off-channel wait time associated with a CMD_FRAME completes. Document this in the uapi/linux/nl80211.h file. Signed-off-by:
-
Sven Eckelmann authored
Implement the basics required for supporting high efficiency with mesh: include HE information elements in beacons, probe responses, and peering action frames, and check for compatible HE configurations when peering. Signed-off-by:
Sven Eckelmann <seckelmann@datto.com> Forwarded: https://patchwork.kernel.org/patch/11029299/ Link: https://lore.kernel.org/r/20190724163359.3507-2-sven@narfation.orgSigned-off-by:
-
Lorenzo Bianconi authored
Add IEEE80211_KEY_FLAG_GENERATE_MMIE flag to ieee80211_key_flags in order to allow the driver to notify mac80211 to generate MMIE and that it requires sequence number generation only. This is a preliminary patch to add BIP_CMAC_128 hw support to mt7615 driver Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/dfe275f9aa0f1cc6b33085f9efd5d8447f68ad13.1563228405.git.lorenzo@kernel.orgSigned-off-by:
-
John Crispin authored
Add support to mac80211 for parsing SPR elements as per P802.11ax_D4.0 section 9.4.2.241. Signed-off-by:
Shashidhar Lakkavalli <slakkavalli@datto.com> Signed-off-by:
John Crispin <john@phrozen.org> Link: https://lore.kernel.org/r/20190618061915.7102-2-john@phrozen.orgSigned-off-by:
-
John Crispin authored
Add support to ieee80211_add_tx_radiotap_header() for handling rates reported via ieee80211_tx_status. This allows us to also report HE rates. Signed-off-by:
-
John Crispin authored
This will allow use to report HE rates on the radiotap interface. Signed-off-by:
-
John Crispin authored
Right now struct ieee80211_tx_rate cannot hold HE rates. Lets use struct ieee80211_tx_status instead. This will also make the code future-proof for when we have EHT. Signed-off-by:
-
John Crispin authored
ADDBA_EXT IEs can be used to negotiate the BA fragmentation level. Signed-off-by:
-
Johannes Berg authored
If we just read jiffies over and over again, a non-transmitting entry may have a newer timestamp than the transmitting one, leading to possible confusion on expiry. Give them all the same timestamp when creating them. Signed-off-by:
-
Johannes Berg authored
Don't parse the multi-BSSID structures if we couldn't even create their transmitting BSS, this would confuse all of our tracking. This also means that non_tx_data->tx_bss will never be NULL, so we can clean up a little bit. Signed-off-by:
-
Johannes Berg authored
cfg80211_inform_single_bss_frame_data() doesn't need the non_tx_data data argument since it's always NULL. Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20190703070142.GA29993@kroah.comSigned-off-by:
-
Alexander Wetzel authored
Extended Key ID allows A-MPDU sessions while rekeying as long as each A-MPDU aggregates only MPDUs with one keyid together. Drivers able to segregate MPDUs accordingly can tell mac80211 to not stop A-MPDU sessions when rekeying by setting the new flag IEEE80211_HW_AMPDU_KEYBORDER_SUPPORT. Signed-off-by:
Alexander Wetzel <alexander@wetzel-home.de> Link: https://lore.kernel.org/r/20190629195015.19680-3-alexander@wetzel-home.deSigned-off-by:
-
Alexander Wetzel authored
1) Drop IEEE80211_HW_EXT_KEY_ID_NATIVE and let drivers directly set the NL80211_EXT_FEATURE_EXT_KEY_ID flag. 2) Drop IEEE80211_HW_NO_AMPDU_KEYBORDER_SUPPORT and simply assume all drivers are unable to handle A-MPDU key borders. The new Extended Key ID API now requires all mac80211 drivers to set NL80211_EXT_FEATURE_EXT_KEY_ID when they implement set_key() and can handle Extended Key ID. For drivers not providing set_key() mac80211 itself enables Extended Key ID support, using the internal SW crypto services. Signed-off-by:
-
Alexander Wetzel authored
Prepare hwsim Extended Key ID support for a mac80211 API change. The mac80211 flag IEEE80211_HW_EXT_KEY_ID_NATIVE is being replaced by NL80211_EXT_FEATURE_EXT_KEY_ID which only must be set by drivers when they support HW crypto. This reverts commit cfe7007a ("mac80211_hwsim: Extended Key ID support"). Signed-off-by:
-
Erik Stromdahl authored
Since ieee80211_tx_dequeue() must not be called with softirqs enabled (i.e. from process context without proper disable of bottom halves), we add a wrapper that disables bottom halves before calling ieee80211_tx_dequeue() The new function is named ieee80211_tx_dequeue_ni() just as all other from-process-context versions found in mac80211. The documentation of ieee80211_tx_dequeue() is also updated so it mentions that the function should not be called from process context. Signed-off-by:
Erik Stromdahl <erik.stromdahl@gmail.com> Link: https://lore.kernel.org/r/20190617200140.6189-1-erik.stromdahl@gmail.comSigned-off-by:
-
Ard Biesheuvel authored
Instead of open coding the CCM aead mode in the driver, and invoking the AES block cipher block by block, use a ccm(aes) aead transform which already encapsulates this functionality. This is a cleaner use of the crypto API, and permits optimized implementations to be used, which are typically much faster and deal more efficiently with the SIMD register file, which usually needs to be preserved/restored in order to use special AES instructions. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Link: https://lore.kernel.org/r/20190617091901.7063-1-ard.biesheuvel@linaro.orgSigned-off-by:
-
Greg Kroah-Hartman authored
The remove_sta_debugfs callback in struct rate_control_ops is no longer used by any driver, as there is no need for it (the debugfs directory is already removed recursivly by the mac80211 core.) Because no one needs it, just remove it to keep anyone else from accidentally using it in the future. Cc: Johannes Berg <johannes@sipsolutions.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by:
-
Greg Kroah-Hartman authored
The .remove_sta_debugfs callback was not doing anything in this driver, so remove it as it is not needed. Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. This driver was saving the debugfs file away to be removed at a later time. However, the 80211 core would delete the whole directory that the debugfs files are created in, after it asks the driver to do the deletion, so just rely on the 80211 core to do all of the cleanup for us, making us not need to keep a pointer to the dentries around at all. This cleans up the structure of the driver data a bit and makes the code a tiny bit smaller. Signed-off-by:
-
Emmanuel Grumbach authored
This low level driver can find it useful to get the vif when a remain on channel session is cancelled. iwlwifi will need this soon. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://lore.kernel.org/r/20190723180001.5828-1-emmanuel.grumbach@intel.comSigned-off-by:
-
Christophe JAILLET authored
This function name should be 'mac80211_hwsim_he_capab()' (s wand w switched) to be consistent with the rest of the file. Fix and use it. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20190725191328.18010-1-christophe.jaillet@wanadoo.frSigned-off-by:
-
Jisheng Zhang authored
devm_platform_ioremap_resource() wraps platform_get_resource() and devm_ioremap_resource() in a single helper, let's use that helper to simplify the code. Signed-off-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 25 Jul, 2019 8 commits
-
-
David S. Miller authored
Tuong Lien says: ==================== tipc: link changeover issues This patch series is to resolve some issues found with the current link changeover mechanism, it also includes an optimization for the link synching. ==================== Signed-off-by: -
Tuong Lien authored
In conjunction with changing the interfaces' MTU (e.g. especially in the case of a bonding) where the TIPC links are brought up and down in a short time, a couple of issues were detected with the current link changeover mechanism: 1) When one link is up but immediately forced down again, the failover procedure will be carried out in order to failover all the messages in the link's transmq queue onto the other working link. The link and node state is also set to FAILINGOVER as part of the process. The message will be transmited in form of a FAILOVER_MSG, so its size is plus of 40 bytes (= the message header size). There is no problem if the original message size is not larger than the link's MTU - 40, and indeed this is the max size of a normal payload messages. However, in the situation above, because the link has just been up, the messages in the link's transmq are almost SYNCH_MSGs which had been generated by the link synching procedure, then their size might reach the max value already! When the FAILOVER_MSG is built on the top of such a SYNCH_MSG, its size will exceed the link's MTU. As a result, the messages are dropped silently and the failover procedure will never end up, the link will not be able to exit the FAILINGOVER state, so cannot be re-established. 2) The same scenario above can happen more easily in case the MTU of the links is set differently or when changing. In that case, as long as a large message in the failure link's transmq queue was built and fragmented with its link's MTU > the other link's one, the issue will happen (there is no need of a link synching in advance). 3) The link synching procedure also faces with the same issue but since the link synching is only started upon receipt of a SYNCH_MSG, dropping the message will not result in a state deadlock, but it is not expected as design. The 1) & 3) issues are resolved by the last commit that only a dummy SYNCH_MSG (i.e. without data) is generated at the link synching, so the size of a FAILOVER_MSG if any then will never exceed the link's MTU. For the 2) issue, the only solution is trying to fragment the messages in the failure link's transmq queue according to the working link's MTU so they can be failovered then. A new function is made to accomplish this, it will still be a TUNNEL PROTOCOL/FAILOVER MSG but if the original message size is too large, it will be fragmented & reassembled at the receiving side. Acked-by:
Ying Xue <ying.xue@windriver.com> Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by:
-
Tuong Lien authored
This commit along with the next one are to resolve the issues with the link changeover mechanism. See that commit for details. Basically, for the link synching, from now on, we will send only one single ("dummy") SYNCH message to peer. The SYNCH message does not contain any data, just a header conveying the synch point to the peer. A new node capability flag ("TIPC_TUNNEL_ENHANCED") is introduced for backward compatible! Acked-by: -
Ding Xiang authored
devm_ioremap_resource already contains error message, so remove the redundant dev_err message Signed-off-by:
Ding Xiang <dingxiang@cmss.chinamobile.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Two small updates Patch #1, from Amit, exposes the size of the key-value database (KVD) where different entries (e.g., routes, neighbours) are stored in the device. This allows users to understand how many entries can be offloaded and is also useful for writing scale tests. Patch #2 increases the number of IPv6 nexthop groups mlxsw can offload. The problem and solution are explained in detail in the commit message. ==================== Signed-off-by: -
Ido Schimmel authored
Unlike IPv4, the kernel does not consolidate IPv6 nexthop groups. To avoid exhausting the device's adjacency table - where nexthops are stored - the driver does this consolidation instead. Each nexthop group is hashed by XOR-ing the interface indexes of all the member nexthop devices. However, the ifindex itself is not hashed, which can result in identical keys used for different groups and finally an -EBUSY error from rhashtable due to too long objects list. Improve the situation by hashing the ifindex itself. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Amit Cohen authored
Unlike Spectrum-1, the KVD (Key-value database) of Spectrum-2 is not partitioned, so only expose the entire KVD size. This enables users to query the total size of the KVD. Signed-off-by:
Amit Cohen <amitc@mellanox.com> Acked-by:
-
Wolfram Sang authored
Move from i2c_new_dummy() to i2c_new_dummy_device(). So, we now get an ERRPTR which we use in error handling. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
- 24 Jul, 2019 6 commits
-
-
Arnd Bergmann authored
The mlx4_dev_cap and mlx4_init_hca_param are really too large to be put on the kernel stack, as shown by this clang warning: drivers/net/ethernet/mellanox/mlx4/main.c:3304:12: error: stack frame size of 1088 bytes in function 'mlx4_load_one' [-Werror,-Wframe-larger-than=] With gcc, the problem is the same, but it does not warn because it does not inline this function, and therefore stays just below the warning limit, while clang is just above it. Use kzalloc for dynamic allocation instead of putting them on stack. This gets the combined stack frame down to 424 bytes. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Arnd Bergmann authored
clang warns about an overly large stack frame in one function when it decides to inline all __qed_get_vport_*() functions into __qed_get_vport_stats(): drivers/net/ethernet/qlogic/qed/qed_l2.c:1889:13: error: stack frame size of 1128 bytes in function '_qed_get_vport_stats' [-Werror,-Wframe-larger-than=] Use a noinline_for_stack annotation to prevent clang from inlining these, which keeps the maximum stack usage at around half of that in the worst case, similar to what we get with gcc. Fixes: 86622ee7 ("qed: Move statistics to L2 code") Signed-off-by:
-
Heiner Kallweit authored
This patch improves and simplifies rtl_set_rx_mode a little. No functional change intended. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2019-07-24 This series contains updates to igc and e1000e client drivers only. Sasha provides a couple of cleanups to remove code that is not needed and reduce structure sizes. Updated the MAC reset flow to use the device reset flow instead of a port reset flow. Added addition device id's that will be supported. Kai-Heng Feng provides a workaround for a possible stalled packet issue in our ICH devices due to a clock recovery from the PCH being too slow. v2: removed the last patch in the series that supposedly fixed a MAC/PHY de-sync potential issue while waiting for additional information from hardware engineers. ==================== Signed-off-by: -
Qian Cai authored
The linux-next commit "net: Rename skb_frag_t size to bv_len" [1] introduced a compilation error on powerpc as it forgot to deal with the renaming from "size" to "bv_len" for ixgbevf. [1] https://lore.kernel.org/netdev/20190723030831.11879-1-willy@infradead.org/T/#md052f1c7de965ccd1bdcb6f92e1990a52298eac5 In file included from ./include/linux/cache.h:5, from ./include/linux/printk.h:9, from ./include/linux/kernel.h:15, from ./include/linux/list.h:9, from ./include/linux/module.h:9, from drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:12: drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function 'ixgbevf_xmit_frame_ring': drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:4138:51: error: 'skb_frag_t' {aka 'struct bio_vec'} has no member named 'size' count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size); ^ ./include/uapi/linux/kernel.h:13:40: note: in definition of macro '__KERNEL_DIV_ROUND_UP' #define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d)) ^ drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:4138:12: note: in expansion of macro 'TXD_USE_COUNT' count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size); Signed-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
-
Masanari Iida authored
This patch fix some spelling typo in qos_mc_aware.sh Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
-
