summaryrefslogtreecommitdiffhomepage
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-04-14Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netdeveldavem/net-nextJakub Kicinski28-97/+365
Merge in late fixes in preparation for the net-next PR. Conflicts: include/net/sch_generic.h a6bd339dbb351 ("net_sched: fix skb memory leak in deferred qdisc drops") ff2998f29f390 ("net: sched: introduce qdisc-specific drop reason tracing") https://lore.kernel.org/adz0iX85FHMz0HdO@sirena.org.uk drivers/net/ethernet/airoha/airoha_eth.c 1acdfbdb516b ("net: airoha: Fix VIP configuration for AN7583 SoC") bf3471e6e6c0 ("net: airoha: Make flow control source port mapping dependent on nbq parameter") Adjacent changes: drivers/net/ethernet/airoha/airoha_ppe.c f44218cd5e6a ("net: airoha: Reset PPE cpu port configuration in airoha_ppe_hw_init()") 7da62262ec96 ("inet: add ip_local_port_step_width sysctl to improve port usage distribution") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-14net: pse-pd: fix kernel-doc function name for pse_control_find_by_id()Kory Maincent1-1/+1
The kernel-doc comment header incorrectly referenced the function name pse_control_find_net_by_id() instead of the actual function name pse_control_find_by_id(). Correct the function name in the documentation to match the implementation. Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260414150948.744618-1-kory.maincent@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-14wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in ↵Shardul Bankar1-5/+3
pre_exit wg_netns_pre_exit() manually acquires rtnl_lock() inside the pernet .pre_exit callback. This causes a hung task when another thread holds rtnl_mutex - the cleanup_net workqueue (or the setup_net failure rollback path) blocks indefinitely in wg_netns_pre_exit() waiting to acquire the lock. Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net: Add ->exit_rtnl() hook to struct pernet_operations."), where the framework already holds RTNL and batches all callbacks under a single rtnl_lock()/rtnl_unlock() pair, eliminating the contention window. The rcu_assign_pointer(wg->creating_net, NULL) is safe to move from .pre_exit to .exit_rtnl (which runs after synchronize_rcu()) because all RCU readers of creating_net either use maybe_get_net() - which returns NULL for a dying namespace with zero refcount - or access net->user_ns which remains valid throughout the entire ops_undo_list sequence. Reported-by: syzbot+f2fbf7478a35a94c8b7c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?id=cb64c22a492202ca929e18262fdb8cb89e635c70 Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com> [ Jason: added __net_exit and __read_mostly annotations that were missing. ] Fixes: 900575aa33a3 ("wireguard: device: avoid circular netns references") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20260414153944.2742252-5-Jason@zx2c4.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-14wireguard: allowedips: remove redundant spaceJason A. Donenfeld1-1/+1
Not a contentful commit, but amusingly found when porting ba3d7b93 to Windows. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20260414153944.2742252-4-Jason@zx2c4.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-14wireguard: allowedips: Use kfree_rcu() instead of call_rcu()Fushuai Wang1-7/+2
Replace call_rcu() + kmem_cache_free() with kfree_rcu() to simplify the code and reduce function size. Signed-off-by: Fushuai Wang <wangfushuai@baidu.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20260414153944.2742252-2-Jason@zx2c4.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-14net: airoha: Add missing PPE configurations in airoha_ppe_hw_init()Lorenzo Bianconi1-3/+11
Add the following PPE configuration in airoha_ppe_hw_init routine: - 6RD hw offloading is currently not supported by Netfilter flowtable. Disable explicitly PPE 6RD offloading in order to prevent PPE to learn 6RD flows and eventually interrupt the traffic. - Add missing PPE bind rate configuration for L3 and L2 traffic. PPE bind rate configuration specifies the pps threshold to move a PPE entry state from UNBIND to BIND. Without this configuration this value is random. - Set ageing thresholds to the values used in the vendor SDK in order to improve connection stability under load and avoid packet loss caused by fast aging. Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260412-airoha_ppe_hw_init-missing-bits-v1-1-06ac670819e3@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-14net: airoha: Fix VIP configuration for AN7583 SoCLorenzo Bianconi2-17/+51
EN7581 and AN7583 SoCs have different VIP definitions. Introduce get_vip_port callback in airoha_eth_soc_data struct in order to take into account EN7581 and AN7583 VIP register layout and definition differences. Introduce nbq parameter in airoha_gdm_port struct. At the moment nbq is set statically to value previously used in airhoha_set_gdm2_loopback routine and it will be read from device tree in subsequent patches. Fixes: e4e5ce823bdd ("net: airoha: Add AN7583 SoC support") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260412-airoha-7583-vip-fix-v1-1-c35e02b054bb@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-14net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()Greg Kroah-Hartman1-1/+6
A malicious USB device claiming to be a CDC Phonet modem can overflow the skb_shared_info->frags[] array by sending an unbounded sequence of full-page bulk transfers. Drop the skb and increment the length error when the frag limit is reached. This matches the same fix that commit f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path") did for the t7xx driver. Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: stable <stable@kernel.org> Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2026041134-dreamboat-buddhism-d1ec@gregkh Fixes: 87cf65601e17 ("USB host CDC Phonet network interface driver") Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: airoha: Remove PCE_MC_EN_MASK bit in REG_FE_PCE_CFG configurationLorenzo Bianconi1-3/+2
PCE_MC_EN_MASK bit in REG_FE_PCE_CFG configuration performed in airoha_fe_init() is used to duplicate multicast packets and send a copy to the CPU when the traffic is offloaded. This is necessary just if it is requested by the user. Disable multicast packets duplication by default. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260412-airoha_fe_init_remove_mc_en_bit-v1-1-7b6a5a25a74d@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13net: airoha: Rely on net_device pointer in ETS callbacksLorenzo Bianconi1-16/+14
Remove airoha_gdm_port dependency in ETS tc callback signatures and rely on net_device pointer instead. Please note this patch does not introduce any logical change and it is a preliminary patch in order to support multiple net_devices connected to the same GDM3 or GDM4 port via an external hw arbiter. Tested-by: Xuegang Lu <xuegang.lu@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260412-airoha-multi-serdes-preliminary-patch-v1-3-08d5b670ca8f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13net: airoha: Rely on net_device pointer in HTB callbacksLorenzo Bianconi1-21/+24
Remove airoha_gdm_port dependency in HTB tc callback signatures and rely on net_device pointer instead. Please note this patch does not introduce any logical change and it is a preliminary patch in order to support multiple net_devices connected to the same GDM3 or GDM4 port via an external hw arbiter. Tested-by: Xuegang Lu <xuegang.lu@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260412-airoha-multi-serdes-preliminary-patch-v1-2-08d5b670ca8f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13net: airoha: Rely on net_device pointer in airoha_dev_setup_tc_block signatureLorenzo Bianconi1-5/+5
Remove airoha_gdm_port dependency in airoha_dev_setup_tc_block routine signature and rely on net_device pointer instead. Please note this patch does not introduce any logical change and it is a preliminary patch to support multiple net_devices connected to the GDM3 or GDM4 ports via an external hw arbiter. Tested-by: Xuegang Lu <xuegang.lu@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260412-airoha-multi-serdes-preliminary-patch-v1-1-08d5b670ca8f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13net: dsa: mxl862xx: implement .get_stats64Daniel Golle3-7/+270
Poll free-running firmware RMON counters every 2 seconds and accumulate deltas into 64-bit per-port statistics. 32-bit packet counters wrap in ~220s at 10 Gbps line rate with minimum-size frames; the 2s polling interval provides a comfortable margin. The .get_stats64 callback forces a fresh poll so that counters are always up to date when queried. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/fa38548ba05866879e8912721edc91947ce4ff12.1775951347.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13net: dsa: mxl862xx: add ethtool statistics supportDaniel Golle3-0/+318
The MxL862xx firmware exposes per-port RMON counters through the RMON_PORT_GET command, covering standard IEEE 802.3 MAC statistics (unicast/multicast/broadcast packet and byte counts, collision counters, pause frames) as well as hardware-specific counters such as extended VLAN discard and MTU exceed events. Add the RMON counter firmware API structures and command definitions. Implement .get_strings, .get_sset_count, and .get_ethtool_stats for legacy ethtool -S support. Implement .get_eth_mac_stats, .get_eth_ctrl_stats, and .get_pause_stats for the standardized IEEE 802.3 statistics interface. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/480be14d5ed51f3db7b1681b298044dbf8e87494.1775951347.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13net: phy: realtek: use LEDCR page number define on RTL8211FAleksander Jan Bajkowski1-2/+3
Replace the magic number with an existing define for the LEDCR register page number on the RTL8211F. Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/20260411105150.184577-1-olek2@wp.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13bnge: return after auxiliary_device_uninit() in error pathGreg Kroah-Hartman1-0/+1
When auxiliary_device_add() fails, the error block calls auxiliary_device_uninit() but does not return. The uninit drops the last reference and synchronously runs bnge_aux_dev_release(), which sets bd->auxr_dev = NULL and frees the underlying object. The subsequent bd->auxr_dev->net = bd->netdev then dereferences NULL, which is not a good thing to have happen when trying to clean up from an error. Add the missing return, as the auxiliary bus documentation states is a requirement (seems that LLM tools read documentation better than humans do...) Cc: Vikas Gupta <vikas.gupta@broadcom.com> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Fixes: 8ac050ec3b1c ("bng_en: Add RoCE aux device support") Cc: stable <stable@kernel.org> Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2026041124-banshee-molecular-0f70@gregkh Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13octeon_ep_vf: add NULL check for napi_build_skb()David Carlier1-2/+28
napi_build_skb() can return NULL on allocation failure. In __octep_vf_oq_process_rx(), the result is used directly without a NULL check in both the single-buffer and multi-fragment paths, leading to a NULL pointer dereference. Add NULL checks after both napi_build_skb() calls, properly advancing descriptors and consuming remaining fragments on failure. Fixes: 1cd3b407977c ("octeon_ep_vf: add Tx/Rx processing and interrupt support") Cc: stable@vger.kernel.org Signed-off-by: David Carlier <devnexen@gmail.com> Link: https://patch.msgid.link/20260409184009.930359-3-devnexen@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13octeon_ep_vf: introduce octep_vf_oq_next_idx() helperDavid Carlier1-9/+8
Introduce octep_vf_oq_next_idx() to consolidate the repeated ring index advance and wraparound pattern in __octep_vf_oq_process_rx(). No functional change intended. Signed-off-by: David Carlier <devnexen@gmail.com> Link: https://patch.msgid.link/20260409184009.930359-2-devnexen@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13net: phy: qcom: at803x: Use the correct bit to disable extended next pageMaxime Chevallier1-1/+1
As noted in the blamed commit, the AR8035 and other PHYs from this family advertise the Extended Next Page support by default, which may be understood by some partners as this PHY being multi-gig capable. The fix is to disable XNP advertising, which is done by setting bit 12 of the Auto-Negotiation Advertisement Register (MII_ADVERTISE). The blamed commit incorrectly uses MDIO_AN_CTRL1_XNP, which is bit 13 as per 802.3 : 45.2.7.1 AN control register (Register 7.0) BIT 12 in MII_ADVERTISE is wrapped by ADVERTISE_RESV, used by some drivers such as the aquantia one. 802.3 Clause 28 defines bit 12 as Extended Next Page ability, at least in recent versions of the standard. Let's add a define for it and use it in the at803x driver. Fixes: 3c51fa5d2afe ("net: phy: ar803x: disable extended next page bit") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260410171021.1277138-1-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13net: stmmac: enable RPS and RBU interruptsRussell King (Oracle)1-0/+6
Enable receive process stopped and receive buffer unavailable interrupts, so that the statistic counters can be updated. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1wBBaR-0000000GZHR-1dbM@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13Merge tag 'for-net-next-2026-04-13' of ↵Jakub Kicinski13-224/+427
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Luiz Augusto von Dentz says: ==================== bluetooth-next pull request for net-next: core: - hci_core: Rate limit the logging of invalid ISO handle - hci_sync: make hci_cmd_sync_run_once return -EEXIST if exists - hci_event: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER - hci_event: fix potential UAF in SSP passkey handlers - HCI: Avoid a couple -Wflex-array-member-not-at-end warnings - L2CAP: CoC: Disconnect if received packet size exceeds MPS - L2CAP: Add missing chan lock in l2cap_ecred_reconf_rsp - L2CAP: Fix printing wrong information if SDU length exceeds MTU - SCO: check for codecs->num_codecs == 1 before assigning to sco_pi(sk)->codec drivers: - btusb: MT7922: Add VID/PID 0489/e174 - btusb: Add Lite-On 04ca:3807 for MediaTek MT7921 - btusb: Add MT7927 IDs ASUS ROG Crosshair X870E Hero, Lenovo Legion Pro 7 16ARX9, Gigabyte Z790 AORUS MASTER X, MSI X870E Ace Max, TP-Link Archer TBE550E, ASUS X870E / ProArt X870E-Creator. - btusb: Add MT7902 IDs 13d3/3579, 13d3/3580, 13d3/3594, 13d3/3596, 0e8d/1ede - btusb: Add MT7902 IDs 13d3/3579, 13d3/3580, 13d3/3594, 13d3/3596, 0e8d/1ede - btusb: MediaTek MT7922: Add VID 0489 & PID e11d - btintel: Add support for Scorpious Peak2 support - btintel: Add support for Scorpious Peak2F support - btintel_pcie: Add device id of Scorpius Peak2, Nova Lake-PCD-H - btintel_pcie: Add device id of Scorpious2, Nova Lake-PCD-S - btmtk: Add reset mechanism if downloading firmware failed - btmtk: Add MT6639 (MT7927) Bluetooth support - btmtk: fix ISO interface setup for single alt setting - btmtk: add MT7902 SDIO support - Bluetooth: btmtk: add MT7902 MCU support - btbcm: Add entry for BCM4343A2 UART Bluetooth - qca: enable pwrseq support for wcn39xx devices - hci_qca: Fix BT not getting powered-off on rmmod - hci_qca: disable power control for WCN7850 when bt_en is not defined - hci_qca: Fix missing wakeup during SSR memdump handling - hci_ldisc: Clear HCI_UART_PROTO_INIT on error - mmc: sdio: add MediaTek MT7902 SDIO device ID - hci_ll: Enable BROKEN_ENHANCED_SETUP_SYNC_CONN for WL183x * tag 'for-net-next-2026-04-13' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next: (59 commits) Bluetooth: hci_qca: Fix missing wakeup during SSR memdump handling Bluetooth: btintel_pcie: use strscpy to copy plain strings Bluetooth: hci_event: fix potential UAF in SSP passkey handlers Bluetooth: hci.h: Avoid a couple -Wflex-array-member-not-at-end warnings Bluetooth: SCO: check for codecs->num_codecs == 1 before assigning to sco_pi(sk)->codec Bluetooth: btintel_pcie: Align shared DMA memory to 128 bytes Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp Bluetooth: hci_ll: Enable BROKEN_ENHANCED_SETUP_SYNC_CONN for WL183x Bluetooth: btusb: MediaTek MT7922: Add VID 0489 & PID e11d Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-Creator Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550E Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace Max Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER X Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9 Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E Hero Bluetooth: btmtk: fix ISO interface setup for single alt setting Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER Bluetooth: btmtk: refactor endpoint lookup ... ==================== Link: https://patch.msgid.link/20260413132247.320961-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13mlx4: correct error reporting in mlx4_master_process_vhcr()Alok Tiwari1-2/+2
mlx4_master_process_vhcr() logs vhcr->errno on failures, but this field is never populated by the PF path. As a result, all failures are reported with errno 0 and err print in status case which is misleading. Use the actual return value (err) instead, translate it to FW status before logging, and report both values. Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260409092754.508880-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-13Bluetooth: hci_qca: Fix missing wakeup during SSR memdump handlingShuai Zhang1-2/+2
When a Bluetooth controller encounters a coredump, it triggers the Subsystem Restart (SSR) mechanism. The controller first reports the coredump data and, once the upload is complete, sends a hw_error event. The host relies on this event to proceed with subsequent recovery actions. If the host has not finished processing the coredump data when the hw_error event is received, it waits until either the processing is complete or the 8-second timeout expires before handling the event. The current implementation clears QCA_MEMDUMP_COLLECTION using clear_bit(), which does not wake up waiters sleeping in wait_on_bit_timeout(). As a result, the waiting thread may remain blocked until the timeout expires even if the coredump collection has already completed. Fix this by clearing QCA_MEMDUMP_COLLECTION with clear_and_wake_up_bit(), which also wakes up the waiting thread and allows the hw_error handling to proceed immediately. Test case: - Trigger a controller coredump using: hcitool cmd 0x3f 0c 26 - Tested on QCA6390. - Capture HCI logs using btmon. - Verify that the delay between receiving the hw_error event and initiating the power-off sequence is reduced compared to the timeout-based behavior. Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btintel_pcie: use strscpy to copy plain stringsThorsten Blum1-2/+2
Use strscpy() instead of snprintf() to copy plain strings with no format specifiers. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btintel_pcie: Align shared DMA memory to 128 bytesKiran K2-44/+53
Align each descriptor/index/context region to 128 bytes before calculating the total DMA pool size. This ensures the memory layout shared with firmware meets the 128-byte alignment requirement. The DMA pool alignment is also set to 128 bytes to match the firmware expectation for all shared structures. Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: hci_ll: Enable BROKEN_ENHANCED_SETUP_SYNC_CONN for WL183xStefano Radaelli1-0/+10
TI WL183x controllers advertise support for the HCI Enhanced Setup Synchronous Connection command, but SCO setup fails when the enhanced path is used. The only working configuration is to fall back to the legacy HCI Setup Synchronous Connection (0x0028). This matches the scenario described in commit 05abad857277 ("Bluetooth: HCI: Add HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN quirk"). Enable HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN automatically for devices compatible with: - ti,wl1831-st - ti,wl1835-st - ti,wl1837-st Signed-off-by: Stefano Radaelli <stefano.r@variscite.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: MediaTek MT7922: Add VID 0489 & PID e11dKamiyama Chiaki1-0/+2
Add VID 0489 & PID e11d for MediaTek MT7922 USB Bluetooth chip. Found in Dynabook GA/ZY (W6GAZY5RCL). The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=03 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e11d Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Kamiyama Chiaki <nercone@nercone.dev> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] arrayArnd Bergmann1-16/+16
When USB support is disabled, the array is not referenced anywhere, causing a warning: drivers/bluetooth/btmtk.c:35:3: error: 'btmtk_mt6639_devs' defined but not used [-Werror=unused-const-variable=] 35 | } btmtk_mt6639_devs[] = { | ^~~~~~~~~~~~~~~~~ Move it into the #ifdef block. Fixes: 28b7c5a6db74 ("Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for ASUS X870E / ProArt X870E-CreatorJavier Tia1-0/+2
Add USB device ID 13d3:3588 (IMC Networks/Azurewave) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the ASUS ROG STRIX X870E-E GAMING WIFI and ASUS ProArt X870E-Creator WiFi motherboards. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3588 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io> Tested-by: Ivan Lubnin <lubnin.ivan@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for TP-Link Archer TBE550EJavier Tia1-0/+2
Add USB device ID 0489:e116 (Foxconn/Hon Hai) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the TP-Link Archer TBE550E PCIe adapter. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e116 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb ... I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Thibaut FRANCOIS <tibo@humeurlibre.fr> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for MSI X870E Ace MaxJavier Tia1-0/+2
Add USB device ID 0489:e110 (Foxconn/Hon Hai) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the MSI X870E Ace Max motherboard. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e110 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb ... I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Nitin Gurram <nitin.reddy88@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for Gigabyte Z790 AORUS MASTER XJavier Tia1-0/+2
Add USB device ID 0489:e10f (Foxconn/Hon Hai) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the Gigabyte Z790 AORUS MASTER X motherboard. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e10f Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb ... I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for Lenovo Legion Pro 7 16ARX9Javier Tia1-0/+2
Add USB device ID 0489:e0fa (Foxconn/Hon Hai) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the Lenovo Legion Pro 7 16ARX9 laptop. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e0fa Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb ... I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Llewellyn Curran <melinko2003@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: Add MT7927 ID for ASUS ROG Crosshair X870E HeroJavier Tia1-0/+2
Add USB device ID 0489:e13a (Foxconn/Hon Hai) for the MediaTek MT7927 (Filogic 380) Bluetooth interface found on the ASUS ROG Crosshair X870E Hero WiFi motherboard. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below. T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e13a Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb ... I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Signed-off-by: Javier Tia <floss@jetm.me> Tested-by: Jose Tiburcio Ribeiro Netto <jnetto@mineiro.io> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btmtk: fix ISO interface setup for single alt settingJavier Tia1-1/+2
Some MT6639 Bluetooth USB interfaces (e.g. IMC Networks 13d3:3588 on ASUS ROG STRIX X870E-E and ProArt X870E-Creator boards) expose only a single alternate setting (alt 0) on the ISO interface. The driver unconditionally requests alt setting 1, which fails with EINVAL on these devices, causing a ~20 second initialization delay and no LE audio support. Check the number of available alternate settings before selecting one. If only alt 0 exists, use it; otherwise request alt 1 as before. Closes: https://github.com/jetm/mediatek-mt7927-dkms/pull/39 Signed-off-by: Javier Tia <floss@jetm.me> Reported-by: Ryan Gilbert <xelnaga@gmail.com> Tested-by: Ryan Gilbert <xelnaga@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth supportJavier Tia3-8/+61
The MediaTek MT7927 (Filogic 380) combo WiFi 7 + BT 5.4 module uses hardware variant 0x6639 for its Bluetooth subsystem. Without this patch, the chip fails with "Unsupported hardware variant (00006639)" or hangs during firmware download. Three changes are needed to support MT6639: 1. CHIPID workaround: On some boards the BT USB MMIO register reads 0x0000 for dev_id, causing the driver to skip the 0x6639 init path. Force dev_id to 0x6639 only when the USB VID/PID matches a known MT6639 device, avoiding misdetection if a future chip also reads zero. This follows the WiFi-side pattern that uses PCI device IDs to scope the same workaround. 2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of "1_1" used by MT7925 and other variants. The firmware path is mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927 directory to match the WiFi firmware convention. The filename will likely change to use MT7927 once MediaTek submits a dedicated Linux firmware binary. 3. Section filtering: The MT6639 firmware binary contains 9 sections, but only sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related. Sending the remaining WiFi/other sections causes an irreversible BT subsystem hang requiring a full power cycle. This matches the Windows driver behavior observed via USB captures. Also add 0x6639 to the reset register (CONNV3) and firmware setup switch cases alongside the existing 0x7925 handling. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Reported-by: Ryan Gilbert <xelnaga@gmail.com> Signed-off-by: Javier Tia <floss@jetm.me> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btmtk: refactor endpoint lookupJohan Hovold1-24/+5
Use the common USB helper for looking up bulk and interrupt endpoints instead of open coding. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: btusb: refactor endpoint lookupJohan Hovold1-43/+8
Use the common USB helper for looking up bulk and interrupt endpoints instead of open coding. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on errorJonathan Rissanen1-0/+3
When hci_register_dev() fails in hci_uart_register_dev() HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu) and setting hu->hdev to NULL. This means incoming UART data will reach the protocol-specific recv handler in hci_uart_tty_receive() after resources are freed. Clear HCI_UART_PROTO_INIT with a write lock before calling hu->proto->close() and setting hu->hdev to NULL. The write lock ensures all active readers have completed and no new reader can enter the protocol recv path before resources are freed. This allows the protocol-specific recv functions to remove the "HCI_UART_REGISTERED" guard without risking a null pointer dereference if hci_register_dev() fails. Fixes: 5df5dafc171b ("Bluetooth: hci_uart: Fix another race during initialization") Signed-off-by: Jonathan Rissanen <jonathan.rissanen@axis.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13Bluetooth: hci_qca: disable power control for WCN7850 when bt_en is not definedShuai Zhang1-1/+2
On platforms using an M.2 slot with both UART and USB support, bt_en is pulled high by hardware. In this case, software-based power control should be disabled. The current platforms are Lemans-EVK and Monaco-EVK. Add QCA_WCN7850 to the existing condition so that power_ctrl_enabled is cleared when bt_en is not software-controlled (or absent), aligning its behavior with WCN6750 and WCN6855 Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13bluetooth: btusb: Fix whitespace in btusb.cLukas Kraft1-1/+2
Replace single space with tab and insert blank line after declaration, according to checkpatch Signed-off-by: Lukas Kraft <rebootrequired42@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-04-13net: team: Add new tx_enabled team port optionMarc Harvey1-0/+55
This option allows independent control over tx enablement without affecting rx enablement. Like the rx_enabled option, this also implicitly affects the enabled option. If this option is not used, then the enabled option will continue to behave as it did before. Tested in a follow-up patch with a new selftest. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-9-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Add new rx_enabled team port optionMarc Harvey1-0/+49
Allow independent control over rx enablement via the rx_enabled option without affecting tx enablement. This affects the normal enabled option since a port is only considered enabled if both tx and rx are enabled. If this option is not used, then the enabled option will continue to behave exactly as it did before. Tested in a follow-up patch with a new selftest. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-8-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Track rx enablement separately from tx enablementMarc Harvey2-25/+81
Separate the rx and tx enablement/disablement into different functions so that it is easier to interact with them independently later. Although this patch changes receive and transmit paths, the actual behavior of the teaming driver should remain unchanged, since there is no option introduced yet to change rx or tx enablement independently. Those options will be added in follow-up patches. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-7-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Rename enablement functions and struct members to txMarc Harvey4-25/+27
Add no functional changes, but rename enablement functions, variables etc. that are used in teaming driver transmit decisions. Since rx and tx enablement are still coupled, some of the variables renamed in this patch are still used for the rx path, but that will change in a follow-up patch. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-6-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Rename port_disabled team mode op to port_tx_disabledMarc Harvey2-4/+4
This team mode op is only used by the load balance mode, and it only uses it in the tx path. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-3-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Remove unused team_mode_op, port_enabledMarc Harvey1-2/+0
This team_mode_op wasn't used by any of the team modes, so remove it. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-2-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-13net: team: Annotate reads and writes for mixed lock accessed valuesMarc Harvey2-6/+7
The team_port's "index" and the team's "en_port_count" are read in the hot transmit path, but are only written to when holding the rtnl lock. Use READ_ONCE() for all lockless reads of these values, and use WRITE_ONCE() for all writes. Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Marc Harvey <marcharvey@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260409-teaming-driver-internal-v7-1-f47e7589685d@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-12net: ipa: add IPA v5.2 configuration dataLuca Weiss8-1/+464
Add the configuration data required for IPA v5.2, which is used in the Qualcomm Milos SoC. Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://patch.msgid.link/20260410-ipa-v5-2-v2-2-778422a05060@fairphone.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-12net: ethernet: mtk_eth_soc: initialize PPE per-tag-layer MTU registersDaniel Golle3-1/+52
The PPE enforces output frame size limits via per-tag-layer VLAN_MTU registers that the driver never initializes. The hardware defaults do not account for PPPoE overhead, causing the PPE to punt encapsulated frames back to the CPU instead of forwarding them. Initialize the registers at PPE start and on MTU changes using the maximum GMAC MTU. This is a conservative approximation -- the actual per-PPE requirement depends on egress path, but using the global maximum ensures the limits are never too small. Fixes: ba37b7caf1ed2 ("net: ethernet: mtk_eth_soc: add support for initializing the PPE") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/ec995ab8ce8be423267a1cc093147a74d2eb9d82.1775789829.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Copyright © 2025 - 2026 Wayne Cole. WTFPL. Attribution appreciated. No warranty. Not liable for bodily damages.