- 28 Jan, 2022 36 commits
-
-
Ping-Ke Shih authored
In station mode, mac_id of station is the same as rtwvif's one. In AP mode, each station uses individual mac_id. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220107034239.22002-7-pkshih@realtek.com
-
Ping-Ke Shih authored
Update beacon content if TIM bitmap maintained by mac80211 is changed. Since .set_tim must be atomic but driver uses mutex lock, we add a work. Otherwise, kernel says "sched: RT throttling activated" and lock down. Signed-off-by:
-
Ping-Ke Shih authored
This C2H notify driver the beacon count we send out. We don't handle the content for now, so add a dummy handler to avoid messages, like rtw89_pci 0000:03:00.0: c2h class 0 func 3 not support C2H: 00000000: 01 03 01 3f 0f 00 00 00 80 0a 00 00 00 00 a0 rtw89_pci 0000:03:00.0: c2h class 0 func 3 not support C2H: 00000000: 01 03 01 40 0f 00 00 00 00 03 20 00 00 00 a5 Signed-off-by:
-
Ping-Ke Shih authored
Firmware sends out beacon content generated by mac80211, and then stations can receive beacon and work with this AP properly. Also, we download beacon content again if TIM is changed. Signed-off-by:
-
Ping-Ke Shih authored
Since firmware transmits beacon by hardware SSN, driver does it with the same setting, then packets in the air have continual sequence number. Signed-off-by:
-
Ping-Ke Shih authored
With this patch, we can receive probe_req and reply probe_resp, and STA can find us. Signed-off-by:
-
Ping-Ke Shih authored
BA CAM is used to ACK peer's packets, so it must be established when IEEE80211_AMPDU_RX_START, and free it by IEEE80211_AMPDU_RX_STOP. The hardware can support two static BA CAM entries, so I implement a bitmap and a struct to record which entry is used and its corresponding tid. Also, the hardware can learn and create dynamic BA CAM entries automatically if received packets don't match static BA CAM. That means it can still work if we don't use H2C to set static BA CAM. An exception is tid=0 should be always allocated in static BA CAM, so an existing static BA CAM will be replaced if it is full and peer is going to establish a BA with tid=0. The new firmware use new format of this H2C, so I upgrade it as well. Signed-off-by:
-
Ping-Ke Shih authored
We have three points to receive packets to mac80211 with three different kinds of status. Many handlers are common and can be shared, so I move them together, and I don't change the logic at all. Signed-off-by:
-
Ping-Ke Shih authored
8852AE can receive packets with VHT MCS10/11, and we want to know we have received this kind of packets, so show the counter of VHT MCS10/11 in debugfs, like: TP TX: 1 [1] Mbps (lv: 1), RX: 420 [422] Mbps (lv: 4) Beacon: 19 Avg packet length: TX=102, RX=3081 RX count: Legacy: [0, 0, 0, 0] OFDM: [0, 0, 0, 0, 0, 0, 0, 0] HT 0: [0, 0, 0, 0, 0, 0, 0, 0] HT 1: [0, 0, 0, 0, 0, 0, 0, 0] VHT 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0][0, 0] VHT 2SS: [0, 0, 0, 0, 0, 0, 0, 4, 624, 4818][29913, 556] HE 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] HE 2ss: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] TX rate [0]: VHT 2SS MCS-9 SGI (hw_rate=0x119) ==> agg_wait=1 (3500) RX rate [0]: VHT 2SS MCS-10 SGI (hw_rate=0x11a) RSSI: -30 dBm (raw=161, prev=165) Signed-off-by: -
Ping-Ke Shih authored
RTW89_MAX_HW_PORT_NUM and RTW89_PORT_NUM refer to the same thing, so remove the one of them. Signed-off-by:
-
Zong-Zhe Yang authored
We are planning to support more chipsets, e.g. 8852C. Before that, we consider architecutre to handle multiple kinds of chipsets. Obviosuly, based on original design, rtw89_core module will have large size even if there is only one chipset under running. It is because all chipset related things are put in rtw89_core now. To reduce such overhead, we extract modules of rtw89 and adjust dependencies between modules. The following assumes that 8852AE, 8852AU, and 8852CE are all supported, we describe the difference before and after extraction. [Before extraction] ------------- |------------------------------------ | rtw89_usb | V ------------- --------------------------------------- ------------- | rtw89_core (including 8852A, 8852C) | <--- | rtw89_pci | --------------------------------------- ------------- The data of 8852A and 8852C are built in rtw89_core. And rtw89_pci is the entry of 8852AE and 8852CE. And rtw89_usb is the entry of 8852AU. [After extraction] ------------- ---------------- |----------- | rtw89_usb | <-------- | rtw89_8852au | | ------------- ---------------- V --------------- | -------------- | | <--------------- | rtw89_core | <--- | rtw89_8852a | -------------- | | <--------------- ^ ^ --------------- | | | ------------- ---------------- | | | | <-------- | rtw89_8852ae | | |----------- | rtw89_pci | ---------------- | | | <----------------- | ------------- | | --------------- ---------------- |--------------- | rtw89_8852c | <------ | rtw89_8852ce | --------------- ---------------- The data of 8852A/8852C is extracted to rtw89_8852a/rtw89_8852c. And rtw89_pci/rtw89_usb handles only common flow of pci/usb bus. Finally, 8852AE, 8852AU, and 8852CE have individual entry modules, i.e. rtw89_8852ae, rtw89_8852au, and rtw89_8852ce correspondingly. Signed-off-by:Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for v5.18. 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
-
Wen Gong authored
For the NL80211_REGDOM_SET_BY_USER hint from cfg80211, it set the new alpha2 code to ath11k, then ath11k send WMI_SET_INIT_COUNTRY_CMDID to firmware for all chips currently. When test with WCN6855/QCA6390 chips, this WMI CMD leads firmware crash. For AP based chips(ipq8074/qcn9074), WMI_SET_INIT_COUNTRY_CMDID is used to send to firmware, for STATION based chips(WCN6855/QCA6390), it need to use another WMI CMD WMI_SET_CURRENT_COUNTRY_CMDID. Add flag current_cc_support in hardware parameters, it is used to distinguish AP/STA platform. After that, the firmware will work normal and the regulatory feature works well for QCA6390/WCN6855. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 Signed-off-by:
Wen Gong <quic_wgong@quicinc.com> Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220119041355.32014-1-quic_wgong@quicinc.com
-
Wen Gong authored
When station connect to AP of 6 GHz with 40 MHz bandwidth, the TX is always stay 20 MHz, it is because the flag WMI_PEER_40MHZ is not set while peer assoc. Add the flag if remote peer is 40 MHz bandwidth. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 Fixes: c3a7d7eb ("ath11k: add 6 GHz params in peer assoc command") Signed-off-by:
-
Pavel Skripkin authored
Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing field initialization. In htc_connect_service() svc_meta_len and pad are not initialized. Based on code it looks like in current skb there is no service data, so simply initialize svc_meta_len to 0. htc_issue_send() does not initialize htc_frame_hdr::control array. Based on firmware code, it will initialize it by itself, so simply zero whole array to make KMSAN happy Fail logs: BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 4-7 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 16-17 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 Fixes: fb9987d0 ("ath9k_htc: Support for AR9271 chipset.") Reported-by: syzbot+f83a1df1ed4f67e8d8ad@syzkaller.appspotmail.com Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
Pavel Begunkov says: ==================== udp/ipv6 optimisations Shed some weight from udp/ipv6. Zerocopy benchmarks over dummy showed ~5% tx/s improvement, should be similar for small payload non-zc cases. The performance comes from killing 4 atomics and a couple of big struct memcpy/memset. 1/10 removes a pair of atomics on dst refcounting for cork->skb setup, 9/10 saves another pair on cork init. 5/10 and 8/10 kill extra 88B memset and memcpy respectively. ==================== Link: https://lore.kernel.org/r/cover.1643243772.git.asml.silence@gmail.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Pavel Begunkov authored
Inline a part of ipv6_fixup_options() to avoid extra overhead on function call if opt is NULL. Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Pavel Begunkov authored
udpv6_sendmsg() doesn't need dst after calling ip6_make_skb(), so instead of taking an additional reference inside ip6_setup_cork() and releasing the initial one afterwards, we can hand over a reference into ip6_make_skb() saving two atomics. The only other user of ip6_setup_cork() is ip6_append_data() and it requires an extra dst_hold(). Signed-off-by:
-
Pavel Begunkov authored
udpv6_sendmsg() first initialises an on-stack 88B struct flowi6 and then copies it into cork, which is expensive. Avoid the copy in corkless case by initialising on-stack cork->fl directly. The main part is a couple of lines under !corkreq check. The rest converts fl6 variable to be a pointer. Signed-off-by:
-
Pavel Begunkov authored
Another preparation patch. inet_cork_full already contains a field for iflow, so we can avoid passing a separate struct iflow6 into __ip6_append_data() and ip6_make_skb(), and use the flow stored in inet_cork_full. Make sure callers set cork->fl, i.e. we init it in ip6_append_data() and before calling ip6_make_skb(). Signed-off-by:
-
Pavel Begunkov authored
Convert a struct inet_cork argument in __ip6_append_data() to struct inet_cork_full. As one struct contains another inet_cork is still can be accessed via ->base field. It's a preparation patch making further changes a bit cleaner. Signed-off-by:
-
Pavel Begunkov authored
It doesn't appear there is any reason for ip6_cork_release() to zero cork->fl, it'll be fully filled on next initialisation. This 88 bytes memset accounts to 0.3-0.5% of total CPU cycles. It's also needed in following patches and allows to remove an extar flow copy in udp_v6_push_pending_frames(). Signed-off-by:
-
Pavel Begunkov authored
Clean up ip6_setup_cork() and ip6_cork_release() adding a local variable for v6_cork->opt. It's a preparation patch for further changes. Signed-off-by:
-
Pavel Begunkov authored
ipv6_push_nfrag_opts() doesn't change passed daddr, and so __ip6_make_skb() doesn't actually need to keep an on-stack copy of fl6->daddr. Set initially final_dst to fl6->daddr, ipv6_push_nfrag_opts() will override it if needed, and get rid of extra copies. Signed-off-by:
-
Pavel Begunkov authored
Corked AF_INET for ipv6 socket doesn't appear to be the hottest case, so move it out of the common path under up->pending check to remove overhead. Signed-off-by:
-
Pavel Begunkov authored
__ip6_make_skb() gets a cork->dst ref, hands it over to skb and shortly after puts cork->dst. Save two atomics by stealing it without extra referencing, ip6_cork_release() handles NULL cork->dst. Signed-off-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== mlxsw: Various updates This patchset contains miscellaneous updates for mlxsw. No user visible changes that I am aware of. Patches #1-#5 rework registration of internal traps in preparation of line cards support. Patch #6 improves driver resilience against a misbehaving device. Patch #7 prevents the driver from overwriting device internal actions. See the commit message for more details. ==================== Link: https://lore.kernel.org/r/20220127090226.283442-1-idosch@nvidia.comSigned-off-by:
-
Ido Schimmel authored
In Spectrum-2 and later ASICs, each TCAM region has a default action that is executed in case a packet did not match any rule in the region. The location of the action in the database (KVDL) is computed by adding the region's index to a base value. Some TCAM regions are not exposed to the host and used internally by the device. Allocate KVDL entries for the default actions of these regions to avoid the host from overwriting them. With mlxsw, lookups in the internal regions are not currently performed, but it is a good practice not to overwrite their default actions. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Amit Cohen authored
When processing events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not for the CPU port (local port 0), which exists, but does not have all the fields as any local port. This can result in a NULL pointer dereference when trying access 'struct mlxsw_sp_port' fields which are not initialized for CPU port. Commit 63b08b1f ("mlxsw: spectrum: Protect driver from buggy firmware") already handled such issue by bailing early when processing a PUDE event reported for the CPU port. Generalize the approach by moving the check to a common function and making use of it in all relevant places. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Signed-off-by:
-
Jiri Pirko authored
For event traps which are used in core, avoid having a separate trap group for each event. Instead of that introduce a single core event trap group and use it for all event traps. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Jiri Pirko authored
These functions belong to core.c alongside the functions that register/unregister a single trap. Move it there. Make the functions possibly usable by other parts of mlxsw code. Signed-off-by:
-
Jiri Pirko authored
Instead of initializing the trap groups used by core in spectrum.c over op, do it directly in core.c Signed-off-by:
-
Jiri Pirko authored
The call inits the EMAD group, but other groups as well. Therefore, move it out of EMAD init code and call it before. Signed-off-by:
-
Jiri Pirko authored
Instead of calling the same code four times, do it in a loop over array which contains trap grups to be set. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxJakub Kicinski authored
Saeed Mahameed says: ==================== mlx5-updates-2022-01-27 1) Dima, adds an internal mlx5 steering callback per steering provider (FW vs SW steering), to advertise steering capabilities implemented by each module, this helps upper modules in mlx5 to know what is supported and what's not without the need to tell what is the underlying steering mode. 2nd patch is the usecase where this interface is used to implement Vlan Push/pop for uplink with SW steering, where in FW mode it's not supported yet. 2) Roi Dayan improves code readability and maintainability as preparation step for multi attribute instance per flow in mlx5 TC module Currently the mlx5_flow object contains a single mlx5_attr instance. However, multi table actions (e.g. CT) instantiate multiple attr instances. This is a refactoring series in a preparation to support multiple attribute instances per flow. The commits prepare functions to get attr instance instead of using flow->attr and also using attr->flags if the flag is more relevant to be attr flag and not a flow flag considering there will be multiple attr instances. i.e. CT and SAMPLE flags. * tag 'mlx5-updates-2022-01-27' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net/mlx5: VLAN push on RX, pop on TX net/mlx5: Introduce software defined steering capabilities net/mlx5: Remove unused TIR modify bitmask enums net/mlx5e: CT, Remove redundant flow args from tc ct calls net/mlx5e: TC, Store mapped tunnel id on flow attr net/mlx5e: Test CT and SAMPLE on flow attr net/mlx5e: Refactor eswitch attr flags to just attr flags net/mlx5e: CT, Don't set flow flag CT for ct clear flow net/mlx5e: TC, Hold sample_attr on stack instead of pointer net/mlx5e: TC, Reject rules with multiple CT actions net/mlx5e: TC, Refactor mlx5e_tc_add_flow_mod_hdr() to get flow attr net/mlx5e: TC, Pass attr to tc_act can_offload() net/mlx5e: TC, Split pedit offloads verify from alloc_tc_pedit_action() net/mlx5e: TC, Move pedit_headers_action to parse_attr net/mlx5e: Move counter creation call to alloc_flow_attr_counter() net/mlx5e: Pass attr arg for attaching/detaching encaps net/mlx5e: Move code chunk setting encap dests into its own function ==================== Link: https://lore.kernel.org/r/20220127204007.146300-1-saeed@kernel.orgSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== 1GbE Intel Wired LAN Driver Updates 2022-01-27 Christophe Jaillet removes useless DMA-32 fallback calls from applicable Intel drivers and simplifies code as a result of the removal. * '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: igbvf: Remove useless DMA-32 fallback configuration igb: Remove useless DMA-32 fallback configuration igc: Remove useless DMA-32 fallback configuration ice: Remove useless DMA-32 fallback configuration iavf: Remove useless DMA-32 fallback configuration e1000e: Remove useless DMA-32 fallback configuration i40e: Remove useless DMA-32 fallback configuration ixgbevf: Remove useless DMA-32 fallback configuration ixgbe: Remove useless DMA-32 fallback configuration ixgb: Remove useless DMA-32 fallback configuration ==================== Link: https://lore.kernel.org/r/20220127215224.422113-1-anthony.l.nguyen@intel.comSigned-off-by:
-
- 27 Jan, 2022 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
No conflicts. Signed-off-by: -
Dima Chumak authored
Some older NIC hardware isn't capable of doing VLAN push on RX and pop on TX. A workaround has been added in software to support it, but it has a performance penalty since it requires a hairpin + loopback. There's no such limitation with the newer NICs, so no need to pay the price of the w/a. With this change the software w/a is disabled for certain HW versions and steering modes that support it. Signed-off-by:
Dima Chumak <dchumak@nvidia.com> Reviewed-by:
Oz Shlomo <ozsh@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
Dima Chumak authored
There are two different internal steering modes, abstracted from the rest of the driver. In order to keep upper layer of the driver agnostic to the differences in capabilities of the steering modes, this patch introduces mlx5_fs_get_capabilities() API to check if a certain software defined capability is supported. It differs from the capabilities exposed by the hardware, as it takes into account the flow steering mode (SMFS/DMFS) currently enabled. This implementation supports only two capability flags: MLX5_FLOW_STEERING_CAP_VLAN_PUSH_ON_RX MLX5_FLOW_STEERING_CAP_VLAN_POP_ON_TX They map to DR_ACTION_STATE_PUSH_VLAN and DR_ACTION_STATE_POP_VLAN actions, implemented in SW steering earlier in commit f5e22be5 ("net/mlx5: DR, Split modify VLAN state to separate pop/push states"). Which enables using of pop/push vlan without restrictions, e.g. doing vlan pop on TX and RX, compared to FW steering that supports only vlan pop on RX and push on TX. Other capabilities can be added in the future. Signed-off-by:
Mark Bloch <mbloch@nvidia.com> Reviewed-by:
Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by:
-
Tariq Toukan authored
struct mlx5_ifc_modify_tir_bitmask_bits is used for the bitmask of MODIFY_TIR operations. Remove the unused bitmask enums. Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Reviewed-by:
Gal Pressman <gal@nvidia.com> Signed-off-by:
-
