wireguard-linux/net/ethtool, branch stable

net: ethtool: let tsconfig reach a PHY-only timestamp provider

2026-09-29T02:26:41Z

TSCONFIG_GET and TSCONFIG_SET reject a device that implements neither hwtstamp NDO, even when its PHY can serve the request. The ioctls they meant to replace handle it, so the two interfaces disagree on the same hardware and user space has to pick one. Accept the default timestamping PHY and an already installed provider on both sides. On the set side the test moves into ethnl_set_tsconfig() as the validate callback runs without rtnl. On the get side it stays ahead of ethnl_ops_begin(), so a device that can serve nothing keeps failing with EOPNOTSUPP and a dump still skips it rather than stopping there. A netdev provider needs ndo_hwtstamp_set to be programmed at all, so don't pick that source without it, and test for ndo_hwtstamp_get before calling it. Fixes: 6e9e2eed4f39 ("net: ethtool: Add support for tsconfig command to get/set hwtstamp config") Signed-off-by: Nicolai Buchwitz Reviewed-by: Maxime Chevallier Reviewed-by: Kory Maincent Link: https://patch.msgid.link/20260925135237.3432266-3-nb@tipi-net.de Signed-off-by: Jakub Kicinski

net: ethtool: keep rtnl_lock for the ioctl self test

2026-09-19T00:19:15Z

An offline self test that brings the interface down and back up with netif_close() / netif_open() requires rtnl_lock for both. Since the ethtool IOCTL path became rtnl-optional for ops-locked drivers, the ETHTOOL_TEST ioctl runs holding only the netdev instance lock, so on an ops-locked driver the self test now tears the device down without rtnl_lock. With lockdep this reproduces deterministically on every offline self test on such a driver; note the sole lock held is the instance lock, not rtnl: WARNING: suspicious RCU usage net/core/netpoll.c:207 suspicious rcu_dereference_protected() usage! 1 lock held by ethtool/107: #0: (&dev->lock){+.+.}, at: dev_ethtool Call Trace: netpoll_poll_disable __dev_close_many netif_close_many netif_close fbnic_self_test dev_ethtool_locked dev_ethtool dev_ioctl sock_ioctl __x64_sys_ioctl Without lockdep the same condition trips ASSERT_RTNL() in __dev_close_many() / __dev_open(); that check only samples the global rtnl state, so it can be masked by a concurrent rtnl holder, but the device is still being reconfigured without the lock it requires. The ethtool self_test is a legacy ioctl-only command, so an ETHTOOL_TEST case is only needed on the ioctl path. Add an opt-in bit for drivers whose self test needs rtnl_lock and set it on the ops-locked drivers whose offline self test tears the interface down and up: - fbnic (ops-locked via queue_mgmt_ops): fbnic_self_test() offline path uses netif_close() / netif_open(). - bnxt (ops-locked via queue_mgmt_ops): bnxt_self_test() offline path goes through bnxt_close_nic() / bnxt_half_open_nic() / bnxt_half_close_nic() / bnxt_open_nic(), which close and reopen the device. Fixes: f994752b1127 ("net: ethtool: optionally skip rtnl_lock on IOCTL path") Signed-off-by: Alexander Duyck Reviewed-by: Simon Horman Link: https://patch.msgid.link/178942019771.7700.338431553546884773.stgit@ahduyck-xeon-server.home.arpa Signed-off-by: Jakub Kicinski

ethtool: tsconfig: reject zero-valued tx_type and rx_filter bitsets

2026-08-14T00:44:54Z

The ffs()/fls() guard in ethnl_set_tsconfig() was meant to enforce that the user selects exactly one tx_type (and one rx_filter) at a time (off / none are explicit types with non-zero values). However, both ffs(0) and fls(0) return 0, so the guard passes a zero-valued bitset through. The subsequent ffs(req_tx_type) - 1 would produce -1, if user selected no bit. net_hwtstamp_validate() catches the invalid -1 downstream, but returns a generic error (-ERANGE) without telling the user what went wrong. Return -EINVAL + extack instead. Replace the ffs()/fls() comparison with a hweight32() == 1 check. Reviewed-by: Andrew Lunn Reviewed-by: Joe Damato Reviewed-by: Vadim Fedorenko Link: https://patch.msgid.link/20260812162230.1837788-1-kuba@kernel.org Signed-off-by: Jakub Kicinski

ethtool: rss: Fix hfunc and input_xfrm parsing on big endian

2026-07-09T09:38:30Z

ETHTOOL_A_RSS_HFUNC and ETHTOOL_A_RSS_INPUT_XFRM are NLA_U32 attributes, but ethnl_rss_set() and ethnl_rss_create_doit() parse them with ethnl_update_u8(), which reads a single byte. On little endian this happens to read the least significant byte and works as long as the value fits in a byte. On big endian it reads the most significant byte, so the requested value is parsed incorrectly. The destination fields in struct ethtool_rxfh_param are u8, so the attribute can't be read directly with ethnl_update_u32(). Cap the hfunc policy at U8_MAX so an out of range value is rejected instead of being silently truncated into the u8 field, and add ethnl_update_u8_u32() to read the full u32 and narrow it into the u8 destination. Fixes: 82ae67cbc423 ("ethtool: rss: support setting hfunc via Netlink") Fixes: d3e2c7bab124 ("ethtool: rss: support setting input-xfrm via Netlink") Fixes: a166ab7816c5 ("ethtool: rss: support creating contexts via Netlink") Reviewed-by: Dragos Tatulea Reviewed-by: Nimrod Oren Signed-off-by: Gal Pressman Link: https://patch.msgid.link/20260706055017.3355806-1-gal@nvidia.com Signed-off-by: Paolo Abeni

