kernel/linux.git/drivers/net/wwan, branch v6.12.80

net: wwan: mhi: Add network support for Foxconn T99W760

2026-03-04T12:21:12+00:00

[ Upstream commit 915a5f60ad947e8dd515d2cc77a96a14dffb3f15 ] T99W760 is designed based on Qualcomm SDX35 chip. It use similar architecture with SDX72/SDX75 chip. So we need to assign initial link id for this device to make sure network available. Signed-off-by: Slark Xiao Link: https://patch.msgid.link/20260105022646.10630-1-slark_xiao@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: wwan: t7xx: fix potential skb->frags overflow in RX path

2026-02-06T15:55:41+00:00

[ Upstream commit f0813bcd2d9d97fdbdf2efb9532ab03ae92e99e6 ] When receiving data in the DPMAIF RX path, the t7xx_dpmaif_set_frag_to_skb() function adds page fragments to an skb without checking if the number of fragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow in skb_shinfo(skb)->frags[] array, corrupting adjacent memory and potentially causing kernel crashes or other undefined behavior. This issue was identified through static code analysis by comparing with a similar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76: fix array overflow on receiving too many fragments for a packet"). The vulnerability could be triggered if the modem firmware sends packets with excessive fragments. While under normal protocol conditions (MTU 3080 bytes, BAT buffer 3584 bytes), a single packet should not require additional fragments, the kernel should not blindly trust firmware behavior. Malicious, buggy, or compromised firmware could potentially craft packets with more fragments than the kernel expects. Fix this by adding a bounds check before calling skb_add_rx_frag() to ensure nr_frags does not exceed MAX_SKB_FRAGS. The check must be performed before unmapping to avoid a page leak and double DMA unmap during device teardown. Fixes: d642b012df70a ("net: wwan: t7xx: Add data path interface") Signed-off-by: Kery Qi Link: https://patch.msgid.link/20260122170401.1986-2-qikeyu2017@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: wwan: iosm: Fix memory leak in ipc_mux_deinit()

2026-01-17T15:31:23+00:00

[ Upstream commit 92e6e0a87f6860a4710f9494f8c704d498ae60f8 ] Commit 1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support") allocated memory for pp_qlt in ipc_mux_init() but did not free it in ipc_mux_deinit(). This results in a memory leak when the driver is unloaded. Free the allocated memory in ipc_mux_deinit() to fix the leak. Fixes: 1f52d7b62285 ("net: wwan: iosm: Enable M.2 7360 WWAN card support") Co-developed-by: Jianhao Xu Signed-off-by: Jianhao Xu Signed-off-by: Zilin Guan Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20251230071853.1062223-1-zilin@seu.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: wwan: mhi: Keep modem name match with Foxconn T99W640

2025-12-06T21:24:55+00:00

[ Upstream commit 4fcb8ab4a09b1855dbfd7062605dd13abd64c086 ] Correct it since M.2 device T99W640 has updated from T99W515. We need to align it with MHI side otherwise this modem can't get the network. Fixes: ae5a34264354 ("bus: mhi: host: pci_generic: Fix the modem name of Foxconn T99W640") Signed-off-by: Slark Xiao Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20251125070900.33324-1-slark_xiao@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: wwan: t7xx: add support for HP DRMR-H01

2025-11-13T20:34:35+00:00

[ Upstream commit 370e98728bda92b1bdffb448d1acdcbe19dadb4c ] add support for HP DRMR-H01 (0x03f0, 0x09c8) Signed-off-by: Sammy Hsu Link: https://patch.msgid.link/20251002024841.5979-1-sammy.hsu@wnc.com.tw Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: wwan: mhi_wwan_mbim: use correct mux_id for multiplexing

2025-06-19T13:32:19+00:00

[ Upstream commit 501fe52aa908c96f2c9b8d54767938a1a5960354 ] Recent Qualcomm chipsets like SDX72/75 require MBIM sessionId mapping to muxId in the range (0x70-0x8F) for the PCIe tethered use. This has been partially addressed by the referenced commit, mapping the default data call to muxId = 112, but the multiplexed data calls scenario was not properly considered, mapping sessionId = 1 to muxId 1, while it should have been 113. Fix this by moving the session_id assignment logic to mhi_mbim_newlink, in order to map sessionId = n to muxId = n + WDS_BIND_MUX_DATA_PORT_MUX_ID. Fixes: 65bc58c3dcad ("net: wwan: mhi: make default data link id configurable") Signed-off-by: Daniele Palmas Reviewed-by: Loic Poulain Link: https://patch.msgid.link/20250603091204.2802840-1-dnlplm@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

net: wwan: t7xx: Fix napi rx poll issue

2025-06-19T13:32:17+00:00

[ Upstream commit 905fe0845bb27e4eed2ca27ea06e6c4847f1b2b1 ] When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic. BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:dev_gro_receive+0x3a/0x620 [...] Call Trace: ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)] ? dev_gro_receive+0x3a/0x620 napi_gro_receive+0xad/0x170 t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)] t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)] net_rx_action+0x103/0x470 irq_exit_rcu+0x13a/0x310 sysvec_apic_timer_interrupt+0x56/0x90 Fixes: 5545b7b9f294 ("net: wwan: t7xx: Add NAPI support") Signed-off-by: Jinjian Song Link: https://patch.msgid.link/20250530031648.5592-1-jinjian.song@fibocom.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

