- 16 Feb, 2022 23 commits
-
-
Mordechay Goodstein authored
If the station supports EHT mode, calculate the maximum RX NSS from EHT station capabilities. Signed-off-by:
Mordechay Goodstein <mordechay.goodstein@intel.com> Link: https://lore.kernel.org/r/20220214173004.cf61972c8919.I54f5a416f0789bf4eefad04703d941b6755f6dd6@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Ilan Peer authored
When a station configuration is updated, also update the station EHT capabilities. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Link: https://lore.kernel.org/r/20220214173004.47213ffb23a8.I15c6c8430e1a0184b1322e40f1727ed4f17b04e2@changeidSigned-off-by:
-
Ilan Peer authored
When the association is an EHT association, parse the EHT element from the association response and update the station's EHT capabilities accordingly. Signed-off-by:
-
Ilan Peer authored
Add the EHT capabilities element to both probe request and association request frames, if advertised by the driver. Signed-off-by:
-
Ilan Peer authored
Add initial support for EHT and 320 MHz bandwidth in mac80211. As a new IEEE80211_STA_RX_BW_320 is added to enum ieee80211_sta_rx_bandwidth, update the drivers to avoid compilation warnings. Signed-off-by:
-
Ilan Peer authored
Parse the new EHT elements in the element parsing utilities. Signed-off-by:
-
Ilan Peer authored
Add attributes and some code bits to support userspace passing in EHT capabilities of stations. Signed-off-by:
-
Ilan Peer authored
This may be necessary in some cases, add a flag and propagate it, just like the NO-HE that already exists. Signed-off-by:
-
Sriram R authored
Add support to advertise drivers or regulatory limitations on 320 MHz channels to userspace. Signed-off-by:
Sriram R <quic_srirrama@quicinc.com> Co-authored-by:
Karthikeyan Periyasamy <quic_periyasia@quicinc.com> Signed-off-by:
Veerendranath Jakkam <quic_vjakkam@quicinc.com> Signed-off-by:
-
Veerendranath Jakkam authored
Add support for reporting and calculating EHT bitrates. Signed-off-by:
-
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:
-
Ilan Peer authored
And advertise EHT capabilities to user space when supported. Signed-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:
-
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 10 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:
-
