- 25 Jul, 2023 38 commits
-
-
Ming Yen Hsieh authored
Due to the scan command may only request legacy bands and PSC channel in 6GHz band, we are unable to scan the APs on non-PSC channel in this case. Enable WIPHY_FLAG_SPLIT_SCAN_6GHZ to support non-PSC channel (obtained during scan on legacy bands) in 6GHz scan request. Fixes: 50ac15a5 ("mt76: mt7921: add 6GHz support") Signed-off-by:
Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Signed-off-by:
Deren Wu <deren.wu@mediatek.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name>
-
Ryder Lee authored
The stats are clear-on-read, which makes it very difficult for tools to adequately deal with wrapped stats and with keeping good totals. So, accumulate these values when they are read from the firmware/radio and present totals to user-space. Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
-
Ryder Lee authored
mt76_connac2_mac_fill_txs() counts tx_nss but ethtool doesn't show stats. Add missing histogram accordingly. Signed-off-by:
-
Deren Wu authored
txs may be dropped if the frame is aggregated in AMSDU. When the problem shows up, some SKBs would be hold in driver to cause network stopped temporarily. Even if the problem can be recovered by txs timeout handling, mt7921 still need to disable txs in AMSDU to avoid this issue. Cc: stable@vger.kernel.org Fixes: 163f4d22 ("mt76: mt7921: add MAC support") Reviewed-by:
Shayne Chen <shayne.chen@mediatek.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Deren Wu authored
Get missing tx retries/failed counts from txfree done events and report them via mt7921_sta_statistics(). Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Alexander Couzens authored
Add support for the MediaTek MT7981 SoC which is similar to the MT7986 but with a newer IP cores and only 2x ARM Cortex-A53 instead of 4x. Unlike MT7986 the MT7981 can only connect a single wireless frontend, usually MT7976 is used for DBDC. Signed-off-by:
Alexander Couzens <lynxis@fe80.eu> Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Reviewed-by:
-
Daniel Golle authored
Add mediatek,mt7981-wmac compatible string entry. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Lorenzo Bianconi authored
Get rid of private copy of mib_stats structure. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
-
Lorenzo Bianconi authored
Get rid of private copy of mib_stats structure. Signed-off-by:
-
Lorenzo Bianconi authored
mib_stats structure is shared by mostly all chipsets. Move it to shared code. Signed-off-by:
-
Lorenzo Bianconi authored
Get rid of MT_MIB_RTS_COUNT_MASK marco duplication in mt7921/regs.h Signed-off-by:
-
Deren Wu authored
mt7921 support following antenna combiantions only. * primary + secondary (2x2) * primary only (1x1) Since we cannot work on secondary antenna only, return error if the antenna bitmap is 0x2 in .set_antenna(). For example: iw phy0 set antenna 3 3 /* valid */ iw phy0 set antenna 1 1 /* valid */ iw phy0 set antenna 2 2 /* invalid */ Cc: stable@vger.kernel.org Fixes: e0f9fdda ("mt76: mt7921: add ieee80211_ops") Suggested-by:
Knox Chiou <knoxchiou@google.com> Signed-off-by:
-
Ryder Lee authored
Avoid blocking other statistics sinfo->filled when txrate is unavailable. Signed-off-by:
-
Ryder Lee authored
Avoid blocking other statistics sinfo->filled when txrate is unavailable. Signed-off-by:
-
Peter Chiu authored
AQL relies on accurate tx rate reporting, so add this patch for non-binding skb rate when WED is enabled. Co-developed-by:
Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by:
-
Peter Chiu authored
Concurrent binding/non-binding skbs could be handled anywhere which leads to mixed byte counting, so switch to use PPDU TxS reporting regardless Tx paths when WED is active. Fixes: 43eaa368 ("wifi: mt76: add PPDU based TxS support for WED device") Co-developed-by:
-
Peter Chiu authored
PPDU TxS can only report MPDU count whereas mac80211 requires MSDU scale (NL80211_STA_INFO_TX_PACKETS), so switch to get MSDU counts from WA statistic. Note that mt7915 WA firmware only counts tx_packet for WED path, so driver needs to take care of host path additionally. Fixes: 43eaa368 ("wifi: mt76: add PPDU based TxS support for WED device") Co-developed-by:
-
Ryder Lee authored
Get missing tx retries/failed counts from txfree done events and report them via mt7915_sta_statistics(). Co-developed-by:
-
StanleyYP Wang authored
The background radar uses MT_RX_SEL2 as its band indication, so fix it. Fixes: 7a53eecd (wifi: mt76: mt7915: check the correctness of event data) Signed-off-by:
StanleyYP Wang <StanleyYP.Wang@mediatek.com> Signed-off-by:
-
Ryder Lee authored
Enable support for the 5GHz channel 177 with center frequency 5885MHz and operating class 125 based on IEEE Std 802.11ax-2021 Table E-4. Signed-off-by:
Himanshu Goyal <himanshu.goyal@mediatek.com> Signed-off-by:
-
Ryder Lee authored
The Group ID Management frame is an Action frame of category VHT. It is transmitted by the AP to assign or change the user position of a STA for one or more group IDs. Also, sniffer can use a given group id to monitor STA that belongs to that group. Notify underlying driver of changes via BSS_CHANGED_MU_GROUPS. Signed-off-by:
-
Ryder Lee authored
The Group ID Management frame is an Action frame of category VHT. It is transmitted by the AP to assign or change the user position of a STA for one or more group IDs. Also, sniffer can use a given group id to monitor STA that belongs to that group. Signed-off-by:
-
Ryder Lee authored
When header translation failure is indicated, the hardware will insert an extra 2-byte field containing the data length after the protocol type field. This happens either when the LLC-SNAP pattern did not match, or if a VLAN header was detected. The previous commit accidentally breaks the logic, so reverts back. Fixes: 27db47ab (wifi: mt76: mt7996: enable mesh HW amsdu/de-amsdu support) Signed-off-by:
-
Matt Whitlock authored
mt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() and mt7921_skb_add_usb_sdio_hdr(), both of which blindly assume that adequate headroom will be available in the passed skb. This assumption typically is satisfied when the skb was allocated in the net core for transmission via the mt7921 netdev (although even that is only an optimization and is not strictly guaranteed), but the assumption is sometimes not satisfied when the skb originated in the receive path of another netdev and was passed through to the mt7921, such as by the bridge layer. Blindly prepending bytes to an skb is always wrong. This commit introduces a call to skb_cow_head() before the call to mt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() to ensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can be pushed onto the skb. Without this fix, I can trivially cause kernel panics by bridging an MT7921AU-based USB 802.11ax interface with an Ethernet interface on an Intel Atom-based x86 system using its onboard RTL8169 PCI Ethernet adapter and also on an ARM-based Raspberry Pi 1 using its onboard SMSC9512 USB Ethernet adapter. Note that the panics do not occur in every system configuration, as they occur only if the receiving netdev leaves less headroom in its received skbs than the mt7921 needs for its SDIO headers. Here is an example stack trace of this panic on Raspberry Pi OS Lite 2023-02-21 running kernel 6.1.24+ [1]: skb_panic from skb_push+0x44/0x48 skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common] mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb] mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76] __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76] mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76] mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common] mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76] __mt76_worker_fn [mt76] from kthread+0xbc/0xe0 kthread from ret_from_fork+0x14/0x34 After this fix, bridging the mt7921 interface works fine on both of my previously problematic systems. [1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a Link: https://github.com/openwrt/openwrt/issues/11796Signed-off-by:
Matt Whitlock <kernel@mattwhitlock.name> Signed-off-by:
-
Dmitry Antipov authored
Remove unused 'struct gpioh_item'. It seems it was so since commit 5b435de0 ("net: wireless: add brcm80211 drivers"). Signed-off-by:
Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230719083232.158177-1-dmantipov@yandex.ru
-
Johannes Wiesboeck authored
Allow moving the wiphy device for mwififex to a non-inital network namespace. Many wireless drivers enable this flag implicitly by initializing through the generic ieee80211_alloc_hw_nm function. As mwifiex does not utilize this function WIPHY_FLAG_NETNS_OK must be set explicitly. Moving to network namespace and working connection tested using wpa_supplicant from a network namespace as well as from a container on GyroidOS. The hardware was the Toradex Apalis i.MX8QM Board using the Azurewave AW-CM276NF wireless module. Signed-off-by:
Johannes Wiesboeck <johannes.wiesboeck@aisec.fraunhofer.de> Reviewed-by:
Michael Weiß <michael.weiss@aisec.fraunhofer.de> Signed-off-by:
-
Dmitry Antipov authored
When compiling with gcc 13.1 and CONFIG_FORTIFY_SOURCE=y, I've noticed the following: In function ‘fortify_memcpy_chk’, inlined from ‘mwifiex_construct_tdls_action_frame’ at drivers/net/wireless/marvell/mwifiex/tdls.c:765:3, inlined from ‘mwifiex_send_tdls_action_frame’ at drivers/net/wireless/marvell/mwifiex/tdls.c:856:6: ./include/linux/fortify-string.h:529:25: warning: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 529 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The compiler actually complains on: memmove(pos + ETH_ALEN, &mgmt->u.action.category, sizeof(mgmt->u.action.u.tdls_discover_resp)); and it happens because the fortification logic interprets this as an attempt to overread 1-byte 'u.action.category' member of 'struct ieee80211_mgmt'. To silence this warning, it's enough to pass an address of 'u.action' itself instead of an address of its first member. This also fixes an improper usage of 'sizeof()'. Since 'skb' is extended with 'sizeof(mgmt->u.action.u.tdls_discover_resp) + 1' bytes (where 1 is actually 'sizeof(mgmt->u.action.category)'), I assume that the same number of bytes should be copied. Suggested-by:Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Dmitry Antipov authored
Prefer 'strscpy()' over 'strlcpy()' in 'mwifiex_init_hw_fw()'. Signed-off-by:
-
Bitterblue Smith authored
Theoretically this chip can handle 127 clients. Only compile tested but it should work as well as the RTL8188FU. Signed-off-by:
Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by:
-
Bitterblue Smith authored
Theoretically this chip can handle 127 clients. Tested only very briefly but it should work as well as the RTL8188FU. Signed-off-by:
-
Bitterblue Smith authored
Theoretically this chip can handle 15 clients. Tested only very briefly but it should work as well as the RTL8188FU. Signed-off-by:
-
Bitterblue Smith authored
Theoretically this chip can handle 127 clients. Tested only very briefly but it should work as well as the RTL8188FU. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Yueh-Shun Li authored
Spell "transmits" properly. Found by searching for keyword "tranm". Signed-off-by:
Yueh-Shun Li <shamrocklee@posteo.net> Signed-off-by:
-
Zhang Shurong authored
If there is a failure during kstrtobool_from_user() rtw89_debug_priv_btc_manual_set should return a negative error code instead of returning the count directly. Fix this bug by returning an error code instead of a count after a failed call of the function "kstrtobool_from_user". Moreover I omitted the label "out" with this source code correction. Fixes: e3ec7017 ("rtw89: add Realtek 802.11ax driver") Signed-off-by:
Zhang Shurong <zhang_shurong@foxmail.com> Acked-by:
-
Dmitry Antipov authored
Since all iterators called by 'rtw_iterate_vifs()' never uses 'mac' argument, it may be omitted, and 'struct rtw_vifs_entry' may be simplified accordingly. Signed-off-by:
-
Dmitry Antipov authored
Drop no longer used 'bulkout_size' of 'struct rtw_usb' as well as related macros from usb.h and leftovers in 'rtw_usb_parse()'. This follows commit 462c8db6 ("wifi: rtw88: usb: drop now unnecessary URB size check"). Reviewed-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Dmitry Antipov authored
Drop unused and set but unused 'last_push' of 'struct rtw_txq', 'wireless_set' of 'struct rtw_sta_info', 'usb_txagg_num' of 'struct rtw_usb' and 'n' of 'struct rx_usb_ctrl_block', unused definition of 'struct rtw_timer_list', adjust related code. Reviewed-by:
-
Dmitry Antipov authored
Fix possible crash and memory leak on driver unload by deleting TX purge timer and freeing C2H queue in 'rtw_core_deinit()', shrink critical section in the latter by freeing COEX queue out of TX report lock scope. Reviewed-by:
-
- 24 Jul, 2023 1 commit
-
-
Eric Dumazet authored
IPv6 inet sockets are supposed to have a "struct ipv6_pinfo" field at the end of their definition, so that inet6_sk_generic() can derive from socket size the offset of the "struct ipv6_pinfo". This is very fragile, and prevents adding bigger alignment in sockets, because inet6_sk_generic() does not work if the compiler adds padding after the ipv6_pinfo component. We are currently working on a patch series to reorganize TCP structures for better data locality and found issues similar to the one fixed in commit f5d54767 ("tcp: fix tcp_inet6_sk() for 32bit kernels") Alternative would be to force an alignment on "struct ipv6_pinfo", greater or equal to __alignof__(any ipv6 sock) to ensure there is no padding. This does not look great. v2: fix typo in mptcp_proto_v6_init() (Paolo) Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Chao Wu <wwchao@google.com> Cc: Wei Wang <weiwan@google.com> Cc: Coco Li <lixiaoyan@google.com> Cc: YiFei Zhu <zhuyifei@google.com> Reviewed-by:
David S. Miller <davem@davemloft.net>
-
- 23 Jul, 2023 1 commit
-
-
Patrick Rohr authored
This change adds a new sysctl accept_ra_min_rtr_lft to specify the minimum acceptable router lifetime in an RA. If the received RA router lifetime is less than the configured value (and not 0), the RA is ignored. This is useful for mobile devices, whose battery life can be impacted by networks that configure RAs with a short lifetime. On such networks, the device should never gain IPv6 provisioning and should attempt to drop RAs via hardware offload, if available. Signed-off-by:
Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Cc: Lorenzo Colitti <lorenzo@google.com> Signed-off-by:
-