net: wwan: mhi_wwan_mbim: Silence sequence number glitch errors

2025-03-22T19:54:19+00:00

[ Upstream commit 0d1fac6d26aff5df21bb4ec980d9b7a11c410b96 ] When using the Qualcomm X55 modem on the ThinkPad X13s, the kernel log is constantly being filled with errors related to a "sequence number glitch", e.g.: [ 1903.284538] sequence number glitch prev=16 curr=0 [ 1913.812205] sequence number glitch prev=50 curr=0 [ 1923.698219] sequence number glitch prev=142 curr=0 [ 2029.248276] sequence number glitch prev=1555 curr=0 [ 2046.333059] sequence number glitch prev=70 curr=0 [ 2076.520067] sequence number glitch prev=272 curr=0 [ 2158.704202] sequence number glitch prev=2655 curr=0 [ 2218.530776] sequence number glitch prev=2349 curr=0 [ 2225.579092] sequence number glitch prev=6 curr=0 Internet connectivity is working fine, so this error seems harmless. It looks like modem does not preserve the sequence number when entering low power state; the amount of errors depends on how actively the modem is being used. A similar issue has also been seen on USB-based MBIM modems [1]. However, in cdc_ncm.c the "sequence number glitch" message is a debug message instead of an error. Apply the same to the mhi_wwan_mbim.c driver to silence these errors when using the modem. [1]: https://lists.freedesktop.org/archives/libmbim-devel/2016-November/000781.html Signed-off-by: Stephan Gerhold Reviewed-by: Loic Poulain Acked-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20250212-mhi-wwan-mbim-sequence-glitch-v1-1-503735977cbd@linaro.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: wwan: iosm: Fix hibernation by re-binding the driver around it

2025-02-17T09:04:53+00:00

[ Upstream commit 0b6f6593aa8c3a05f155c12fd0e7ad33a5149c31 ] Currently, the driver is seriously broken with respect to the hibernation (S4): after image restore the device is back into IPC_MEM_EXEC_STAGE_BOOT (which AFAIK means bootloader stage) and needs full re-launch of the rest of its firmware, but the driver restore handler treats the device as merely sleeping and just sends it a wake-up command. This wake-up command times out but device nodes (/dev/wwan*) remain accessible. However attempting to use them causes the bootloader to crash and enter IPC_MEM_EXEC_STAGE_CD_READY stage (which apparently means "a crash dump is ready"). It seems that the device cannot be re-initialized from this crashed stage without toggling some reset pin (on my test platform that's apparently what the device _RST ACPI method does). While it would theoretically be possible to rewrite the driver to tear down the whole MUX / IPC layers on hibernation (so the bootloader does not crash from improper access) and then re-launch the device on restore this would require significant refactoring of the driver (believe me, I've tried), since there are quite a few assumptions hard-coded in the driver about the device never being partially de-initialized (like channels other than devlink cannot be closed, for example). Probably this would also need some programming guide for this hardware. Considering that the driver seems orphaned [1] and other people are hitting this issue too [2] fix it by simply unbinding the PCI driver before hibernation and re-binding it after restore, much like USB_QUIRK_RESET_RESUME does for USB devices that exhibit a similar problem. Tested on XMM7360 in HP EliteBook 855 G7 both with s2idle (which uses the existing suspend / resume handlers) and S4 (which uses the new code). [1]: https://lore.kernel.org/all/c248f0b4-2114-4c61-905f-466a786bdebb@leemhuis.info/ [2]: https://github.com/xmm7360/xmm7360-pci/issues/211#issuecomment-1804139413 Reviewed-by: Sergey Ryazanov Signed-off-by: Maciej S. Szmigiero Link: https://patch.msgid.link/e60287ebdb0ab54c4075071b72568a40a75d0205.1736372610.git.mail@maciej.szmigiero.name Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: wwan: iosm: Properly check for valid exec stage in ipc_mmio_init()

2025-01-09T12:33:42+00:00

[ Upstream commit a7af435df0e04cfb4a4004136d597c42639a2ae7 ] ipc_mmio_init() used the post-decrement operator in its loop continuing condition of "retries" counter being "> 0", which meant that when this condition caused loop exit "retries" counter reached -1. But the later valid exec stage failure check only tests for "retries" counter being exactly zero, so it didn't trigger in this case (but would wrongly trigger if the code reaches a valid exec stage in the very last loop iteration). Fix this by using the pre-decrement operator instead, so the loop counter is exactly zero on valid exec stage failure. Fixes: dc0514f5d828 ("net: iosm: mmio scratchpad") Signed-off-by: Maciej S. Szmigiero Link: https://patch.msgid.link/8b19125a825f9dcdd81c667c1e5c48ba28d505a6.1735490770.git.mail@maciej.szmigiero.name Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin