summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2025-01-13wifi: mac80211: change disassoc sequence a bitMiri Korenblit
Currently, the sequence goes like this (among others): 1. flush all stations (including the AP ones) -> this will tell the drivers to remove the stations 2. notify the driver the vif is not associated. Which means that in between 1 and 2, the state is that the vif is associated, but there is no AP station, which makes no sense, and may be problematic for some drivers (for example iwlwifi) Change the sequence to: 1. flush the TDLS stations 2. move the AP station to IEEE80211_STA_NONE 3. notify the driver about the vif being unassociated 4. flush the AP station In order to not break other drivers, add a vif flag to indicate whether the driver wants to new sequence or not. If the flag is not set, then things will be done in the old sequence. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20241224192322.996ad1be6cb3.I7815d33415aa1d65c0120b54be7a15a45388f807@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-13wifi: iwlwifi: mvm: send the right link idMiri Korenblit
in iwl_mvm_sta_del we call iwl_mvm_sec_key_remove_ap with link id 0, when it might actually be something else, causing us to skip all the keys. Since the call to iwl_mvm_sec_key_remove_ap was mostly skipped (because for STA mode we are not removing the ap sta immediately, but later when the vif is set to unassocicated), this was fine. The other call to iwl_mvm_sec_key_remove_ap, when we actually do remove the ap sta, was called with the right link id. So the bug didn't happen so far. Now that mac80211 is going to change such that we can immediately remove the ap sta, the call to iwl_mvm_sec_key_remove_ap with link id 0 will not be skipped, so no key will be removed, and then when mac80211 eventually tells us to remove that keys, we no longer have the sta ids for them. Simply pass the right link id to iwl_mvm_sec_key_remove_ap. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20241224192322.db7a5f551492.I79fe16a14fa0bb20751ba2526c3195fef39ef772@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-13wifi: iwlwifi: mvm: remove pre-mld code from mld pathMiri Korenblit
This code is only relevant for older devices, that are not supporting mld, so shouldn't be in iwl_mvm_sta_del, which is common to both pre-mld and mld. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20241224192322.a665d16a3857.I840b00a7b38f3967ec5e75ff6a85e756f4d82437@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-13wifi: iwlwifi: fix documentation about initial values in station tableRolf Eike Beer
The inverse value is stored in the table, make the documentation match the code. Signed-off-by: Rolf Eike Beer <eb@emlix.com> Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/2008554.usQuhbGJ8B@devpool47.emlix.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-13wifi: mt76: mt7921: fix a potential scan no APsQuan Zhou
In multi-channel scenarios, the granted channel must be aborted before station remove. Otherwise, the firmware will be put into a wrong state, resulting in have chance to make subsequence scan no APs. With this patch, the granted channel will be always aborted before station remove. Signed-off-by: Quan Zhou <quan.zhou@mediatek.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Tested-by: David Ruth <druth@chromium.org> Reviewed-by: David Ruth <druth@chromium.org> Link: https://patch.msgid.link/1ac1ae779db86d4012199a24ea2ca74050ed4af6.1721300411.git.quan.zhou@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-13wifi: mt76: Fix EHT NSS radiotap reporting.Ben Greear
Wireshark and iwlwifi use zero-based NSS reporting, adjust mt76 to do the same. Signed-off-by: Ben Greear <greearb@candelatech.com> Link: https://patch.msgid.link/20240909211238.3237111-2-greearb@candelatech.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-13wifi: mt76: mt7996: Add eht radiotap tlvBen Greear
This duplicates what the 7925 driver is doing, wireshark seems to at least mostly decode it as expected. Signed-off-by: Ben Greear <greearb@candelatech.com> Link: https://patch.msgid.link/20240909211238.3237111-1-greearb@candelatech.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-13wifi: mt76: mt7915: Fix mesh scan on MT7916 DBDCNicolas Cavallari
commit c4f075582304 ("wifi: mt76: mt7915: fix command timeout in AP stop period") changes the behavior of mt7915_bss_info_changed() in mesh mode when enable_beacon becomes false: it calls mt7915_mcu_add_bss_info(..., false) and mt7915_mcu_add_sta(..., false) while the previous code didn't. These sends mcu commands that apparently confuse the firmware. This breaks scanning while in mesh mode on AsiaRF MT7916 DBDC-based cards: scanning works but no mesh frames get sent afterwards and the firmware seems to be hosed. It breaks on MT7916 DBDC but not on MT7915 DBDC. Fixes: c4f075582304 ("wifi: mt76: mt7915: fix command timeout in AP stop period") Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Link: https://patch.msgid.link/20240927085350.4594-1-nicolas.cavallari@green-communications.fr Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-13wifi: mt76: mt7615: Convert comma to semicolonShen Lichuan
To ensure code clarity and prevent potential errors, it's advisable to employ the ';' as a statement separator, except when ',' are intentionally used for specific purposes. Signed-off-by: Shen Lichuan <shenlichuan@vivo.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20240911034243.31596-1-shenlichuan@vivo.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-13wifi: mt76: mt7925: fix off by one in mt7925_load_clc()Dan Carpenter
This comparison should be >= instead of > to prevent an out of bounds read and write. Fixes: 9679ca7326e5 ("wifi: mt76: mt7925: fix a potential array-index-out-of-bounds issue for clc") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/84bf5dd2-2fe3-4410-a7af-ae841e41082a@stanley.mountain Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-13wifi: mt76: mt7921s: fix a potential firmware freeze during startupLeon Yen
The maximum command quota of the firmware may be exceeded because the command to retrieve the quota setting has not been taken into account. This patch considers not only the quota usage of the command retrieving quota settings but also limits the total quota usage. Signed-off-by: Leon Yen <leon.yen@mediatek.com> Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20240916060157.10157-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-13wifi: mt76: mt792x: add P2P_DEVICE supportHao Zhang
Regist the NL80211_IFTYPE_P2P_DEVICE to support p2p device for mt792x chips Signed-off-by: Hao Zhang <hao.zhang.mediatek@gmail.com> Signed-off-by: allan.wang <allan.wang@mediatek.com> Signed-off-by: Ming Yen Hsieh <MingYen.Hsieh@mediatek.com> Link: https://patch.msgid.link/20240919081713.23787-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-13wifi: mt76: mt7996: set correct background radar capabilityStanleyYP Wang
Some of the variants do not support background radar, so add a helper to report background radar capability. Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Tested-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/20240926032440.15978-3-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-13wifi: mt76: mt7996: add support for more variantsShayne Chen
Current varaints supported: - mt7996 chipset: tri-band, 4+4+4 NSS, eFEM - mt7992 chipset: dual-band, 4+4 NSS, eFEM This patch adds support for the following variants: - mt7996 chipset: - tri-band, 4+4+4 NSS, iFEM - tri-band, 2+3+3 NSS, eFEM - tri-band, 2+3+3 NSS, iFEM - mt7992 chipset: - dual-band, 4+4 NSS, iFEM - dual-band, 4+4 NSS, with band0 iFEM and band1 eFEM - dual-band, 2+3 NSS, eFEM - dual-band, 2+3 NSS, iFEM Co-developed-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com> Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Tested-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/20240926032440.15978-2-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-13wifi: mt76: mt7996: extend flexibility of mt7996_mcu_get_eeprom()Shayne Chen
Support passing customized buffer pointer and length to mt7996_mcu_get_eeprom(). This is the preparation for adding more variants support which needs to prefetch FEM module from efuse, and also fixes potential OOB issue when reading the last efuse block. Co-developed-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com> Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Tested-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/20240926032440.15978-1-shayne.chen@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-01-12kernel-wide: add explicity||explicitly to spelling.txtShivam Chaudhary
Correct the spelling dictionary so that future instances will be caught by checkpatch, and fix the instances found. Link: https://lkml.kernel.org/r/20241211154903.47027-1-cvam0000@gmail.com Signed-off-by: Shivam Chaudhary <cvam0000@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Naveen N Rao <naveen@kernel.org> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Shivam Chaudhary <cvam0000@gmail.com> Cc: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-01-12wifi: ath11k: convert timeouts to secs_to_jiffies()Easwar Hariharan
Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced secs_to_jiffies(). As the value here is a multiple of 1000, use secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication. This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with the following Coccinelle rules: @@ constant C; @@ - msecs_to_jiffies(C * 1000) + secs_to_jiffies(C) @@ constant C; @@ - msecs_to_jiffies(C * MSEC_PER_SEC) + secs_to_jiffies(C) Link: https://lkml.kernel.org/r/20241210-converge-secs-to-jiffies-v3-14-ddfefd7e9f2a@linux.microsoft.com Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Daniel Mack <daniel@zonque.org> Cc: David Airlie <airlied@gmail.com> Cc: David S. Miller <davem@davemloft.net> Cc: Dick Kennedy <dick.kennedy@broadcom.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Florian Fainelli <florian.fainelli@broadcom.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Haojian Zhuang <haojian.zhuang@gmail.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Ilya Dryomov <idryomov@gmail.com> Cc: Jack Wang <jinpu.wang@cloud.ionos.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: James Smart <james.smart@broadcom.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Jeff Johnson <jjohnson@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Jeroen de Borst <jeroendb@google.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Joe Lawrence <joe.lawrence@redhat.com> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Jozsef Kadlecsik <kadlec@netfilter.org> Cc: Julia Lawall <julia.lawall@inria.fr> Cc: Kalle Valo <kvalo@kernel.org> Cc: Louis Peens <louis.peens@corigine.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Miroslav Benes <mbenes@suse.cz> Cc: Naveen N Rao <naveen@kernel.org> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Nicolas Palix <nicolas.palix@imag.fr> Cc: Oded Gabbay <ogabbay@kernel.org> Cc: Ofir Bitton <obitton@habana.ai> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Praveen Kaligineedi <pkaligineedi@google.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Roger Pau Monné <roger.pau@citrix.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Scott Branden <sbranden@broadcom.com> Cc: Shailend Chand <shailend@google.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: Simon Horman <horms@kernel.org> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Takashi Iwai <tiwai@suse.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Xiubo Li <xiubli@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-01-12net/mlx5: SHAMPO: Introduce new SHAMPO specific HCA capsSaeed Mahameed
Read and cache SHAMPO specific caps for header data split capabilities. Will be used in downstream patch. Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109204231.1809851-4-tariqt@nvidia.com Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-01-12wifi: rtw88: Add support for LED blinkingBitterblue Smith
Register a struct led_classdev with the kernel's LED subsystem and create a throughput-based trigger for it. Then mac80211 makes the LED blink. Tested with Tenda U12 (RTL8812AU), Tenda U9 (RTL8811CU), TP-Link Archer T2U Nano (RTL8811AU), TP-Link Archer T3U Plus (RTL8812BU), Edimax EW-7611UCB (RTL8821AU), LM842 (RTL8822CU). Also tested with devices which don't have LEDs: the laptop's internal RTL8822CE and a no-name RTL8723DU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/6c43451f-ab2f-4e76-ac6e-ff5a18dd981d@gmail.com
2025-01-12wifi: rtw88: sdio: Fix disconnection after beacon lossFiona Klute
This is the equivalent of commit 28818b4d871b ("wifi: rtw88: usb: Fix disconnection after beacon loss") for SDIO chips. Tested on Pinephone (RTL8723CS), random disconnections became rare, instead of a frequent nuisance. Cc: stable@vger.kernel.org Signed-off-by: Fiona Klute <fiona.klute@gmx.de> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # Tested on Pinebook Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250106135434.35936-1-fiona.klute@gmx.de
2025-01-12wifi: rtw88: 8703b: Fix RX/TX issuesVasily Khoruzhick
Fix 3 typos in 8703b driver. 2 typos in calibration routines are not fatal and do not seem to have any impact, just fix them to match vendor driver. However the last one in rtw8703b_set_channel_bb() clears too many bits in REG_OFDM0_TX_PSD_NOISE, causing TX and RX issues (neither rate goes above MCS0-MCS1). Vendor driver clears only 2 most significant bits. With the last typo fixed, the driver is able to reach MCS7 on Pinebook Cc: stable@vger.kernel.org Fixes: 9bb762b3a957 ("wifi: rtw88: Add definitions for 8703b chip") Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Fiona Klute <fiona.klute@gmx.de> Tested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103075107.1337533-1-anarsoul@gmail.com
2025-01-12wifi: rtw88: Delete rf_type member of struct rtw_sta_infoBitterblue Smith
It's not used for anything. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/b80f7904-c6b4-4d12-a5f9-69ab9b965732@gmail.com
2025-01-12wifi: rtw88: Add USB PHY configurationBitterblue Smith
Add some extra configuration for USB devices. Currently only RTL8822BU version (cut) D needs this. The new code makes use of the existing usb3_param_8822b array from rtw8822b.c. A user reported that TP-Link Archer T3U in USB 3 mode was randomly disconnecting from USB: [ 26.036502] usb 2-2: new SuperSpeed USB device number 3 using xhci_hcd ... [ 27.576491] usb 2-2: USB disconnect, device number 3 [ 28.621528] usb 2-2: new SuperSpeed USB device number 4 using xhci_hcd ... [ 45.984521] usb 2-2: USB disconnect, device number 4 ... [ 46.845585] usb 2-2: new SuperSpeed USB device number 5 using xhci_hcd ... [ 94.400380] usb 2-2: USB disconnect, device number 5 ... [ 95.590421] usb 2-2: new SuperSpeed USB device number 6 using xhci_hcd This patch fixes that. Link: https://github.com/lwfinger/rtw88/issues/262 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/9d312b14-0146-4be8-9c50-ef432234db50@gmail.com
2025-01-12wifi: rtw89: 8922ae: add variant info to support RTL8922AE-VSPing-Ke Shih
RTL8922AE-VS is a variant of RTL8922AE, which is supported by firmware version after 0.35.54.0 and only can support up to MCS11. Add a variant struct to describe these requirements accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250108020955.14668-3-pkshih@realtek.com
2025-01-12wifi: rtw89: read hardware capabilities part 1 via firmware commandPing-Ke Shih
Firmware after version 0.35.51.0 defines and exports more hardware capabilities, which driver will consider reported QAM field as EHT MCS capability to register hardware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250108020955.14668-2-pkshih@realtek.com
2025-01-12wifi: rtw89: fix race between cancel_hw_scan and hw_scan completionPing-Ke Shih
The rtwdev->scanning flag isn't protected by mutex originally, so cancel_hw_scan can pass the condition, but suddenly hw_scan completion unset the flag and calls ieee80211_scan_completed() that will free local->hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex. KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211_conn_work [cfg80211] RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x61/0x73 ? __die_body+0x20/0x73 ? die_addr+0x4f/0x7b ? exc_general_protection+0x191/0x1db ? asm_exc_general_protection+0x27/0x30 ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core] ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core] ? do_raw_spin_lock+0x75/0xdb ? __pfx_do_raw_spin_lock+0x10/0x10 rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core] ? _raw_spin_unlock+0xe/0x24 ? __mutex_lock.constprop.0+0x40c/0x471 ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core] ? __mutex_lock_slowpath+0x13/0x1f ? mutex_lock+0xa2/0xdc ? __pfx_mutex_lock+0x10/0x10 rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core] rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core] ieee80211_scan_cancel+0x468/0x4d0 [mac80211] ieee80211_prep_connection+0x858/0x899 [mac80211] ieee80211_mgd_auth+0xbea/0xdde [mac80211] ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211] ? cfg80211_find_elem+0x15/0x29 [cfg80211] ? is_bss+0x1b7/0x1d7 [cfg80211] ieee80211_auth+0x18/0x27 [mac80211] cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211] cfg80211_conn_do_work+0x410/0xb81 [cfg80211] ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211] ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? __kasan_check_write+0x14/0x22 ? mutex_lock+0x8e/0xdc ? __pfx_mutex_lock+0x10/0x10 ? __pfx___radix_tree_lookup+0x10/0x10 cfg80211_conn_work+0x245/0x34d [cfg80211] ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211] ? update_cfs_rq_load_avg+0x3bc/0x3d7 ? sched_clock_noinstr+0x9/0x1a ? sched_clock+0x10/0x24 ? sched_clock_cpu+0x7e/0x42e ? newidle_balance+0x796/0x937 ? __pfx_sched_clock_cpu+0x10/0x10 ? __pfx_newidle_balance+0x10/0x10 ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? _raw_spin_unlock+0xe/0x24 ? raw_spin_rq_unlock+0x47/0x54 ? raw_spin_rq_unlock_irq+0x9/0x1f ? finish_task_switch.isra.0+0x347/0x586 ? __schedule+0x27bf/0x2892 ? mutex_unlock+0x80/0xd0 ? do_raw_spin_lock+0x75/0xdb ? __pfx___schedule+0x10/0x10 process_scheduled_works+0x58c/0x821 worker_thread+0x4c7/0x586 ? __kasan_check_read+0x11/0x1f kthread+0x285/0x294 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x6f ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 895907779752 ("rtw89: 8852a: add ieee80211_ops::hw_scan") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250107114254.6769-1-pkshih@realtek.com
2025-01-12wifi: rtw89: mcc: consider time limits not divisible by 1024Zong-Zhe Yang
For each MCC role, time limits, including max_tob_us, max_toa_us, and mac_dur_us, are calculated if there are NoA attributes. The relation between these time limits is "max_dur_us = max_tob_us + max_toa_us". Then, the unit is converted from us to TU. However, originally, each time limit was divided by 1024 independently. It missed to consider the cases that max_tob_us or max_toa_us is not divisible by 1024. It causes the result breaks "max_dur (TU) = max_tob (TU) + max_toa (TU)". Finally, when MCC calculates pattern parameters based on these kinds of time limits, it might not perform well. Fixes: b09df09b55fb ("wifi: rtw89: mcc: initialize start flow") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103074412.124066-1-pkshih@realtek.com
2025-01-12wifi: rtw89: pci: treat first receiving part as first segment for 8922AEPing-Ke Shih
For early chips, the RX BD info contains FS/LS bits for first/last segments of a receiving packet. For 8922AE, the FS bit should be ignored, or it may throw warning: rtw89_8922ae 0000:1a:00.0: skb should not be ready before first segment start To have compatible logic, FS determined by what pending skb is existing (!new) or not. Since we expect every single receiving packet in single one segment, enlarge 4 bytes for RX BD info, and add a debug message to note if RX buffer is possibly smaller than expected size. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103025126.15378-1-pkshih@realtek.com
2025-01-12wifi: rtw89: avoid to init mgnt_entry list twice when WoWLAN failedChih-Kang Chang
If WoWLAN failed in resume flow, the rtw89_ops_add_interface() triggered without removing the interface first. Then the mgnt_entry list init again, causing the list_empty() check in rtw89_chanctx_ops_assign_vif() useless, and list_add_tail() again. Therefore, we have added a check to prevent double adding of the list. rtw89_8852ce 0000:01:00.0: failed to check wow status disabled rtw89_8852ce 0000:01:00.0: wow: failed to check disable fw ready rtw89_8852ce 0000:01:00.0: wow: failed to swap to normal fw rtw89_8852ce 0000:01:00.0: failed to disable wow rtw89_8852ce 0000:01:00.0: failed to resume for wow -110 rtw89_8852ce 0000:01:00.0: MAC has already powered on i2c_hid_acpi i2c-ILTK0001:00: PM: acpi_subsys_resume+0x0/0x60 returned 0 after 284705 usecs list_add corruption. prev->next should be next (ffff9d9719d82228), but was ffff9d9719f96030. (prev=ffff9d9719f96030). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:34! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 6918 Comm: kworker/u8:19 Tainted: G U O Hardware name: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.514.0 03/25/2024 Workqueue: events_unbound async_run_entry_fn RIP: 0010:__list_add_valid_or_report+0x9f/0xb0 Code: e8 56 89 ff ff 0f 0b 48 c7 c7 3e fc e0 96 48 89 c6 e8 45 89 ff ... RSP: 0018:ffffa51b42bbbaf0 EFLAGS: 00010246 RAX: 0000000000000075 RBX: ffff9d9719d82ab0 RCX: 13acb86e047a4400 RDX: 3fffffffffffffff RSI: 0000000000000000 RDI: 00000000ffffdfff RBP: ffffa51b42bbbb28 R08: ffffffff9768e250 R09: 0000000000001fff R10: ffffffff9765e250 R11: 0000000000005ffd R12: ffff9d9719f95c40 R13: ffff9d9719f95be8 R14: ffff9d97081bfd78 R15: ffff9d9719d82060 FS: 0000000000000000(0000) GS:ffff9d9a6fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007e7d029a4060 CR3: 0000000345e38000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x68/0xb0 ? die+0xaa/0xd0 ? do_trap+0x9f/0x170 ? __list_add_valid_or_report+0x9f/0xb0 ? __list_add_valid_or_report+0x9f/0xb0 ? handle_invalid_op+0x69/0x90 ? __list_add_valid_or_report+0x9f/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x9f/0xb0 rtw89_chanctx_ops_assign_vif+0x1f9/0x210 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] ? __mutex_unlock_slowpath+0xa0/0xf0 rtw89_ops_assign_vif_chanctx+0x4b/0x90 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] drv_assign_vif_chanctx+0xa7/0x1f0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ieee80211_reconfig+0x9cb/0x17b0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? dev_printk_emit+0x51/0x70 ? _dev_info+0x6e/0x90 wiphy_resume+0x89/0x180 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] dpm_run_callback+0x37/0x1e0 device_resume+0x26d/0x4b0 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x29/0xd0 worker_thread+0x397/0x970 kthread+0xed/0x110 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces") Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250103024500.14990-1-pkshih@realtek.com
2025-01-12wifi: rtw89: correct header conversion rule for MLO onlyPo-Hao Huang
Header conversion should only be used with MLO connections. Otherwise P2P connection fails due to wrong probe responses sent. Fix it accordingly. Fixes: b8499664fca9 ("wifi: rtw89: Add header conversion for MLO connections") Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241231004811.8646-4-pkshih@realtek.com
2025-01-12wifi: rtw89: chan: fix soft lockup in rtw89_entity_recalc_mgnt_roles()Zong-Zhe Yang
During rtw89_entity_recalc_mgnt_roles(), there is a normalizing process which will re-order the list if an entry with target pattern is found. And once one is found, should have aborted the list_for_each_entry. But, `break` just aborted the inner for-loop. The outer list_for_each_entry still continues. Normally, only the first entry will match the target pattern, and the re-ordering will change nothing, so there won't be soft lockup. However, in some special cases, soft lockup would happen. Fix it by `goto fill` to break from the list_for_each_entry. The following is a sample of kernel log for this problem. watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [wpa_supplicant:2055] [...] RIP: 0010:rtw89_entity_recalc ([...] chan.c:392 chan.c:479) rtw89_core [...] Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241231004811.8646-3-pkshih@realtek.com
2025-01-12wifi: rtw89: fix proceeding MCC with wrong scanning state after sequence changesZong-Zhe Yang
When starting/proceeding MCC, it will abort an ongoing hw scan process. In the proceeding cases, it unexpectedly tries to abort a non-exist hw scan process. Then, a trace shown at the bottom will happen. This problem is caused by a previous commit which changed some call sequence inside rtw89_hw_scan_complete() to fix some coex problems. These changes lead to our scanning flag was not cleared when proceeding MCC. To keep the fixes on coex, and resolve the problem here, re-consider the related call sequence. The known sequence requirements are listed below. * the old sequence: A. notify coex B. clear scanning flag C. proceed chanctx C-1. set channel C-2. proceed MCC (the problem: A needs to be after C-1) * the current sequence: C. proceed chanctx C-1. set channel C-2. proceed MCC A. notify coex B. clear scanning flag (the problem: C-2 needs to be after B) So, now let hw scan caller pass a callback to proceed chanctx if needed. Then, the new sequence will be like the below. C-1. set channel A. notify coex B. clear scanning flag C-2. proceed MCC The following is the kernel log for the problem in current sequence. rtw89_8852be 0000:04:00.0: rtw89_hw_scan_offload failed ret -110 ------------[ cut here ]------------ [...] CPU: 2 PID: 3991 Comm: kworker/u16:0 Tainted: G OE 6.6.17 #3 Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 Workqueue: events_unbound wiphy_work_cancel [cfg80211] RIP: 0010:ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] Code: 9c 24 d0 11 00 00 49 39 dd 0f 85 46 ff ff ff 4c 89 e7 e8 09 2d RSP: 0018:ffffb27783643d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff8a2280964bc0 RSI: 0000000000000000 RDI: ffff8a23df580900 RBP: ffffb27783643d88 R08: 0000000000000001 R09: 0000000000000400 R10: 0000000000000000 R11: 0000000000008268 R12: ffff8a23df580900 R13: ffff8a23df581b00 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8a258e680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f26a0654000 CR3: 000000002ea2e002 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x68/0x70 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ? __warn+0x8f/0x150 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ? report_bug+0x1f5/0x200 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ieee80211_scan_work+0x14a/0x650 [mac80211] ? __queue_work+0x10f/0x410 wiphy_work_cancel+0x2fb/0x310 [cfg80211] process_scheduled_works+0x9d/0x390 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x15b/0x2d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x108/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Fixes: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241231004811.8646-2-pkshih@realtek.com
2025-01-11net: airoha: Fix channel configuration for ETS QdiscLorenzo Bianconi
Limit ETS QoS channel to AIROHA_NUM_QOS_CHANNELS in airoha_tc_setup_qdisc_ets() in order to align the configured channel to the value set in airoha_dev_select_queue(). Fixes: 20bf7d07c956 ("net: airoha: Add sched ETS offload support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250107-airoha-ets-fix-chan-v1-1-97f66ed3a068@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-11net: phy: dp83822: Add support for PHY LEDs on DP83822Dimitri Fedrau
The DP83822 supports up to three configurable Light Emitting Diode (LED) pins: LED_0, LED_1 (GPIO1), COL (GPIO2) and RX_D3 (GPIO3). Several functions can be multiplexed onto the LEDs for different modes of operation. LED_0 and COL (GPIO2) use the MLED function. MLED can be routed to only one of these two pins at a time. Add minimal LED controller driver supporting the most common uses with the 'netdev' trigger. Signed-off-by: Dimitri Fedrau <dima.fedrau@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250107-dp83822-leds-v2-1-5b260aad874f@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10Merge tag 'linux-can-next-for-6.14-20250110' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2025-01-10 Pierre-Henry Moussay adds PIC64GX compatibility to the DT bindings for Microchip's mpfs-can IP core. The next 3 patches are by Sean Nyekjaer and target the tcan4x5x driver. First the DT bindings is converted to DT schema, then nWKRQ voltage selection is added to the driver. Dario Binacchi's patch for the sun4i_can makes the driver more consistent by adding a likely() to the driver. Another patch by Sean Nyekjaer for the tcan4x5x driver gets rid of a false error message. Charan Pedumuru converts the atmel-can DT bindings to DT schema. The next 2 patches are by Oliver Hartkopp. The first one maps Oliver's former mail addresses to a dedicated CAN mail address. The second one assigns net/sched/em_canid.c additionally to the CAN maintainers. Ariel Otilibili's patch removes dead code from the CAN dev helper. The next 3 patches are by Sean Nyekjaer and add HW standby support to the tcan4x5x driver. A patch by Dario Binacchi fixes the DT bindings for the st,stm32-bxcan driver. The last 4 patches are by Jimmy Assarsson and target the kvaser_usb and the kvaser_pciefd driver: error statistics are improved and CAN_CTRLMODE_BERR_REPORTING is added. * tag 'linux-can-next-for-6.14-20250110' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: kvaser_pciefd: Add support for CAN_CTRLMODE_BERR_REPORTING can: kvaser_pciefd: Update stats and state even if alloc_can_err_skb() fails can: kvaser_usb: Add support for CAN_CTRLMODE_BERR_REPORTING can: kvaser_usb: Update stats and state even if alloc_can_err_skb() fails dt-bindings: can: st,stm32-bxcan: fix st,gcan property type can: m_can: call deinit/init callback when going into suspend/resume can: tcan4x5x: add deinit callback to set standby mode can: m_can: add deinit callback can: dev: can_get_state_str(): Remove dead code MAINTAINERS: assign em_canid.c additionally to CAN maintainers mailmap: add an entry for Oliver Hartkopp dt-bindings: net: can: atmel: Convert to json schema can: tcan4x5x: get rid of false clock errors can: sun4i_can: continue to use likely() to check skb can: tcan4x5x: add option for selecting nWKRQ voltage dt-bindings: can: tcan4x5x: Document the ti,nwkrq-voltage-vio option dt-bindings: can: convert tcan4x5x.txt to DT schema dt-bindings: can: mpfs: add PIC64GX CAN compatibility ==================== Link: https://patch.msgid.link/20250110112712.3214173-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: ethernet: ti: cpsw: fix the comment regarding VLAN-aware ALEAlexander Sverdlin
In all 3 cases (cpsw, cpsw-new, am65-cpsw) ALE is being configured in VLAN-aware mode, while the comment states the opposite. Seems to be a typo copy-pasted from one driver to another. Fix the commend which has been puzzling some people (including me) for at least a decade. Link: https://lore.kernel.org/linux-arm-kernel/4699400.vD3TdgH1nR@localhost/ Link: https://lore.kernel.org/netdev/0106ce78-c83f-4552-a234-1bf7a33f1ed1@kernel.org/ Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250109214219.123767-1-alexander.sverdlin@siemens.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: ravb: Fix max TX frame size for RZ/V2MPaul Barker
When tx_max_frame_size was added to struct ravb_hw_info, no value was set in ravb_rzv2m_hw_info so the default value of zero was used. The maximum MTU is set by subtracting from tx_max_frame_size to allow space for headers and frame checksums. As ndev->max_mtu is unsigned, this subtraction wraps around leading to a ridiculously large positive value that is obviously incorrect. Before tx_max_frame_size was introduced, the maximum MTU was based on rx_max_frame_size. So, we can restore the correct maximum MTU by copying the rx_max_frame_size value into tx_max_frame_size for RZ/V2M. Fixes: 1d63864299ca ("net: ravb: Fix maximum TX frame size for GbEth devices") Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://patch.msgid.link/20250109113706.1409149-1-paul.barker.ct@bp.renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: mana: Cleanup "mana" debugfs dir after cleanup of all childrenShradha Gupta
In mana_driver_exit(), mana_debugfs_root gets cleanup before any of it's children (which happens later in the pci_unregister_driver()). Due to this, when mana driver is configured as a module and rmmod is invoked, following stack gets printed along with failure in rmmod command. [ 2399.317651] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ 2399.318657] #PF: supervisor write access in kernel mode [ 2399.319057] #PF: error_code(0x0002) - not-present page [ 2399.319528] PGD 10eb68067 P4D 0 [ 2399.319914] Oops: Oops: 0002 [#1] SMP NOPTI [ 2399.320308] CPU: 72 UID: 0 PID: 5815 Comm: rmmod Not tainted 6.13.0-rc5+ #89 [ 2399.320986] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 [ 2399.321892] RIP: 0010:down_write+0x1a/0x50 [ 2399.322303] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 54 49 89 fc e8 9d cd ff ff 31 c0 ba 01 00 00 00 <f0> 49 0f b1 14 24 75 17 65 48 8b 05 f6 84 dd 5f 49 89 44 24 08 4c [ 2399.323669] RSP: 0018:ff53859d6c663a70 EFLAGS: 00010246 [ 2399.324061] RAX: 0000000000000000 RBX: ff1d4eb505060180 RCX: ffffff8100000000 [ 2399.324620] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098 [ 2399.325167] RBP: ff53859d6c663a78 R08: 00000000000009c4 R09: ff1d4eb4fac90000 [ 2399.325681] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000098 [ 2399.326185] R13: ff1d4e42e1a4a0c8 R14: ff1d4eb538ce0000 R15: 0000000000000098 [ 2399.326755] FS: 00007fe729570000(0000) GS:ff1d4eb2b7200000(0000) knlGS:0000000000000000 [ 2399.327269] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2399.327690] CR2: 0000000000000098 CR3: 00000001c0584005 CR4: 0000000000373ef0 [ 2399.328166] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2399.328623] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 2399.329055] Call Trace: [ 2399.329243] <TASK> [ 2399.329379] ? show_regs+0x69/0x80 [ 2399.329602] ? __die+0x25/0x70 [ 2399.329856] ? page_fault_oops+0x271/0x550 [ 2399.330088] ? psi_group_change+0x217/0x470 [ 2399.330341] ? do_user_addr_fault+0x455/0x7b0 [ 2399.330667] ? finish_task_switch.isra.0+0x91/0x2f0 [ 2399.331004] ? exc_page_fault+0x73/0x160 [ 2399.331275] ? asm_exc_page_fault+0x27/0x30 [ 2399.343324] ? down_write+0x1a/0x50 [ 2399.343631] simple_recursive_removal+0x4d/0x2c0 [ 2399.343977] ? __pfx_remove_one+0x10/0x10 [ 2399.344251] debugfs_remove+0x45/0x70 [ 2399.344511] mana_destroy_rxq+0x44/0x400 [mana] [ 2399.344845] mana_destroy_vport+0x54/0x1c0 [mana] [ 2399.345229] mana_detach+0x2f1/0x4e0 [mana] [ 2399.345466] ? ida_free+0x150/0x160 [ 2399.345718] ? __cond_resched+0x1a/0x50 [ 2399.345987] mana_remove+0xf4/0x1a0 [mana] [ 2399.346243] mana_gd_remove+0x25/0x80 [mana] [ 2399.346605] pci_device_remove+0x41/0xb0 [ 2399.346878] device_remove+0x46/0x70 [ 2399.347150] device_release_driver_internal+0x1e3/0x250 [ 2399.347831] ? klist_remove+0x81/0xe0 [ 2399.348377] driver_detach+0x4b/0xa0 [ 2399.348906] bus_remove_driver+0x83/0x100 [ 2399.349435] driver_unregister+0x31/0x60 [ 2399.349919] pci_unregister_driver+0x40/0x90 [ 2399.350492] mana_driver_exit+0x1c/0xb50 [mana] [ 2399.351102] __do_sys_delete_module.constprop.0+0x184/0x320 [ 2399.351664] ? __fput+0x1a9/0x2d0 [ 2399.352200] __x64_sys_delete_module+0x12/0x20 [ 2399.352760] x64_sys_call+0x1e66/0x2140 [ 2399.353316] do_syscall_64+0x79/0x150 [ 2399.353813] ? syscall_exit_to_user_mode+0x49/0x230 [ 2399.354346] ? do_syscall_64+0x85/0x150 [ 2399.354816] ? irqentry_exit+0x1d/0x30 [ 2399.355287] ? exc_page_fault+0x7f/0x160 [ 2399.355756] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 2399.356302] RIP: 0033:0x7fe728d26aeb [ 2399.356776] Code: 73 01 c3 48 8b 0d 45 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 15 33 0f 00 f7 d8 64 89 01 48 [ 2399.358372] RSP: 002b:00007ffff954d6f8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 2399.359066] RAX: ffffffffffffffda RBX: 00005609156cc760 RCX: 00007fe728d26aeb [ 2399.359779] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005609156cc7c8 [ 2399.360535] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 2399.361261] R10: 00007fe728dbeac0 R11: 0000000000000206 R12: 00007ffff954d950 [ 2399.361952] R13: 00005609156cc2a0 R14: 00007ffff954ee5f R15: 00005609156cc760 [ 2399.362688] </TASK> Fixes: 6607c17c6c5e ("net: mana: Enable debugfs files for MANA device") Cc: stable@vger.kernel.org Signed-off-by: Shradha Gupta <shradhagupta@linux.microsoft.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/1736398991-764-1-git-send-email-shradhagupta@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10ipvlan: Support bonding eventsEtienne Champetier
This allows ipvlan to function properly on top of bonds using active-backup mode. This was implemented for macvlan in 2014 in commit 4c9912556867 ("macvlan: Support bonding events"). Signed-off-by: Etienne Champetier <champetier.etienne@gmail.com> Link: https://patch.msgid.link/20250109032819.326528-2-champetier.etienne@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10eth: bnxt: always recalculate features after XDP clearing, fix null-derefJakub Kicinski
Recalculate features when XDP is detached. Before: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [requested on] After: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: on The fact that HW-GRO doesn't get re-enabled automatically is just a minor annoyance. The real issue is that the features will randomly come back during another reconfiguration which just happens to invoke netdev_update_features(). The driver doesn't handle reconfiguring two things at a time very robustly. Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") we only reconfigure the RSS hash table if the "effective" number of Rx rings has changed. If HW-GRO is enabled "effective" number of rings is 2x what user sees. So if we are in the bad state, with HW-GRO re-enablement "pending" after XDP off, and we lower the rings by / 2 - the HW-GRO rings doing 2x and the ethtool -L doing / 2 may cancel each other out, and the: if (old_rx_rings != bp->hw_resc.resv_rx_rings && condition in __bnxt_reserve_rings() will be false. The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0 As we try to access a freed ring. The issue is present since XDP support was added, really, but prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") it wasn't causing major issues. Fixes: 1054aee82321 ("bnxt_en: Use NETIF_F_GRO_HW.") Fixes: 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") Reviewed-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Link: https://patch.msgid.link/20250109043057.2888953-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: stmmac: remove stmmac_lpi_entry_timer_config()Russell King (Oracle)
Remove stmmac_lpi_entry_timer_config(), setting priv->eee_sw_timer_en at the original call sites, and calling the appropriate stmmac_xxx_hw_lpi_timer() function. No functional change. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tVZEq-0002LQ-PC@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: stmmac: split hardware LPI timer controlRussell King (Oracle)
Provide stmmac_disable_hw_lpi_timer() and stmmac_enable_hw_lpi_timer() to control the hardware transmit LPI timer. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tVZEl-0002LK-LA@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: stmmac: remove unnecessary EEE handling in stmmac_release()Russell King (Oracle)
phylink_stop() will cause phylink to call the mac_link_down() operation before phylink_stop() returns. As mac_link_down() will call stmmac_eee_init(false), this will set both priv->eee_active and priv->eee_enabled to be false, deleting the eee_ctrl_timer if priv->eee_enabled was previously set. As stmmac_release() calls phylink_stop() before checking whether priv->eee_enabled is true, this is a condition that can never be satisfied, and thus the code within this if() block will never be executed. Remove it. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tVZEg-0002LE-HH@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: stmmac: move setup of eee_ctrl_timer to stmmac_dvr_probe()Russell King (Oracle)
Move the initialisation of the EEE software timer to the probe function as it is unnecessary to do this each time we enable software LPI. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tVZEb-0002L8-DJ@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: stmmac: use boolean for eee_enabled and eee_activeRussell King (Oracle)
priv->eee_enabled and priv->eee_active are both assigned using boolean values. Type them as bool rather than int. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tVZEW-0002L2-9w@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: stmmac: move priv->eee_active into stmmac_eee_init()Russell King (Oracle)
Since all call sites of stmmac_eee_init() assign priv->eee_active immediately before, pass this state into stmmac_eee_init() and assign priv->eee_active within this function. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tVZER-0002Kv-5O@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: stmmac: move priv->eee_enabled into stmmac_eee_init()Russell King (Oracle)
All call sites for stmmac_eee_init() assign the return code to priv->eee_enabled. Rather than having this coded at each call site, move the assignment inside stmmac_eee_init(). Since stmmac_init_eee() takes priv->lock before checking the state of priv->eee_enabled, move the assignment within the locked region. Also, stmmac_suspend() checks the state of this member under the lock. While two concurrent calls to stmmac_init_eee() aren't possible, there is a possibility that stmmac_suspend() may run concurrently with a change of priv->eee_enabled unless we modify it under the lock. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tVZEM-0002Kq-2Z@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: stmmac: remove priv->eee_tw_timerRussell King (Oracle)
priv->eee_tw_timer is only assigned during initialisation to a constant value (STMMAC_DEFAULT_TWT_LS) and then never changed. Remove priv->eee_tw_timer, and instead use STMMAC_DEFAULT_TWT_LS for both uses in stmmac_eee_init(). Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tVZEG-0002Kk-VH@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: stmmac: convert to use phy_eee_rx_clock_stop()Russell King (Oracle)
Convert stmmac to use phy_eee_rx_clock_stop() to set the PHY receive clock stop in LPI setting, rather than calling the legacy phy_init_eee() function. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tVZEB-0002Ke-RZ@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-10net: stmmac: report EEE error statistics if EEE is supportedRussell King (Oracle)
Report the number of EEE error statistics in the xstats even when EEE is not enabled in hardware, but is supported. The PHY maintains this counter even when EEE is not enabled. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1tVZE6-0002KY-Nx@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-07-18 23:54:17 +0000