- 16 Feb, 2022 13 commits
-
-
Jia Ding authored
Add 320 MHz support in the channel def and center frequency validation with compatible check. Signed-off-by:
Jia Ding <quic_jiad@quicinc.com> Co-authored-by:
Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Signed-off-by:
Muna Sinada <quic_msinada@quicinc.com> Signed-off-by:
Veerendranath Jakkam <quic_vjakkam@quicinc.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Ilan Peer authored
And advertise EHT capabilities to user space when supported. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Link: https://lore.kernel.org/r/20220214173004.6fb70658529f.I2413a37c8f7d2d6d638038a3d95360a3fce0114d@changeidSigned-off-by:
-
Mordechay Goodstein authored
We add the fields for parsing extended ADDBA request/respond, and new max 1K aggregation for limit ADDBA request/respond. Adjust drivers to use the proper macro, IEEE80211_MAX_AMPDU_BUF -> IEEE80211_MAX_AMPDU_BUF_HE. Signed-off-by:
Mordechay Goodstein <mordechay.goodstein@intel.com> Link: https://lore.kernel.org/r/20220214173004.b8b447ce95b7.I0ee2554c94e89abc7a752b0f7cc7fd79c273efea@changeidSigned-off-by:
-
Ilan Peer authored
Based on Draft P802.11be_D1.4. Signed-off-by:
-
Ilan Peer authored
Add a custom regulatory domain for testing 6 GHz, including 320 MHz bandwidth. This can be used before the regulatory databases are all updated etc. Signed-off-by:
-
Johannes Berg authored
The argument to hwsim_init_s1g_channels() shadows a global, change that to be clearer. Link: https://lore.kernel.org/r/20220214173004.66bac90d64a8.I3e878e42bf2feecbb0a6ca38a68c236c23a8c9e6@changeidSigned-off-by:
-
Johannes Berg authored
Add checks to hwsim to validate that neither TX nor any station's configured bandwidth can exceed the channel (context) configuration previously requested. Link: https://lore.kernel.org/r/20220214173004.9fd154d2c3c2.Ia0cd152357a373149bab017d479ab7d5ded289c0@changeidSigned-off-by:
-
Johannes Berg authored
The kernel (driver code) should be able to assume that a station's HE capabilities are not badly sized, so reject them if they are. Link: https://lore.kernel.org/r/20220214172921.80b710d45cb7.Id57ce32f9538a40e36c620fabedbd2c73346ef56@changeidSigned-off-by:
-
Johannes Berg authored
The code validates the HE capability element size later, but slightly wrong, so use the new helper to do it right and only accept it if it has a good size. Link: https://lore.kernel.org/r/20220214172920.b5b06f264a61.I645ac1e2dc0ace223ef3e551cd5a71c88bd55e04@changeidSigned-off-by:
-
Johannes Berg authored
This element has a very dynamic structure, create a small helper function to validate its size. We're currently checking it in mac80211 in a conversion function, but that's actually slightly buggy. Link: https://lore.kernel.org/r/20220214172920.750bee9eaf37.Ie18359bd38143b7dc949078f10752413e6d36854@changeidSigned-off-by:
-
Johannes Berg authored
Use RCU here to read the regdomain, this will allow us to remove the RTNL locking from the setter. Note in nl80211_get_reg_do() we still need the RTNL to do the wiphy lookup. Link: https://lore.kernel.org/r/20220214101820.5d4acbcf2a46.Ibfc91980439862125e983d9adeebaba73fe38e2d@changeidSigned-off-by:
-
Beni Lev authored
Set the base RSSI of a TX frame. The final RSSI of the frame will be the base RSSI + the radio's TX power Signed-off-by:
Beni Lev <beni.lev@intel.com> Link: https://lore.kernel.org/r/20220210201649.dddebbb55a7f.I6c0607694587b577070339078829fcc20dfcfe2c@changeidSigned-off-by:
-
Johannes Berg authored
Somehow spaces were used here, use tab instead. Link: https://lore.kernel.org/r/20220210201242.da8fa2e5ae8d.Ia452db01876e52e815f6337fef437049df0d8bd9@changeidSigned-off-by:
-
- 14 Feb, 2022 7 commits
-
-
Ping-Ke Shih authored
Apply 160M bandwidth to RA (rate adaptive) mechanism, so it can transmit packets with this bandwidth. On the other hand, convert 160M bandwidth from RX desc to rx_info_bw. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220211075953.40421-7-pkshih@realtek.com
-
Ping-Ke Shih authored
The new chip can support 160M, so add a chip attribute to indicate the chip support it. Signed-off-by:
-
Ping-Ke Shih authored
Construct rate mask of 6G band, and rate adaptive mechanism can work well on this band. Signed-off-by:
-
Zong-Zhe Yang authored
Split 6G band into 8 sub-bands where indexes are from 0 to 7, i.e. RTW89_CH_6G_BAND_IDX[0-7]. Then, decide subband by both band and channel instead of just channel because conflicts between 5G channels and 6G channels. Moreover, add default case to the existing use of switch (subband). Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
Since these macro in rfk helpers are common now, a common naming should be better. So, apply RTW89_ as prefix to them, and modify the use correspondly. No logic is changed at all. Signed-off-by:
-
Zong-Zhe Yang authored
These rfk helpers are also useful for the chip which is under planning. So, move them to common code to avoid duplicate stuff in the future. Signed-off-by:
-
Zhao, Jiaqing authored
BCM43454/6 is a variant of BCM4345 which is exactly identical to BCM4345/6, except the chip id is 0xa9be. This patch adds support for BCM43454/6 by handing it in the same way as BCM4345. Note: when loading some specific version of BCM4345 firmware, the chip id may become 0x4345. This is an expected behavior, and it will restore to 0xa9be after power cycle. Signed-off-by:
Jiaqing Zhao <jiaqing.zhao@intel.com> Signed-off-by:
-
- 11 Feb, 2022 20 commits
-
-
David S. Miller authored
Merge tag 'wireless-next-2022-02-11' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next wireless-next patches for v5.18 First set of patches for v5.18, with both wireless and stack patches. rtw89 now has AP mode support and wcn36xx has survey support. But otherwise pretty normal. Major changes: ath11k * add LDPC FEC type in 802.11 radiotap header * enable RX PPDU stats in monitor co-exist mode wcn36xx * implement survey reporting brcmfmac * add CYW43570 PCIE device rtw88 * rtw8821c: enable RFE 6 devices rtw89 * AP mode support mt76 * mt7916 support * background radar detection support
-
David S. Miller authored
Eric Dumazet says: ==================== ipv6: remove addrconf reliance on loopback Second patch in this series removes IPv6 requirement about the netns loopback device being the last device being dismantled. This was needed because rt6_uncached_list_flush_dev() and ip6_dst_ifdown() had to switch dst dev to a known device (loopback). Instead of loopback, we can use the (hidden) blackhole_netdev which is also always there. This will allow future simplfications of netdev_run_to() and other parts of the stack like default_device_exit_batch(). Last two patches are optimizations for both IP families. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
This is an optimization to keep the per-cpu lists as short as possible: Whenever rt_flush_dev() changes one rtable dst.dev matching the disappearing device, it can can transfer the object to a quarantine list, waiting for a final rt_del_uncached_list(). Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
This is an optimization to keep the per-cpu lists as short as possible: Whenever rt6_uncached_list_flush_dev() changes one rt6_info matching the disappearing device, it can can transfer the object to a quarantine list, waiting for a final rt6_uncached_list_del(). Signed-off-by:
-
Eric Dumazet authored
IPv6 addrconf notifiers wants the loopback device to be the last device being dismantled at netns deletion. This caused many limitations and work arounds. Back in linux-5.3, Mahesh added a per host blackhole_netdev that can be used whenever we need to make sure objects no longer refer to a disappearing device. If we attach to blackhole_netdev an ip6_ptr (allocate an idev), then we can use this special device (which is never freed) in place of the loopback_dev (which can be freed). This will permit improvements in netdev_run_todo() and other parts of the stack where had steps to make sure loopback_dev was the last device to disappear. Signed-off-by:
-
Eric Dumazet authored
This counter has never been visible, there is little point trying to maintain it. Signed-off-by:
-
Holger Brunck authored
The mv88e6352, mv88e6240 and mv88e6176 have a serdes interface. This patch allows to configure the output swing to a desired value in the phy-handle of the port. The value which is peak to peak has to be specified in microvolts. As the chips only supports eight dedicated values we return EINVAL if the value in the DTS does not match one of these values. Signed-off-by:
Holger Brunck <holger.brunck@hitachienergy.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
-
Marek Behún authored
Common PHYs and network PCSes often have the possibility to specify peak-to-peak voltage on the differential pair - the default voltage sometimes needs to be changed for a particular board. Add properties `tx-p2p-microvolt` and `tx-p2p-microvolt-names` for this purpose. The second property is needed to specify the mode for the corresponding voltage in the `tx-p2p-microvolt` property, if the voltage is to be used only for speficic mode. More voltage-mode pairs can be specified. Example usage with only one voltage (it will be used for all supported PHY modes, the `tx-p2p-microvolt-names` property is not needed in this case): tx-p2p-microvolt = <915000>; Example usage with voltages for multiple modes: tx-p2p-microvolt = <915000>, <1100000>, <1200000>; tx-p2p-microvolt-names = "2500base-x", "usb", "pcie"; Add these properties into a separate file phy/transmit-amplitude.yaml, which should be referenced by any binding that uses it. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Guillaume Nault authored
The ->rtm_tos option is normally used to route packets based on both the destination address and the DS field. However it's ignored for IPv6 routes. Setting ->rtm_tos for IPv6 is thus invalid as the route is going to work only on the destination address anyway, so it won't behave as specified. Suggested-by:
Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by:
Guillaume Nault <gnault@redhat.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== More aggressive DSA cleanup This series deletes some code which is apparently not needed. I've had these patches in my tree for a while, and testing on my boards didn't reveal any issues. Compared to the RFC v1 series, the only change is the addition of patch 3. https://patchwork.kernel.org/project/netdevbpf/cover/20220107184842.550334-1-vladimir.oltean@nxp.com/ ==================== Signed-off-by:
-
Vladimir Oltean authored
Since commit 2f1e8ea7 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), suggested by Cong Wang, the DSA interfaces and their master have different dev->nested_level, which makes netif_addr_lock() stop complaining about potentially recursive locking on the same lock class. So we no longer need DSA slave interfaces to have their own lockdep class. Cc: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
Since commit 2f1e8ea7 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), suggested by Cong Wang, the DSA interfaces and their master have different dev->nested_level, which makes netif_addr_lock() stop complaining about potentially recursive locking on the same lock class. So we no longer need DSA masters to have their own lockdep class. Cc: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
There are no legacy ports, DSA registers a devlink instance with ports unconditionally for all switch drivers. Therefore, delete the old-style ndo operations used for determining bridge forwarding domains. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
David S. Miller authored
D. Wythe says: ==================== net/smc: Optimizing performance in short-lived scenarios This patch set aims to optimizing performance of SMC in short-lived links scenarios, which is quite unsatisfactory right now. In our benchmark, we test it with follow scripts: ./wrk -c 10000 -t 4 -H 'Connection: Close' -d 20 http://smc-server Current performance figures like that: Running 20s test @ http://11.213.45.6 4 threads and 10000 connections 4956 requests in 20.06s, 3.24MB read Socket errors: connect 0, read 0, write 672, timeout 0 Requests/sec: 247.07 Transfer/sec: 165.28KB There are many reasons for this phenomenon, this patch set doesn't solve it all though, but it can be well alleviated with it in. Patch 1/5 (Make smc_tcp_listen_work() independent) : Separate smc_tcp_listen_work() from smc_listen_work(), make them independent of each other, the busy SMC handshake can not affect new TCP connections visit any more. Avoid discarding a large number of TCP connections after being overstock, which is undoubtedly raise the connection establishment time. Patch 2/5 (Limit SMC backlog connections): Since patch 1 has separated smc_tcp_listen_work() from smc_listen_work(), an unrestricted TCP accept have come into being. This patch try to put a limit on SMC backlog connections refers to implementation of TCP. Patch 3/5 (Limit SMC visits when handshake workqueue congested): Considering the complexity of SMC handshake right now, in short-lived links scenarios, this may not be the main scenario of SMC though, it's performance is still quite poor. This patch try to provide constraint on SMC handshake when handshake workqueue congested, which is the sign of SMC handshake stacking in our opinion. Patch 4/5 (Dynamic control handshake limitation by socket options) This patch allow applications dynamically control the ability of SMC handshake limitation. Since SMC don't support set SMC socket option before, this patch also have to support SMC's owns socket options. Patch 5/5 (Add global configure for handshake limitation by netlink) This patch provides a way to get benefit of handshake limitation without modifying any code for applications, which is quite useful for most existing applications. After this patch set, performance figures like that: Running 20s test @ http://11.213.45.6 4 threads and 10000 connections 693253 requests in 20.10s, 452.88MB read Requests/sec: 34488.13 Transfer/sec: 22.53MB That's a quite well performance improvement, about to 6 to 7 times in my environment. --- changelog: v1 -> v2: - fix compile warning - fix invalid dependencies in kconfig v2 -> v3: - correct spelling mistakes - fix useless variable declare v3 -> v4 - make smc_tcp_ls_wq be static v4 -> v5 - add dynamic control for SMC auto fallback by socket options - add global configure for SMC auto fallback through netlink v5 -> v6 - move auto fallback to net namespace scope - remove auto fallback attribute in SMC_GEN_SYS_INFO - add independent attributes for auto fallback v6 -> v7 - fix wording and the naming issues, rename 'auto fallback' to handshake limitation. ==================== Signed-off-by:
-
D. Wythe authored
Although we can control SMC handshake limitation through socket options, which means that applications who need it must modify their code. It's quite troublesome for many existing applications. This patch modifies the global default value of SMC handshake limitation through netlink, providing a way to put constraint on handshake without modifies any code for applications. Suggested-by:
Tony Lu <tonylu@linux.alibaba.com> Signed-off-by:
D. Wythe <alibuda@linux.alibaba.com> Reviewed-by:
-
D. Wythe authored
This patch aims to add dynamic control for SMC handshake limitation for every smc sockets, in production environment, it is possible for the same applications to handle different service types, and may have different opinion on SMC handshake limitation. This patch try socket options to complete it, since we don't have socket option level for SMC yet, which requires us to implement it at the same time. This patch does the following: - add new socket option level: SOL_SMC. - add new SMC socket option: SMC_LIMIT_HS. - provide getter/setter for SMC socket options. Link: https://lore.kernel.org/all/20f504f961e1a803f85d64229ad84260434203bd.1644323503.git.alibuda@linux.alibaba.com/Signed-off-by:
-
D. Wythe authored
This patch intends to provide a mechanism to put constraint on SMC connections visit according to the pressure of SMC handshake process. At present, frequent visits will cause the incoming connections to be backlogged in SMC handshake queue, raise the connections established time. Which is quite unacceptable for those applications who base on short lived connections. There are two ways to implement this mechanism: 1. Put limitation after TCP established. 2. Put limitation before TCP established. In the first way, we need to wait and receive CLC messages that the client will potentially send, and then actively reply with a decline message, in a sense, which is also a sort of SMC handshake, affect the connections established time on its way. In the second way, the only problem is that we need to inject SMC logic into TCP when it is about to reply the incoming SYN, since we already do that, it's seems not a problem anymore. And advantage is obvious, few additional processes are required to complete the constraint. This patch use the second way. After this patch, connections who beyond constraint will not informed any SMC indication, and SMC will not be involved in any of its subsequent processes. Link: https://lore.kernel.org/all/1641301961-59331-1-git-send-email-alibuda@linux.alibaba.com/Signed-off-by:
-
D. Wythe authored
Current implementation does not handling backlog semantics, one potential risk is that server will be flooded by infinite amount connections, even if client was SMC-incapable. This patch works to put a limit on backlog connections, referring to the TCP implementation, we divides SMC connections into two categories: 1. Half SMC connection, which includes all TCP established while SMC not connections. 2. Full SMC connection, which includes all SMC established connections. For half SMC connection, since all half SMC connections starts with TCP established, we can achieve our goal by put a limit before TCP established. Refer to the implementation of TCP, this limits will based on not only the half SMC connections but also the full connections, which is also a constraint on full SMC connections. For full SMC connections, although we know exactly where it starts, it's quite hard to put a limit before it. The easiest way is to block wait before receive SMC confirm CLC message, while it's under protection by smc_server_lgr_pending, a global lock, which leads this limit to the entire host instead of a single listen socket. Another way is to drop the full connections, but considering the cast of SMC connections, we prefer to keep full SMC connections. Even so, the limits of full SMC connections still exists, see commits about half SMC connection below. After this patch, the limits of backend connection shows like: For SMC: 1. Client with SMC-capability can makes 2 * backlog full SMC connections or 1 * backlog half SMC connections and 1 * backlog full SMC connections at most. 2. Client without SMC-capability can only makes 1 * backlog half TCP connections and 1 * backlog full TCP connections. Signed-off-by:
-
D. Wythe authored
In multithread and 10K connections benchmark, the backend TCP connection established very slowly, and lots of TCP connections stay in SYN_SENT state. Client: smc_run wrk -c 10000 -t 4 http://server the netstate of server host shows like: 145042 times the listen queue of a socket overflowed 145042 SYNs to LISTEN sockets dropped One reason of this issue is that, since the smc_tcp_listen_work() shared the same workqueue (smc_hs_wq) with smc_listen_work(), while the smc_listen_work() do blocking wait for smc connection established. Once the workqueue became congested, it's will block the accept() from TCP listen. This patch creates a independent workqueue(smc_tcp_ls_wq) for smc_tcp_listen_work(), separate it from smc_listen_work(), which is quite acceptable considering that smc_tcp_listen_work() runs very fast. Signed-off-by:
-
Luiz Angelo Daros de Luca authored
Schema changes: - support for mdio-connected switches (mdio driver), recognized by checking the presence of property "reg" - new compatible strings for rtl8367s and rtl8367rb - "interrupt-controller" was not added as a required property. It might still work polling the ports when missing. Examples changes: - renamed "switch_intc" to make it unique between examples - removed "dsa-mdio" from mdio compatible property - renamed phy@0 to ethernet-phy@0 (not tested with real HW) phy@ requires #phy-cells Signed-off-by:
Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