net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link()

2026-06-25T17:18:34Z

Breno reports following splats on mlx5: RTNL: assertion failed at net/core/dev.c (2241) WARNING: net/core/dev.c:2241 at netif_state_change+0xed/0x130, CPU#5: ethtool/1335 RIP: 0010:netif_state_change+0xf9/0x130 Call Trace: __linkwatch_sync_dev+0xea/0x120 ethtool_op_get_link+0xe/0x20 __ethtool_get_link+0x26/0x40 linkstate_prepare_data+0x51/0x200 ethnl_default_doit+0x213/0x470 genl_family_rcv_msg_doit+0xdd/0x110 Looks like I missed ethtool_op_get_link() trying to sync linkwatch, which needs rtnl_lock. Not all drivers do this - bnxt doesn't, it just returns the link state, so add an opt-in bit. Reported-by: Breno Leitao Fixes: 45079e00133e ("net: ethtool: optionally skip rtnl_lock on Netlink path for GET ops") Acked-by: Stanislav Fomichev Reviewed-by: Breno Leitao Acked-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260624190439.2521219-1-kuba@kernel.org Signed-off-by: Jakub Kicinski

tls: remove tls_toe and the related driver

2026-06-12T23:43:10Z

The tls_toe feature and its single user (chelsio chtls) have been unmaintained for multiple years. It also hooks into the core of the TCP implementation, and bypasses most of the networking stack. Signed-off-by: Sabrina Dubroca Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/1f30e73275c07bf879f547589872d0916025a52e.1781165969.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski

ethtool: tsconfig: always take rtnl_lock

2026-06-12T23:41:56Z

mlx5 throws ASSERT_RTNL() warnings on timestamp config, because it tries to update features. mlx5e_hwtstamp_set() calls netdev_update_features(). I missed this while grepping the drivers because tsconfig goes through ndo_hwtstamp_set/get, not ethtool ops, even tho the new uAPI is in ethtool Netlink. We could add a dedicated opt out bit for mlx5, but NDOs were not supposed to be part of the ethtool locking conversion in the first place. The mlx5 features update is related to the "compressed CQE" format which lacks timestamp, apparently. See commit c0194e2d0ef0 ("net/mlx5e: Disable rxhash when CQE compress is enabled"). Fixes: f9a3e05114b8 ("net: ethtool: optionally skip rtnl_lock on Netlink path for SET ops") Acked-by: Stanislav Fomichev Reviewed-by: Jacob Keller Reviewed-by: Vadim Fedorenko Reviewed-by: Kory Maincent Link: https://patch.msgid.link/20260611200355.2020663-1-kuba@kernel.org Signed-off-by: Jakub Kicinski

net: ethtool: add KSZ87xx low-loss cable PHY tunables

2026-06-11T22:47:56Z

Introduce vendor-specific PHY tunable identifiers to control the KSZ87xx low-loss cable erratum handling through the ethtool PHY tunable interface. The following tunables are added: - a boolean "short-cable" tunable, applying a documented and conservative preset intended for short or low-loss Ethernet cables; - an integer LPF bandwidth tunable, allowing advanced adjustment of the receiver low-pass filter bandwidth; - an integer DSP EQ initial value tunable, allowing advanced tuning of the PHY equalizer initialization. The actual behavior is implemented by the corresponding PHY and switch drivers. Reviewed-by: Marek Vasut Reviewed-by: Nicolai Buchwitz Signed-off-by: Fidelio Lawson Link: https://patch.msgid.link/20260609-ksz87xx_errata_low_loss_connections-v10-2-9ba4418cf3db@exotec.com Signed-off-by: Jakub Kicinski

net: ethtool: optionally skip rtnl_lock on IOCTL path

2026-06-09T17:13:06Z

Convert the IOCTL path similarly to how we converted Netlink. The device lookup gets a little hairy. We could take rtnl_lock unconditionally and drop it before calling the driver (this would avoid the reference + liveness check). But I think being able to make progress even if rtnl is dead-locked is quite useful. First extra concern is handling features. List all the cmds which modify features and always take rtnl_lock. We could fold this list into ethtool_ioctl_needs_rtnl() but seems cleaner to keep ethtool_ioctl_needs_rtnl() driver-related. If a driver changed features and we were not holding rtnl_lock - warn about it. It can only happen on buggy ops locked drivers (buggy because they should have set appropriate "I need rtnl for op X" bit). Second wrinkle is the PHY ID hack which drops the locks while sleeping. Convert its static "busy" variable which used to be protected by rtnl_lock to a field in struct ethtool_netdev_state. This feature is about identifying an adapter or a port within a system, so being able to blink multiple LEDs at the same time is likely not very useful in practice. But it's the simplest fix, we can add a mutex if someone thinks a system should only be ID'ing one port at a time. Reviewed-by: Eric Dumazet Acked-by: Stanislav Fomichev Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260605002912.3456868-12-kuba@kernel.org Signed-off-by: Jakub Kicinski

net: ethtool: ioctl: concentrate the locking

2026-06-09T17:13:06Z

Add another layer of helper functions to make upcoming locking changes easier. Otherwise we'd need a pretty complex goto structure. netdev instance lock is now taken slightly sooner but that should not be an issue since rtnl_lock is already held, anyway. Reviewed-by: Eric Dumazet Acked-by: Stanislav Fomichev Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260605002912.3456868-11-kuba@kernel.org Signed-off-by: Jakub Kicinski