- 31 May, 2020 40 commits
-
-
David S. Miller authored
Merge tag 'mac80211-next-for-davem-2020-05-31' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== Another set of changes, including * many 6 GHz changes, though it's not _quite_ complete (I left out scanning for now, we're still discussing) * allow userspace SA-query processing for operating channel validation * TX status for control port TX, for AP-side operation * more per-STA/TID control options * move to kHz for channels, for future S1G operation * various other small changes ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Nathan Errera authored
With some newer AKMs, the KCK and KEK are bigger, so allow that if the driver advertises support for it. In addition, add a new attribute for the AKM so we can use it for offloaded rekeying. Signed-off-by:
Nathan Errera <nathan.errera@intel.com> [reword commit message] Link: https://lore.kernel.org/r/20200528212237.5eb58b00a5d1.I61b09d77c4f382e8d58a05dcca78096e99a6bc15@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Tova Mussai authored
Set short slot also for 6 GHz band, just like 5 GHz. Signed-off-by:
Tova Mussai <tova.mussai@intel.com> Link: https://lore.kernel.org/r/20200528213443.75f38e6f5efd.I272fbae402b03123f04e9ae69204eeab960c70cd@changeidSigned-off-by:
-
Ilan Peer authored
Treat it like the 5 GHz band. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Link: https://lore.kernel.org/r/20200528213443.889e5c9dd006.Id8ed3bb8000ba8738be5df05639415eb2e23c61a@changeidSigned-off-by:
-
Johannes Berg authored
On 6 GHz, stations don't have ht_supported set, but they can still do aggregation since they must have HE, allow that. Link: https://lore.kernel.org/r/20200528213443.776d3c891b64.Ifa099d450617b50c691832b3c4aa08959fab520a@changeidSigned-off-by:
-
Johannes Berg authored
On 6 GHz band, HE capabilities must be available for all of the interface types, otherwise we shouldn't use 6 GHz. Check this. Link: https://lore.kernel.org/r/20200528213443.5881cb3c8c4a.I583b54172f91f98d44af64a16c5826fe458cbb27@changeidSigned-off-by:
-
Johannes Berg authored
On the 6 GHz band, HE should be used, but without any direct HT/VHT capabilities, instead the HE 6 GHz band capabilities will capture the relevant information. Reject HT/VHT capabilities here. Link: https://lore.kernel.org/r/20200528213443.bfe89c35459a.Ibba5e066fa0087fd49d13cfee89d196ea0c68ae2@changeidSigned-off-by:
-
Johannes Berg authored
If a 6 GHz channel exists, then we can probably safely assume that the device actually supports it, and then it should support most bandwidths. This will probably need to be extended to check the interface type and then dig into the HE capabilities for that though, to have the correct bandwidth check. Link: https://lore.kernel.org/r/20200528213443.d4864ef52e92.I82f09b2b14a56413ce20376d09967fe954a033eb@changeidSigned-off-by:
-
Ilan Peer authored
On 6 GHz, the 6 GHz capabilities element should be added, do that. Signed-off-by:
-
Johannes Berg authored
In order to handle 6 GHz AP side, take the HE 6 GHz band capability data and pass it to the driver (which needs it for A-MPDU spacing and A-MPDU length). Link: https://lore.kernel.org/r/1589399105-25472-6-git-send-email-rmanohar@codeaurora.orgCo-developed-by:
Rajkumar Manoharan <rmanohar@codeaurora.org> Signed-off-by:
-
Shaul Triebitz authored
An AP supporting EMA (Enhanced Multi-BSSID advertisement) should set bit 83 in the extended capabilities IE (9.4.2.26 in the 802.11ax D5 spec). So the *3rd* bit of the 10th byte should be checked. Also, in one place, the wrong byte was checked. (cfg80211_find_ie returns a pointer to the beginning of the IE, so the data really starts at ie[2], so the 10th byte should be ie[12]. To avoid this confusion, use cfg80211_find_elem instead). Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Link: https://lore.kernel.org/r/20200528213443.4316121fa2a3.I9745582f8d41ad8e689dac0fefcd70b276d7c1ea@changeidSigned-off-by:
-
Johannes Berg authored
Support connecting to HE 6 GHz APs and mesh networks on 6 GHz, where the HT/VHT information is missing but instead the HE 6 GHz band capability is present, and the 6 GHz Operation information field is used to encode the channel configuration instead of the HT/VHT operation elements. Also add some other bits needed to connect to 6 GHz networks. Link: https://lore.kernel.org/r/1589399105-25472-10-git-send-email-rmanohar@codeaurora.orgCo-developed-by:
-
Johannes Berg authored
If the AP advertises inconsistent data, namely it has CCFS1 or CCFS2, but doesn't advertise support for 160/80+80 bandwidth or "Extended NSS BW Support", then we cannot use any MCSes in the the higher bandwidth. Thus, avoid connecting with higher bandwidth since it's less efficient that way. Link: https://lore.kernel.org/r/20200528213443.0e55d40c3ccc.I6fd0b4708ebd087e5e46466c3e91f6efbcbef668@changeidSigned-off-by:
-
Rajkumar Manoharan authored
As HT/VHT elements are not allowed in 6 GHz band, do not include them in mesh beacon template formation. Signed-off-by:
-
Rajkumar Manoharan authored
Add 6 GHz operation information (IEEE 802.11ax/D6.0, Figure 9-787k) while building HE operation element for non-HE AP. This field is used to determine channel information in the absence of HT/VHT IEs. Signed-off-by:
-
Rajkumar Manoharan authored
Construct HE 6 GHz band capability element (IEEE 802.11ax/D6.0, 9.4.2.261) for association request and mesh beacon. The 6 GHz capability information is passed by driver through iftypes caps. Signed-off-by:
-
Johannes Berg authored
These capabilities cover what would otherwise be transported in HT/VHT capabilities, but only a subset thereof that is actually needed on 6 GHz with HE already present. Expose the capabilities to userspace, drivers are expected to set them as using the 6 GHz band (currently) requires HE capability. Link: https://lore.kernel.org/r/20200528213443.244cd5cb9db8.Icd8c773277a88c837e7e3af1d4d1013cc3b66543@changeidSigned-off-by:
-
Rajkumar Manoharan authored
Handle 6 GHz band capability element parsing for association. Signed-off-by:
-
Rajkumar Manoharan authored
Handle 6 GHz HE capability while adding new station. It will be used later in mac80211 station processing. Signed-off-by:
-
Johannes Berg authored
Add the HE extended element IDs and the definitions for the HE 6 GHz band capabilities element, from Draft 5.0. Link: https://lore.kernel.org/r/20200528213443.1a6689fe093f.Ifdc5400fb01779351354daf38663ebeea03c9ad9@changeidSigned-off-by:
-
Johannes Berg authored
Add some code to obtain and parse the 6 GHz operation field inside the HE operation element. While at it, fix the required length using sizeof() the new struct, which is 5 instead of 4 now. Link: https://lore.kernel.org/r/20200528213443.42ca72c45ca9.Id74bc1b03da9ea6574f9bc70deeb60dfc1634359@changeidSigned-off-by:
-
Tova Mussai authored
Add the necessary definitions to parse reduced neighbor report elements. Signed-off-by:
-
Johannes Berg authored
This allows identifying whether or not a channel is a PSC (preferred scanning channel). Link: https://lore.kernel.org/r/20200528213443.414363ecf62c.Ic15e681a0e249eab7350a06ceb582cca8bb9a080@changeidSigned-off-by:
-
Johannes Berg authored
My previous commit here was wrong, it didn't check the new flag in two necessary places, so things didn't work. Fix that. Fixes: 155d7c73 ("nl80211: allow client-only BIGTK support") Link: https://lore.kernel.org/r/20200528213443.993f108e96ca.I0086ae42d672379380d04ac5effb2f3d5135731b@changeidSigned-off-by:
-
Arend Van Spriel authored
The 6GHz band does not have regulatory approval yet, but things are moving forward. However, that has led to a change in the channelization of the 6GHz band which has been accepted in the 11ax specification. It also fixes a missing MHZ_TO_KHZ() macro for 6GHz channels while at it. This change is primarily thrown in to discuss how to deal with it. I noticed ath11k adding 6G support with old channelization and ditto for iw. It probably involves changes in hostapd as well. Cc: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Cc: Jouni Malinen <jouni@w1.fi> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://lore.kernel.org/r/edf07cdd-ad15-4012-3afd-d8b961a80b69@broadcom.comSigned-off-by:
-
Johannes Berg authored
The updates to change to kHz frequencies and the 6 GHz additions evidently overlapped (or rather, I didn't see it when applying the latter), so the 6 GHz is broken. Fix this. Fixes: 934f4c7d ("cfg80211: express channels with a KHz component") Link: https://lore.kernel.org/r/20200529140425.1bf824f6911b.I4a1174916b8f5965af4366999eb9ffc7a0347470@changeidSigned-off-by:
-
Paolo Abeni authored
When token lookup on MP_JOIN 3rd ack fails, the server socket closes with a reset the incoming child. Such socket has the 'is_mptcp' flag set, but no msk socket associated - due to the failed lookup. While crafting the reset packet mptcp_established_options_mp() will try to dereference the child's master socket, causing a NULL ptr dereference. This change addresses the issue with explicit fallback to TCP in such error path. Fixes: 729cd643 ("mptcp: cope better with MP_JOIN failure") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Toke Høiland-Jørgensen authored
While the other fq-based qdiscs take advantage of skb->hash and doesn't recompute it if it is already set, sch_cake does not. This was a deliberate choice because sch_cake hashes various parts of the packet header to support its advanced flow isolation modes. However, foregoing the use of skb->hash entirely loses a few important benefits: - When skb->hash is set by hardware, a few CPU cycles can be saved by not hashing again in software. - Tunnel encapsulations will generally preserve the value of skb->hash from before the encapsulation, which allows flow-based qdiscs to distinguish between flows even though the outer packet header no longer has flow information. It turns out that we can preserve these desirable properties in many cases, while still supporting the advanced flow isolation properties of sch_cake. This patch does so by reusing the skb->hash value as the flow_hash part of the hashing procedure in cake_hash() only in the following conditions: - If the skb->hash is marked as covering the flow headers (skb->l4_hash is set) AND - NAT header rewriting is either disabled, or did not change any values used for hashing. The latter is important to match local-origin packets such as those of a tunnel endpoint. The immediate motivation for fixing this was the recent patch to WireGuard to preserve the skb->hash on encapsulation. As such, this is also what I tested against; with this patch, added latency under load for competing flows drops from ~8 ms to sub-1ms on an RRUL test over a WireGuard tunnel going through a virtual link shaped to 1Gbps using sch_cake. This matches the results we saw with a similar setup using sch_fq_codel when testing the WireGuard patch. Fixes: 046f6fd5 ("sched: Add Common Applications Kept Enhanced (cake) qdisc") Signed-off-by:
Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by:
-
Geert Uytterhoeven authored
Until recently, the Micrel KSZ9031 PHY driver ignored any PHY mode ("RGMII-*ID") settings, but used the hardware defaults, augmented by explicit configuration of individual skew values using the "*-skew-ps" DT properties. The lack of PHY mode support was compensated by the EtherAVB MAC driver, which configures TX and/or RX internal delay itself, based on the PHY mode. However, now the KSZ9031 driver has gained PHY mode support, delays may be configured twice, causing regressions. E.g. on the Renesas Salvator-X board with R-Car M3-W ES1.0, TX performance dropped from ca. 400 Mbps to 0.1-0.3 Mbps, as measured by nuttcp. As internal delay configuration supported by the KSZ9031 PHY is too limited for some use cases, the ability to configure MAC internal delay is deemed useful and necessary. Hence a proper fix would involve splitting internal delay configuration in two parts, one for the PHY, and one for the MAC. However, this would require adding new DT properties, thus breaking DTB backwards-compatibility. Hence fix the regression in a backwards-compatibility way, by letting the EtherAVB driver mask the PHY mode when it has inserted a delay, to avoid the PHY driver adding a second delay. This also fixes messages like: Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: *-skew-ps values should be used only with phy-mode = "rgmii" as the PHY no longer sees the original RGMII-*ID mode. Solving the issue by splitting configuration in two parts can be handled in future patches, and would require retaining a backwards-compatibility mode anyway. Fixes: bcf3440c ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Petr Machata says: ==================== selftests: forwarding: Two small changes Two unrelated changes in this patchset: - In patch #1, convert mirror tests from using ping directly to generating ICMP packets by mausezahn. Using ping in tests is error-prone, because ping is too smart. On a flaky system (notably in a simulator), when packets don't come quickly enough, more pings are sent, and that throws off counters. This was worked around in the past by just pinging more slowly, but using mausezahn avoids the issue as well without making the tests unnecessary slow. - A missing stats_update callback was recently added to act_pedit. Now that iproute2 supports JSON dumping for pedit, extend in patch #2 the pedit_dsfield selftest with a check that would have caught the fact that the callback was missing. ==================== Signed-off-by: -
Petr Machata authored
A missing stats_update callback was recently added to act_pedit. Now that iproute2 supports JSON dumping for pedit, extend the pedit_dsfield selftest with a check that would have caught the fact that the callback was missing. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
-
Petr Machata authored
Using ping in tests is error-prone, because ping is too smart. On a flaky system (notably in a simulator), when packets don't come quickly enough, more pings are sent, and that throws off counters. Instead use mausezahn to generate ICMP echo request packets. That allows us to send them in quicker succession as well, because the reason the ping was made slow in the first place was to make the tests work on simulated systems. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
David S. Miller authored
Roopa Prabhu says: ==================== vxlan fdb nexthop misc fixes Roopa Prabhu (2): vxlan: add check to prevent use of remote ip attributes with NDA_NH_ID vxlan: few locking fixes in nexthop event handler ==================== Signed-off-by: -
Roopa Prabhu authored
- remove fdb from nh_list before the rcu grace period - protect fdb->vdev with rcu - hold spin lock before destroying fdb Fixes: c7cdbe2e ("vxlan: support for nexthop notifiers") Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Reviewed-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Roopa Prabhu authored
NDA_NH_ID represents a remote ip or a group of remote ips. It allows use of nexthop groups in lieu of a remote ip or a list of remote ips supported by the fdb api. Current code ignores the other remote ip attrs when NDA_NH_ID is specified. In the spirit of strict checking, This commit adds a check to explicitly return an error on incorrect usage. Fixes: 1274e1cc ("vxlan: ecmp support for mac fdb entries") Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2020-05-28 This series contains updates to the ice driver only. Anirudh (Ani) adds a poll for reset completion before proceeding with driver initialization when the DDP package fails to load and the firmware issues a core reset. Jake cleans up unnecessary code, since ice_set_dflt_vsi_ctx() performs a memset to clear the info from the context structures. Fixed a potential double free during probe unrolling after a failure. Also fixed a potential NULL pointer dereference upon register_netdev() failure. Tony makes two functions static which are not called outside of their file. Brett refactors the ice_ena_vf_mappings(), which was doing the VF's MSIx and queue mapping in one function which was hard to digest. So create a new function to handle the enabling MSIx mappings and another function to handle the enabling of queue mappings. Simplify the code flow in ice_sriov_configure(). Created a helper function for clearing VPGEN_VFRTRIG register, as this needs to be done on reset to notify the VF that we are done resetting it. Fixed the initialization/creation and reset flows, which was unnecessarily complicated, so separate the two flows into their own functions. Renamed VF initialization functions to make it more clear what they do and why. Added functionality to set the VF trust mode bit on reset. Added helper functions to rebuild the VLAN and MAC configurations when resetting a VF. Refactored how the VF reset is handled to prevent VF reset timeouts. Paul cleaned up code not needed during a CORER/GLOBR reset. ==================== Signed-off-by: -
David S. Miller authored
Heiner Kallweit says: ==================== r8169: again few improvements Again a series with few r8169 improvements. ==================== Signed-off-by: -
Heiner Kallweit authored
Simplify handling the power management callbacks. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Functionality for quiescing the chip is spread across different functions currently. Move it to rtl8169_down(). Signed-off-by:
-
Heiner Kallweit authored
Move calls that are needed before and after calling rtl8169_hw_reset() into this function. This requires to move the function in the code. Signed-off-by:
-
