summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2025-07-25net: dsa: microchip: Setup fiber ports for KSZ8463Tristram Ha
The fiber ports in KSZ8463 cannot be detected internally, so it requires specifying that condition in the device tree. Like the one used in Micrel PHY the port link can only be read and there is no write to the PHY. The driver programs registers to operate fiber ports correctly. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250725001753.6330-6-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: microchip: Write switch MAC address differently for KSZ8463Tristram Ha
KSZ8463 uses 16-bit register definitions so it writes differently for 8-bit switch MAC address. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250725001753.6330-5-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: microchip: Use different registers for KSZ8463Tristram Ha
KSZ8463 does not use same set of registers as KSZ8863 so it is necessary to change some registers when using KSZ8463. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250725001753.6330-4-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: microchip: Add KSZ8463 switch support to KSZ DSA driverTristram Ha
KSZ8463 switch is a 3-port switch based from KSZ8863. Its major difference from other KSZ SPI switches is its register access is not a simple continual 8-bit transfer with automatic address increase but uses a byte-enable mechanism specifying 8-bit, 16-bit, or 32-bit access. Its registers are also defined in 16-bit format because it shares a design with a MAC controller using 16-bit access. As a result some common register accesses need to be re-arranged. This patch adds the basic structure for using KSZ8463. It cannot use the same regmap table for other KSZ switches as it interprets the 16-bit value as little-endian and its SPI commands are different. KSZ8463 uses a byte-enable mechanism to specify 8-bit, 16-bit, and 32-bit access. The register is first shifted right by 2 then left by 4. Extra 4 bits are added. If the access is 8-bit one of the 4 bits is set. If the access is 16-bit two of the 4 bits are set. If the access is 32-bit all 4 bits are set. The SPI command for read or write is then added. Because of this register transformation separate SPI read and write functions are provided for KSZ8463. KSZ8463's internal PHYs use standard PHY register definitions so there is no need to remap things. However, the hardware has a bug that the high word and low word of the PHY id are swapped. In addition the port registers are arranged differently so KSZ8463 has its own mapping for port registers and PHY registers. Therefore the PORT_CTRL_ADDR macro is replaced with the get_port_addr helper function. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250725001753.6330-3-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: stmmac: dwmac-socfpga: Add xgmac support for Agilex5Mun Yew Tham
Add support for Agilex5 compatible value. Signed-off-by: Mun Yew Tham <mun.yew.tham@altera.com> Signed-off-by: Matthew Gerlach <matthew.gerlach@altera.com> Link: https://patch.msgid.link/20250724154052.205706-5-matthew.gerlach@altera.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25Merge tag 'linux-can-fixes-for-6.16-20250725' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2025-07-25 The patch is by Stephane Grosjean and adds support the recent firmware of USB CAN FD interfaces to the peak_usb driver. * tag 'linux-can-fixes-for-6.16-20250725' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: peak_usb: fix USB FD devices potential malfunction ==================== Link: https://patch.msgid.link/20250725101619.4095105-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25Merge tag 'linux-can-next-for-6.17-20250725' 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-07-25 The first patch is by Khaled Elnaggar and converts the janz-ican3 driver's fwinfo_show() to sysfs_emit(). Vincent Mailhol contributes 3 patches that first fix a warning in the ti_hecc driver and then add missing COMPILE_TEST more compile coverage to the ti_hecc and tscan1 driver. Randy Dunlap's patch let's the tscan1 driver depend on PC104. A patch by Luis Felipe Hernandez fixes a kernel-doc error in the ctucanfd driver. Jimmy Assarsson contributes 10 patches for the kvaser_pciefd and 11 for the kvaser_usb driver. Both series simplify the identification of physical the CAN interfaces and add devlink support to get information about the running firmware. * tag 'linux-can-next-for-6.17-20250725' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: (27 commits) Documentation: devlink: add devlink documentation for the kvaser_usb driver can: kvaser_usb: Add devlink port support can: kvaser_usb: Expose device information via devlink info_get() can: kvaser_usb: Add devlink support can: kvaser_usb: Store additional device information can: kvaser_usb: Store the different firmware version components in a struct can: kvaser_usb: Move comment regarding max_tx_urbs can: kvaser_usb: Add intermediate variables can: kvaser_usb: Assign netdev.dev_port based on device channel index can: kvaser_usb: Add support for ethtool set_phys_id() can: kvaser_usb: Add support to control CAN LEDs on device Documentation: devlink: add devlink documentation for the kvaser_pciefd driver can: kvaser_pciefd: Add devlink port support can: kvaser_pciefd: Expose device firmware version via devlink info_get() can: kvaser_pciefd: Add devlink support can: kvaser_pciefd: Split driver into C-file and header-file. can: kvaser_pciefd: Store device channel index can: kvaser_pciefd: Store the different firmware version components in a struct can: kvaser_pciefd: Add intermediate variable for device struct in probe() can: kvaser_pciefd: Add support for ethtool set_phys_id() ... ==================== Link: https://patch.msgid.link/20250725161327.4165174-1-mkl@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== libie: commonize adminq structure Michal Swiatkowski says: It is a prework to allow reusing some specific Intel code (eq. fwlog). Move common *_aq_desc structure to libie header and changing it in ice, ixgbe, i40e and iavf. Only generic adminq commands can be easily moved to common header, as rest is slightly different. Format remains the same. It will be better to correctly move it when it will be needed to commonize other part of the code. Move *_aq_str() to new libie module (libie_adminq) and use it across drivers. The functions are exactly the same in each driver. Some more adminq helpers/functions can be moved to libie_adminq when needed. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: i40e: use libie_aq_str iavf: use libie_aq_str ice: use libie_aq_str libie: add adminq helper for converting err to str iavf: use libie adminq descriptors i40e: use libie adminq descriptors ixgbe: use libie adminq descriptors ice, libie: move generic adminq descriptors to lib ==================== Link: https://patch.msgid.link/20250724182826.3758850-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25wireguard: peer: Replace sockaddr with sockaddr_inetKees Cook
As part of the removal of the variably-sized sockaddr for kernel internals, replace struct sockaddr with sockaddr_inet in the endpoint union. No binary changes; the union size remains unchanged due to sockaddr_inet matching the size of sockaddr_in6. Signed-off-by: Kees Cook <kees@kernel.org> Link: https://patch.msgid.link/20250722171836.1078436-2-kees@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net/mlx5e: Expose TIS via devlink tx reporter diagnoseFeng Liu
Underneath "TIS Config" tag expose TIS diagnostic information. Expose the tisn of each TC under each lag port. $ sudo devlink health diagnose auxiliary/mlx5_core.eth.2/131072 reporter tx ...... TIS Config: lag port: 0 tc: 0 tisn: 0 lag port: 1 tc: 0 tisn: 8 ...... Signed-off-by: Feng Liu <feliu@nvidia.com> Reviewed-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/1753194228-333722-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net/mlx5e: Support routed networks during IPsec MACs initializationAlexandre Cassen
Remote IPsec tunnel endpoint may refer to a network segment that is not directly connected to the host. In such a case, IPsec tunnel endpoints are connected to a router and reachable via a routing path. In IPsec packet offload mode, HW is initialized with the MAC address of both IPsec tunnel endpoints. Extend the current IPsec init MACs procedure to resolve nexthop for routed networks. Direct neighbour lookup and probe is still used for directly connected networks and as a fallback mechanism if fib lookup fails. Signed-off-by: Alexandre Cassen <acassen@corp.free.fr> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/1753194228-333722-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: b53: mmap: Implement bcm63xx ephy power controlKyle Hendry
Implement the phy enable/disable calls for b53 mmap, and set the power down registers in the ephy control register appropriately. Signed-off-by: Kyle Hendry <kylehendrydev@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250724035300.20497-8-kylehendrydev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: b53: mmap: Add register layout for bcm6368Kyle Hendry
Add ephy register info for bcm6368. Signed-off-by: Kyle Hendry <kylehendrydev@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250724035300.20497-7-kylehendrydev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: b53: mmap: Add register layout for bcm6318Kyle Hendry
Add ephy register info for bcm6318, which also applies to bcm6328 and bcm6362. Signed-off-by: Kyle Hendry <kylehendrydev@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250724035300.20497-6-kylehendrydev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: b53: mmap: Add syscon reference and register layout for bcm63268Kyle Hendry
On bcm63xx SoCs there are registers that control the PHYs in the GPIO controller. Allow the b53 driver to access them by passing in the syscon through the device tree. Add a structure to describe the ephy control register and add register info for bcm63268. Signed-off-by: Kyle Hendry <kylehendrydev@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250724035300.20497-5-kylehendrydev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: b53: Define chip IDs for more bcm63xx SoCsKyle Hendry
Add defines for bcm6318, bcm6328, bcm6362, bcm6368 chip IDs, update tables and switch init. Signed-off-by: Kyle Hendry <kylehendrydev@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250724035300.20497-4-kylehendrydev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: b53: Add phy_enable(), phy_disable() methodsKyle Hendry
Add phy enable/disable to b53 ops to be called when enabling/disabling ports. Signed-off-by: Kyle Hendry <kylehendrydev@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250724035300.20497-2-kylehendrydev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: phy: micrel: fix KSZ8081/KSZ8091 cable testFlorian Larysch
Commit 21b688dabecb ("net: phy: micrel: Cable Diag feature for lan8814 phy") introduced cable_test support for the LAN8814 that reuses parts of the KSZ886x logic and introduced the cable_diag_reg and pair_mask parameters to account for differences between those chips. However, it did not update the ksz8081_type struct, so those members are now 0, causing no pairs to be tested in ksz886x_cable_test_get_status and ksz886x_cable_test_wait_for_completion to poll the wrong register for the affected PHYs (Basic Control/Reset, which is 0 in normal operation) and exit immediately. Fix this by setting both struct members accordingly. Fixes: 21b688dabecb ("net: phy: micrel: Cable Diag feature for lan8814 phy") Cc: stable@vger.kernel.org Signed-off-by: Florian Larysch <fl@n621.de> Link: https://patch.msgid.link/20250723222250.13960-1-fl@n621.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: microchip: Fix wrong rx drop MIB counter for KSZ8863Tristram Ha
When KSZ8863 support was first added to KSZ driver the RX drop MIB counter was somehow defined as 0x105. The TX drop MIB counter starts at 0x100 for port 1, 0x101 for port 2, and 0x102 for port 3, so the RX drop MIB counter should start at 0x103 for port 1, 0x104 for port 2, and 0x105 for port 3. There are 5 ports for KSZ8895, so its RX drop MIB counter starts at 0x105. Fixes: 4b20a07e103f ("net: dsa: microchip: ksz8795: add support for ksz88xx chips") Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20250723030403.56878-1-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25octeontx2-af: use unsigned int as iterator for unsigned valuesSimon Horman
The local variable i is used to iterate over unsigned values. The lower bound of the loop is set to 0. While the upper bound is cgx->lmac_count, where they lmac_count is an u8. So the theoretical upper bound is 255. As is, GCC can't see this range of values and warns that a formatted string, which includes the %d representation of i, may overflow the buffer provided. GCC 15.1.0 says: .../cgx.c: In function 'cgx_lmac_init': .../cgx.c:1737:49: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 4 and 6 [-Wformat-overflow=] 1737 | sprintf(lmac->name, "cgx_fwi_%d_%d", cgx->cgx_id, i); | ^~ .../cgx.c:1737:37: note: directive argument in the range [-2147483641, 254] 1737 | sprintf(lmac->name, "cgx_fwi_%d_%d", cgx->cgx_id, i); | ^~~~~~~~~~~~~~~ .../cgx.c:1737:17: note: 'sprintf' output between 12 and 24 bytes into a destination of size 16 1737 | sprintf(lmac->name, "cgx_fwi_%d_%d", cgx->cgx_id, i); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Empirically, changing the type of i from (signed) int to unsigned int addresses this problem. I assume by allowing GCC to see the range of values described above. Also update the format specifiers for the integer values in the string in question from %d to %u. This seems appropriate as they are now both unsigned. No functional change intended. Compile tested only. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20250724-octeontx2-af-unsigned-v1-1-c745c106e06f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25usbnet: Set duplex status to unknown in the absence of MIIYi Cong
Currently, USB CDC devices that do not use MDIO to get link status have their duplex mode set to half-duplex by default. However, since the CDC specification does not define a duplex status, this can be misleading. This patch changes the default to DUPLEX_UNKNOWN in the absence of MII, which more accurately reflects the state of the link and avoids implying an incorrect or error state. Link: https://lore.kernel.org/all/20250723152151.70a8034b@kernel.org/ Signed-off-by: Yi Cong <yicong@kylinos.cn> Acked-by: Oliver Neukum <oneukum@suse.com> Link: https://patch.msgid.link/20250724013133.1645142-1-yicongsrfy@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25macsec: set IFF_UNICAST_FLT priv flagStanislav Fomichev
Cosmin reports the following locking issue: # BUG: sleeping function called from invalid context at kernel/locking/mutex.c:275 # dump_stack_lvl+0x4f/0x60 # __might_resched+0xeb/0x140 # mutex_lock+0x1a/0x40 # dev_set_promiscuity+0x26/0x90 # __dev_set_promiscuity+0x85/0x170 # __dev_set_rx_mode+0x69/0xa0 # dev_uc_add+0x6d/0x80 # vlan_dev_open+0x5f/0x120 [8021q] # __dev_open+0x10c/0x2a0 # __dev_change_flags+0x1a4/0x210 # netif_change_flags+0x22/0x60 # do_setlink.isra.0+0xdb0/0x10f0 # rtnl_newlink+0x797/0xb00 # rtnetlink_rcv_msg+0x1cb/0x3f0 # netlink_rcv_skb+0x53/0x100 # netlink_unicast+0x273/0x3b0 # netlink_sendmsg+0x1f2/0x430 Which is similar to recent syzkaller reports in [0] and [1] and triggers because macsec does not advertise IFF_UNICAST_FLT although it has proper ndo_set_rx_mode callback that takes care of pushing uc/mc addresses down to the real device. In general, dev_uc_add call path is problematic for stacking non-IFF_UNICAST_FLT because we might grab netdev instance lock under addr_list_lock spinlock, so this is not a systemic fix. 0: https://lore.kernel.org/netdev/686d55b4.050a0220.1ffab7.0014.GAE@google.com 1: https://lore.kernel.org/netdev/68712acf.a00a0220.26a83e.0051.GAE@google.com/ Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/netdev/2aff4342b0f5b1539c02ffd8df4c7e58dd9746e7.camel@nvidia.com Fixes: 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations") Reported-by: Cosmin Ratiu <cratiu@nvidia.com> Tested-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250723224715.1341121-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: usbnet: Avoid potential RCU stall on LINK_CHANGE eventJohn Ernberg
The Gemalto Cinterion PLS83-W modem (cdc_ether) is emitting confusing link up and down events when the WWAN interface is activated on the modem-side. Interrupt URBs will in consecutive polls grab: * Link Connected * Link Disconnected * Link Connected Where the last Connected is then a stable link state. When the system is under load this may cause the unlink_urbs() work in __handle_link_change() to not complete before the next usbnet_link_change() call turns the carrier on again, allowing rx_submit() to queue new SKBs. In that event the URB queue is filled faster than it can drain, ending up in a RCU stall: rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 0-.... } 33108 jiffies s: 201 root: 0x1/. rcu: blocking rcu_node structures (internal RCU debug): Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 Call trace: arch_local_irq_enable+0x4/0x8 local_bh_enable+0x18/0x20 __netdev_alloc_skb+0x18c/0x1cc rx_submit+0x68/0x1f8 [usbnet] rx_alloc_submit+0x4c/0x74 [usbnet] usbnet_bh+0x1d8/0x218 [usbnet] usbnet_bh_tasklet+0x10/0x18 [usbnet] tasklet_action_common+0xa8/0x110 tasklet_action+0x2c/0x34 handle_softirqs+0x2cc/0x3a0 __do_softirq+0x10/0x18 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 __irq_exit_rcu+0xa8/0xb8 irq_exit_rcu+0xc/0x30 el1_interrupt+0x34/0x48 el1h_64_irq_handler+0x14/0x1c el1h_64_irq+0x68/0x6c _raw_spin_unlock_irqrestore+0x38/0x48 xhci_urb_dequeue+0x1ac/0x45c [xhci_hcd] unlink1+0xd4/0xdc [usbcore] usb_hcd_unlink_urb+0x70/0xb0 [usbcore] usb_unlink_urb+0x24/0x44 [usbcore] unlink_urbs.constprop.0.isra.0+0x64/0xa8 [usbnet] __handle_link_change+0x34/0x70 [usbnet] usbnet_deferred_kevent+0x1c0/0x320 [usbnet] process_scheduled_works+0x2d0/0x48c worker_thread+0x150/0x1dc kthread+0xd8/0xe8 ret_from_fork+0x10/0x20 Get around the problem by delaying the carrier on to the scheduled work. This needs a new flag to keep track of the necessary action. The carrier ok check cannot be removed as it remains required for the LINK_RESET event flow. Fixes: 4b49f58fff00 ("usbnet: handle link change") Cc: stable@vger.kernel.org Signed-off-by: John Ernberg <john.ernberg@actia.se> Link: https://patch.msgid.link/20250723102526.1305339-1-john.ernberg@actia.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: hibmcge: support for statistics of reset failuresJijie Shao
Add a statistical item to count the number of reset failures. This statistical item can be queried using ethtool -S or reported through diagnose information. Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20250723074826.2756135-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net/mlx5e: Fix potential deadlock by deferring RX timeout recoveryShahar Shitrit
mlx5e_reporter_rx_timeout() is currently invoked synchronously in the driver's open error flow. This causes the thread holding priv->state_lock to attempt acquiring the devlink lock, which can result in a circular dependency with other devlink operations. For example: - Devlink health diagnose flow: - __devlink_nl_pre_doit() acquires the devlink lock. - devlink_nl_health_reporter_diagnose_doit() invokes the driver's diagnose callback. - mlx5e_rx_reporter_diagnose() then attempts to acquire priv->state_lock. - Driver open flow: - mlx5e_open() acquires priv->state_lock. - If an error occurs, devlink_health_reporter may be called, attempting to acquire the devlink lock. To prevent this circular locking scenario, defer the RX timeout recovery by scheduling it via a workqueue. This ensures that the recovery work acquires locks in a consistent order: first the devlink lock, then priv->state_lock. Additionally, make the recovery work acquire the netdev instance lock to safely synchronize with the open/close channel flows, similar to mlx5e_tx_timeout_work. Repeatedly attempt to acquire the netdev instance lock until it is taken or the target RQ is no longer active, as indicated by the MLX5E_STATE_CHANNELS_ACTIVE bit. Fixes: 32c57fb26863 ("net/mlx5e: Report and recover from rx timeout") Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1753256672-337784-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net/mlx5e: Remove skb secpath if xfrm state is not foundJianbo Liu
Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup. Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0. Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer. This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0 </IRQ> Fixes: b2ac7541e377 ("net/mlx5e: IPsec: Add Connect-X IPsec Rx data path offload") Signed-off-by: Jianbo Liu <jianbol@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1753256672-337784-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net/mlx5e: Clear Read-Only port buffer size in PBMC before updateAlexei Lazar
When updating the PBMC register, we read its current value, modify desired fields, then write it back. The port_buffer_size field within PBMC is Read-Only (RO). If this RO field contains a non-zero value when read, attempting to write it back will cause the entire PBMC register update to fail. This commit ensures port_buffer_size is explicitly cleared to zero after reading the PBMC register but before writing back the modified value. This allows updates to other fields in the PBMC register to succeed. Fixes: 0696d60853d5 ("net/mlx5e: Receive buffer configuration") Signed-off-by: Alexei Lazar <alazar@nvidia.com> Reviewed-by: Yael Chemla <ychemla@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1753256672-337784-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: Fix typosBjorn Helgaas
Fix typos in comments and error messages. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: David Arinzon <darinzon@amazon.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250723201528.2908218-1-helgaas@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25can: kvaser_usb: Add devlink port supportJimmy Assarsson
Register each CAN channel of the device as an devlink physical port. This makes it easier to get device information for a given network interface (i.e. can2). Example output: $ devlink dev usb/1-1.3:1.0 $ devlink port usb/1-1.3:1.0/0: type eth netdev can0 flavour physical port 0 splittable false usb/1-1.3:1.0/1: type eth netdev can1 flavour physical port 1 splittable false $ devlink port show can1 usb/1-1.3:1.0/1: type eth netdev can1 flavour physical port 0 splittable false $ devlink dev info usb/1-1.3:1.0: driver kvaser_usb serial_number 1020 versions: fixed: board.rev 1 board.id 7330130009653 running: fw 3.22.527 $ ethtool -i can1 driver: kvaser_usb version: 6.12.10-arch1-1 firmware-version: 3.22.527 expansion-rom-version: bus-info: 1-1.3:1.0 supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-11-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_usb: Expose device information via devlink info_get()Jimmy Assarsson
Expose device information via devlink info_get(): * Serial number * Firmware version * Hardware revision * EAN (product number) Example output: $ devlink dev usb/1-1.2:1.0 $ devlink dev info usb/1-1.2:1.0: driver kvaser_usb serial_number 1020 versions: fixed: board.rev 1 board.id 7330130009653 running: fw 3.22.527 Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-10-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_usb: Add devlink supportJimmy Assarsson
Add devlink support at device level. Example output: $ devlink dev usb/1-1.3:1.0 $ devlink dev info usb/1-1.3:1.0: driver kvaser_usb Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-9-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_usb: Store additional device informationJimmy Assarsson
Store additional device information; EAN (product number), serial_number and hardware revision. Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-8-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_usb: Store the different firmware version components in a structJimmy Assarsson
Store firmware version in kvaser_usb_fw_version struct, specifying the different components of the version number. And drop debug prinout of firmware version, since later patches will expose it via the devlink interface. Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-7-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_usb: Move comment regarding max_tx_urbsJimmy Assarsson
Move comment regarding max_tx_urbs, to where the struct member is declared. Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-6-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_usb: Add intermediate variablesJimmy Assarsson
Add intermediate variables, for readability and to simplify future patches. Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-5-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_usb: Assign netdev.dev_port based on device channel indexJimmy Assarsson
Assign netdev.dev_port based on the device channel index, to indicate the port number of the network device. While this driver already uses netdev.dev_id for that purpose, dev_port is more appropriate. However, retain dev_id to avoid potential regressions. Fixes: 3e66d0138c05 ("can: populate netdev::dev_id for udev discrimination") Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-4-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_usb: Add support for ethtool set_phys_id()Jimmy Assarsson
Add support for ethtool set_phys_id(), to physically locate devices by flashing a LED on the device. Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-3-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_usb: Add support to control CAN LEDs on deviceJimmy Assarsson
Add support to turn on/off CAN LEDs on device. Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123452.41-2-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_pciefd: Add devlink port supportJimmy Assarsson
Register each CAN channel of the device as an devlink physical port. This makes it easier to get device information for a given network interface (i.e. can2). Example output: $ devlink dev pci/0000:07:00.0 pci/0000:08:00.0 pci/0000:09:00.0 $ devlink port pci/0000:07:00.0/0: type eth netdev can0 flavour physical port 0 splittable false pci/0000:07:00.0/1: type eth netdev can1 flavour physical port 1 splittable false pci/0000:07:00.0/2: type eth netdev can2 flavour physical port 2 splittable false pci/0000:07:00.0/3: type eth netdev can3 flavour physical port 3 splittable false pci/0000:08:00.0/0: type eth netdev can4 flavour physical port 0 splittable false pci/0000:08:00.0/1: type eth netdev can5 flavour physical port 1 splittable false pci/0000:09:00.0/0: type eth netdev can6 flavour physical port 0 splittable false pci/0000:09:00.0/1: type eth netdev can7 flavour physical port 1 splittable false pci/0000:09:00.0/2: type eth netdev can8 flavour physical port 2 splittable false pci/0000:09:00.0/3: type eth netdev can9 flavour physical port 3 splittable false $ devlink port show can2 pci/0000:07:00.0/2: type eth netdev can2 flavour physical port 2 splittable false $ devlink dev info pci/0000:07:00.0: driver kvaser_pciefd versions: running: fw 1.3.75 pci/0000:08:00.0: driver kvaser_pciefd versions: running: fw 2.4.29 pci/0000:09:00.0: driver kvaser_pciefd versions: running: fw 1.3.72 $ sudo ethtool -i can2 driver: kvaser_pciefd version: 6.8.0-40-generic firmware-version: 1.3.75 expansion-rom-version: bus-info: 0000:07:00.0 supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-10-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_pciefd: Expose device firmware version via devlink info_get()Jimmy Assarsson
Expose device firmware version via devlink info_get(). Example output: $ devlink dev pci/0000:07:00.0 pci/0000:08:00.0 pci/0000:09:00.0 $ devlink dev info pci/0000:07:00.0: driver kvaser_pciefd versions: running: fw 1.3.75 pci/0000:08:00.0: driver kvaser_pciefd versions: running: fw 2.4.29 pci/0000:09:00.0: driver kvaser_pciefd versions: running: fw 1.3.72 Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-9-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_pciefd: Add devlink supportJimmy Assarsson
Add devlink support at device level. Example output: $ devlink dev pci/0000:07:00.0 pci/0000:08:00.0 pci/0000:09:00.0 $ devlink dev info pci/0000:07:00.0: driver kvaser_pciefd pci/0000:08:00.0: driver kvaser_pciefd pci/0000:09:00.0: driver kvaser_pciefd Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-8-extja@kvaser.com [mkl: kvaser_pciefd_remove(): fix use-after-free] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_pciefd: Split driver into C-file and header-file.Jimmy Assarsson
Split driver into C-file and header-file, to simplify future patches. Move common definitions and declarations to a header file. Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-7-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_pciefd: Store device channel indexJimmy Assarsson
Store device channel index in netdev.dev_port. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-6-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_pciefd: Store the different firmware version components in a structJimmy Assarsson
Store firmware version in kvaser_pciefd_fw_version struct, specifying the different components of the version number. And drop debug prinout of firmware version, since later patches will expose it via the devlink interface. Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-5-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_pciefd: Add intermediate variable for device struct in probe()Jimmy Assarsson
Add intermediate variable, for readability and to simplify future patches. Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-4-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_pciefd: Add support for ethtool set_phys_id()Jimmy Assarsson
Add support for ethtool set_phys_id(), to physically locate devices by flashing a LED on the device. Reviewed-by: Axel Forsman <axfo@kvaser.com> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-3-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: kvaser_pciefd: Add support to control CAN LEDs on deviceJimmy Assarsson
Add support to turn on/off CAN LEDs on device. Turn off all CAN LEDs in probe, since they are default on after a reset or power on. Reviewed-by: Axel Forsman <axfo@kvaser.com> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://patch.msgid.link/20250725123230.8-2-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25docs: Fix kernel-doc error in CAN driverLuis Felipe Hernandez
Fix kernel-doc formatting issue causing unexpected indentation error in ctucanfd driver documentation build. Convert main return values to bullet list format while preserving numbered sub-list in order to correct indentation error and visual structure in rendered html. Signed-off-by: Luis Felipe Hernandez <luis.hernandez093@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Reviewed-by: Pavel Pisa <pisa@fel.cvut.cz> Link: https://patch.msgid.link/20250722035352.21807-1-luis.hernandez093@gmail.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: tscan1: CAN_TSCAN1 can depend on PC104Randy Dunlap
Add a dependency on PC104 to limit (restrict) this driver kconfig prompt to kernel configs that have PC104 set. Add COMPILE_TEST as a possibility for more complete build coverage. I tested this build config on x86_64 5 times without problems. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20250721002823.3548945-1-rdunlap@infradead.org [mkl: fix conflict, remove Fixes: tag] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-07-25can: peak_usb: fix USB FD devices potential malfunctionStephane Grosjean
The latest firmware versions of USB CAN FD interfaces export the EP numbers to be used to dialog with the device via the "type" field of a response to a vendor request structure, particularly when its value is greater than or equal to 2. Correct the driver's test of this field. Fixes: 4f232482467a ("can: peak_usb: include support for a new MCU") Signed-off-by: Stephane Grosjean <stephane.grosjean@hms-networks.com> Link: https://patch.msgid.link/20250724081550.11694-1-stephane.grosjean@free.fr Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> [mkl: rephrase commit message] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>