Stanislav Fomichev says:
====================
net: devmem: remove gen_pool from dma-buf allocations
Replace devmem's gen_pool based fixed-size allocator with a binding-level
freelist similar to the one used by io_uring zero-copy receive.
This is motivated by allocation latency observed in the NAPI receive path:
[ 1036.228913] ? gen_pool_create+0x90/0x90
[ 1036.228915] net_devmem_alloc_dmabuf+0x1f/0x60
[ 1036.228918] mp_dmabuf_devmem_alloc_netmems+0x17/0x80
[ 1036.228920] mlx5e_post_rx_mpwqes+0xdbe/0xdd0
[ 1036.228926] mlx5e_napi_poll+0x113/0x830
[ 1036.228928] ? sched_clock+0x5/0x10
[ 1036.228931] ? wake_up_process+0x778/0x14b0
[ 1036.228933] net_rx_action+0x15d/0x570
[ 1036.228934] ? update_rq_clock+0x31/0x240
[ 1036.228937] ? __napi_schedule+0x55/0xa0
[ 1036.228938] ? mlx5_eq_comp_int+0x137/0x230
[ 1036.228940] ? atomic_notifier_call_chain+0x36/0x90
[ 1036.228943] ? sched_clock+0x5/0x10
[ 1036.228944] ? sched_clock_cpu+0xc/0x170
[ 1036.228947] irq_exit_rcu+0x12b/0x370
[ 1036.228950] common_interrupt+0x85/0x90
udmabuf can create a very large number of SG entries. In the worst case,
devmem ends up adding one gen_pool chunk for each net_iov allocation
unit backed by those entries. The gen_pool allocation path then has to
traverse a linked list that can become too long for this hot path.
Patch 1 removes the gen_pool and replaces it with a simple freelist of
net_iov pointers protected by the same spin_lock_bh() pattern used by
io_uring zcrx. Patch 2 removes the now-unnecessary chunk owner wrapper by
embedding the net_iov_area directly in the dma-buf binding. Patch 3
batches freelist allocations.
====================
See mailing Link for performance evaluation.
Link: https://patch.msgid.link/20260917181116.3319017-1-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Rename net_devmem_alloc_dmabuf() into net_devmem_alloc_dmabuf_bulk() and
make it refill page pool with up to PP_ALLOC_CACHE_REFILL NIOVs,
similar to io_pp_zc_alloc_netmems(). That should amortize recently
introduced freelist_lock.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260917181116.3319017-4-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
After replacing the gen_pool with a binding-level freelist, devmem no
longer needs a separate chunk owner object. There is only one
net_iov_area for the binding, so store it directly in struct
net_devmem_dmabuf_binding.
Derive the binding from net_iov_owner() with container_of(), matching the
pattern used by io_uring zcrx. This removes the leftover
dmabuf_genpool_chunk_owner wrapper and its allocation/free path.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260917181116.3319017-3-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
devmem only needs fixed-size net_iov allocations for each dma-buf binding.
The gen_pool tracks the same free set indirectly through DMA addresses,
which makes devmem depend on the generic allocator even though the users
are fixed-size net_iov chunks.
Mirror the io_uring zcrx model more closely by keeping a binding-level
freelist protected by spin_lock_bh(). Use a single net_iov_area owner for
the binding, populate each net_iov's DMA address while walking the SG
table, and check at teardown that all net_iovs have returned to the
freelist.
Validate the DMA-BUF size against the net_iov size up front and derive the
RX and TX entry count from it, avoiding a separate SG-table pass.
Drop the NET_DEVMEM select of GENERIC_ALLOCATOR now that devmem no longer
calls gen_pool APIs.
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260917181116.3319017-2-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Before commit c5c37af6ec ("tcp: Convert do_tcp_sendpages() to use
MSG_SPLICE_PAGES"), do_tcp_sendpages() did not call
tcp_rate_check_app_limited() internally, so callers needed an explicit
tcp_rate_check_app_limited() to cover it. That commit replaced
do_tcp_sendpages() with direct tcp_sendmsg_locked() calls, which perform
the check on every path that queues data. The outer call became redundant
but was left in place.
The site changed here, tls_push_sg(), holds the socket lock and invokes
tcp_sendmsg_locked() on every iteration. The early-return paths in
tcp_sendmsg_locked() that skip tcp_rate_check_app_limited() -- the
MSG_ZEROCOPY allocation failure and MSG_FASTOPEN branches -- return
without queueing any MSG_SPLICE_PAGES data, so there is no functional
consequence from omitting the outer check.
A potential benefit of this change is that it facilitates future reuse of
tls_push_sg() for KTLS support in protocols beyond TCP, such as MPTCP.
Since tcp_rate_check_app_limited() is TCP-specific while sendmsg_locked()
is a generic interface in struct proto_ops, this change allows us to switch
to different protocols via sk->sk_socket->ops->sendmsg_locked() without
carrying protocol-specific assumptions.
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Link: https://patch.msgid.link/5bc803abb4e27054eaffc8b26db7812e6347b0dd.1789634247.git.tanggeliang@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Sagi Maimon says:
====================
ptp: ocp: add TAP CPLD support for ADVA TimeCard X1
The ADVA TimeCard X1 (PCI device 0x0410) carries a Lattice MachXO3 CPLD
on the TMC I2C bus. This series adds access to it and an update path
through devlink flash.
The card has two I2C controllers. Linux registers only the one at
0x00150000, normally routed to the config EEPROMs; the one at 0x00120000
belongs to the on-card MicroBlaze and is routed to the TMC or M.2 bus as
its firmware selects. A request/grant handshake re-routes the host
controller onto the TMC bus, where the PCA9548 and the CPLD behind its
channel 0 live. Everything here is built on that handshake.
Patches 1 and 2 are pre-existing probe-error-path bugs that were buried
in the feature commit in v13; they are split out with Fixes: tags. Patch
1 is also a prerequisite: patch 3 adds a mutex that ptp_ocp_detach()
destroys, so devlink has to be unregistered first. Patch 3 adds the bus
arbitration and the read-only interfaces, patch 4 the flashing.
====================
Link: https://patch.msgid.link/20260916153242.157171-1-sagi.maimon@adtran.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Lattice MachXO3 CPLD on the ADVA TimeCard X1 is programmed over I2C
using in-system programming (ISP). Build on the TMC bus arbitration added
previously and expose the update path as a devlink flash component, next
to the card flash the driver already writes through devlink.
The component is named fw.cpld and reported as a running version, so
->info_get() both publishes the USERCODE of the image currently in the
part and lets the core accept the name:
devlink dev flash pci/0000:02:00.0 file adva-cpld.bin component fw.cpld
Flashing acquires the bus, erases the configuration flash, programs the
image page by page and activates it with the MachXO3 REFRESH command,
reporting progress with the standard devlink notifications. The CPLD is
required to come back with DONE set, not busy and no error code before the
update is called successful, as drivers/fpga/machxo2-spi.c does.
The whole sequence runs under cpld_lock and the i2c adapter lock, so an
EEPROM read blocks for as long as programming takes; the alternative is
reading the TMC bus instead. Flashing is privileged:
DEVLINK_CMD_FLASH_UPDATE carries GENL_ADMIN_PERM.
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Link: https://patch.msgid.link/20260916153242.157171-5-sagi.maimon@adtran.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ADVA TimeCard X1 carries a Lattice MachXO3 CPLD on its TMC I2C bus.
Reaching it means taking that bus from the on-card MicroBlaze first.
The card has two I2C controllers. Linux registers only the one at
0x00150000, normally routed to the config EEPROMs; the one at 0x00120000
belongs to the MicroBlaze and is routed to the TMC or M.2 bus as its
firmware selects. A request/grant handshake re-routes the host controller
onto the TMC bus, where the PCA9548 and the CPLD behind its channel 0
live. An operation takes the i2c core adapter lock for the whole grant
window and uses __i2c_transfer() internally; without that, a concurrent
transfer from ptp_ocp_read_eeprom(), from the nvmem attributes or from the
at24 sysfs files would be issued onto the TMC bus instead of to the
EEPROM. The hand-back waits for the firmware to drop the grant before the
adapter lock is released, for the same reason.
On top of the arbitration this adds two read-only interfaces: a root-only
cpld_status attribute reporting the flags in the CPLD status register, and
the Lattice device ID as the fixed devlink version cpld.id. Reading the
ID claims the bus, so it must not sit on DEVLINK_CMD_INFO_GET, which
carries no GENL_ADMIN_PERM; the driver reads it once from its own worker,
as soon as the i2c adapter has registered, and info_get() reports the
cached value.
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Link: https://patch.msgid.link/20260916153242.157171-4-sagi.maimon@adtran.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Two problems on the dpll error paths in ptp_ocp_probe().
dpll_device_register() takes a second reference and stores bp as the
registration private data, and only dpll_device_unregister() drops it.
out_dpll dropped bp->tracker but never unregistered, so a dpll_pin_get()
or dpll_pin_register() failure left the device registered and visible to
userspace with a priv pointer into the storage devlink_free() releases a
few lines later, as well as leaking the registration object.
A failing dpll_device_register() jumped to the same label as the failing
dpll_device_get(), so the reference taken by dpll_device_get() was never
dropped either. Give that case its own label.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Link: https://patch.msgid.link/20260916153242.157171-3-sagi.maimon@adtran.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
devlink_register() runs before the dpll setup in ptp_ocp_probe(), but the
failure paths after it went straight to ptp_ocp_detach() and then
devlink_free(), which opens with ASSERT_DEVLINK_NOT_REGISTERED(devlink).
Any dpll failure during probe therefore freed a devlink instance that was
still registered.
Route those paths through a new out_devlink label that unregisters first,
matching the order ptp_ocp_remove() already uses.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Link: https://patch.msgid.link/20260916153242.157171-2-sagi.maimon@adtran.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A recent patch introduced a call to devm_cxl_probe_mem(), which is only
available when CXL_MEM is enabled. If CXL_MEM is in a loadable module,
this causes a link failure for a builtin driver:
s390-linux-ld: drivers/net/ethernet/sfc/efx_cxl.o: in function `efx_cxl_init':
efx_cxl.c:(.text+0x156): undefined reference to `devm_cxl_probe_mem'
Adapt the dependency to require CXL_MEM instead of CXL_BUS, which
we know is available when CXL_MEM is.
Fixes: 0418860ef2 ("sfc: obtain and map cxl range using devm_cxl_probe_mem")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/20260917155519.2121486-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
VCAP_KUNIT_TEST enables DEBUG_FS even when the kernel configuration
leaves it disabled. Remove the selection, following the dependency rule
in Documentation/dev-tools/kunit/style.rst.
The debugfs implementation and its tests are already built only with
DEBUG_FS. The other VCAP tests can run without it.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
Acked-by: David Gow <david@davidgow.net>
Link: https://patch.msgid.link/20260917064736.77354-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gcc warns about an unused function here because the __maybe_unused
attribute is in the wrong part of the prototype:
drivers/net/dsa/motorcomm/leds.c:352:1: error: 'yt921x_cled_hw_control_get_device' defined but not used [-Werror=unused-function]
352 | yt921x_cled_hw_control_get_device(struct led_classdev *led_cdev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Move the __maybe_unused attribute to refer to the function rather
than the returned object.
Fixes: 9af9a81682 ("net: dsa: motorcomm: Add LED support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260916082707.3973287-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gro_cells_receive() reports SKB_DROP_REASON_NOT_SPECIFIED when the device
is down or the GRO cell queue length exceeds max_backlog.
Pass SKB_DROP_REASON_DEV_READY and SKB_DROP_REASON_CPU_BACKLOG to
kfree_skb_reason() for these two cases, respectively.
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260916091420.138170-1-xuanqiang.luo@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Javen Xu says:
====================
add support for phy chip and firmware
This series patch add support forRTL8261CE_CG and RTL8261D_VM, and add
firmware support for RTL8261D.
====================
Link: https://patch.msgid.link/20260916081444.497-1-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add support for RTL8261CE_CG, its phy id is 0x001cc899. RTL8261CE_CG
share the same sub_phy_id and firmware with RTL8261C_CG.
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260916081444.497-2-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When initializing phylink configuration, if LPI capabilities is
non-zero, it indicates the hardware supports EEE, thus we enable it by
default.
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Link: https://patch.msgid.link/20260916081306.184-1-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
All of the references to the callback pointer are gone, so remove the
pointer itself before we grow new references to it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260915211538.1519815-2-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ieee802154 socket implementation is the last remaining caller of the
netdevice ioctl callback. In order to completely remove this, add a custom
pointer to the existing wpan_dev specific operations structure. Since that
structure is currently only used to wrap the 'create' header operation,
adjust the naming slightly to make this more generic.
It would be a good idea to adjust the calling conventions and split the
get/set operations into separate functions, but that can be a follow-up
cleanup. For the moment, I kept the actual changes to a minimum to
avoid regressions.
Link: https://lore.kernel.org/all/20231011140225.253106-2-arnd@kernel.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260915211538.1519815-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add the fundamental driver architecture framework and Leonis hardware
layer initialization for NBL NIC family.
- nbl_adapter/nbl_core/nbl_common_info core device context
- PCI probe/remove entry and basic device capability parsing
- Leonis hardware BAR resource request and ioremap logic
This patch establishes the lowest HW layer and core infrastructure,
preparing for subsequent device implementations.
Note:
This commit binds the PCI device during probe, but does not create or
register netdev. Netdev support will be added in later patches of this
series. This intermediate state is safe: hardware BARs are mapped. Chip
configuration and the mailbox control path are brought up by this series,
and Ethernet data path RX/TX queues plus data-plane interrupts remain
unconfigured and disabled at this stage.
Signed-off-by: illusion wang <illusion.wang@nebula-matrix.com>
Link: https://patch.msgid.link/20260914123429.56596-3-illusion.wang@nebula-matrix.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch adds the minimum build infrastructure:
1. Add Kconfig, Makefile and MAINTAINERS entries;
2. Add corresponding driver documentation;
3. Add PCI driver skeleton with empty stubs for nbl driver.
Note: the documentation describes the final full driver features;
implementation will be added in subsequent patches of this series.
Signed-off-by: illusion wang <illusion.wang@nebula-matrix.com>
Link: https://patch.msgid.link/20260914123429.56596-2-illusion.wang@nebula-matrix.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The 16-bit pause watermark register is little endian as
described in the ASIX 4.1.0 out-of-tree driver. Correct the
register byte sequence but also swap the configuration values
used in the code in order to keep the current behaviour.
The endianness is relevant for 16-bit writes to the register.
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Jianhui Xu <neuromoments@gmail.com>
Link: https://patch.msgid.link/20260916-ax88179a-v12-3-60c04c9924a2@birger-koblitz.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The 'priv' variable is defined before an #ifdef block but used inside
of it:
drivers/net/dsa/motorcomm/chip.c: In function 'yt921x_dsa_teardown':
drivers/net/dsa/motorcomm/chip.c:4229:29: error: unused variable 'priv' [-Werror=unused-variable]
Move it one line down.
Fixes: 9af9a81682 ("net: dsa: motorcomm: Add LED support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260915200148.3523045-1-arnd@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ip6gre_exit_rtnl_net() iterates ip6gre devices and variants whose
link_net is dying and queues them for destruction.
The devices may reside in different netns.
Let's use unregister_netdevice_queue_net() to support per-netns
device unregistration.
Even after ip6gre_exit_rtnl_net() queues a cross-netns ip6gre
device, ip6gre_changelink_common(), ip6gre_dellink(), and
ip6gre_tunnel_siocdevprivate() could be called concurrently for
it (once RTNL is removed). In such a case, __rtnl_net_unlock()
will perform the unregistration.
Also, ip6gre_tunnel_siocdevprivate() needs to check check_net(t->net),
otherwise it could create a new dev in dying netns after
ip6gre_exit_rtnl_net().
In the example below, we can see the fallback tunnel device
(ip6gre0) and the cross-netns device (ip6gre1) are unregistered
by different processes:
# bpftrace -e '#include <linux/netdevice.h>
kprobe:ip6gre_tunnel_uninit {
$dev = (struct net_device *)arg0;
printf("PID: %d | DEV: %s%s\n", pid, $dev->name, kstack());
}
kprobe:ip6gre_exit_rtnl_net {
printf("PID: %d%s\n", pid, kstack());
}' &
# ip netns add ns1
# ip netns add ns2
# ip -n ns1 link add name ip6gre1 link-netns ns2 \
type ip6gre local 2001:9292::1 remote 2001:9292::2
# ip netns del ns2
PID: 12
ip6gre_exit_rtnl_net+5
ops_undo_list+702
cleanup_net+1122
...
PID: 12 | DEV: ip6gre0 <------ fallback device (itn->fb_tunnel_dev).
ip6gre_tunnel_uninit+5
unregister_netdevice_many_notify+7137
unregister_netdevice_many_net+1050
__rtnl_net_unlock+37
ops_undo_list+754
cleanup_net+1122
...
PID: 10 | DEV: ip6gre1
ip6gre_tunnel_uninit+5
unregister_netdevice_many_notify+7137
unregister_netdevice_many_net+1050
rtnl_net_work_func+136
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260916230353.367014-7-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct ip6_tnl.net is the netns where encapsulated packets
flow into.
struct ip6_tnl is linked to ip6gre_net.tunnels[][] of netns.
During netns dismantle or module unload, ip6gre_exit_rtnl_net()
iterates the list and queues devices for destruction regardless
of the devices' netns.
Thus, once RTNL is removed, the list can be modified concurrently
from different netns due to device removal.
Let's protect it with per-netns mutex.
Note that dev_siocdevprivate() calls netdev_lock_ops() but
it must be NOP for tunnel devices to avoid AB-BA deadlock.
DEBUG_NET_WARN_ON_ONCE() is added to annotate the locking
explicitly.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260916230353.367014-6-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
With the previous patch, itn->fb_tunnel_dev can be removed
via ->dellink().
However, ioctl(SIOCDELTUNNEL) still uses unregister_netdevice(),
which requires ip6gre_tunnel_unlink() in ip6gre_tunnel_uninit().
Let's use __ip6gre_dellink() everywhere to remove ip6gre (and
variant) devices and remove ip6gre_tunnel_unlink() and
ip6gre_tunnel_unlink_md() in ip6gre_tunnel_uninit().
ip6erspan_tunnel_uninit() is also changed accordingly.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260916230353.367014-5-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ip6gre_dellink() ignores itn->fb_tunnel_dev, so the per-netns
fallback tunnel device cannot be removed by userspace.
This also makes default_device_exit_batch() impossible to remove
the device since it calls ->dellink().
So, ip6gre_exit_rtnl_net() has to iterate devices in the dying
netns and call unregister_netdevice_queue() directly, and
ip6gre_tunnel_unlink() must be called at ->ndo_uninit().
For per-netns device unregistration, we want to check if the
device is being removed in ->dellink(), for which we must call
ip6gre_tunnel_unlink() before unregister_netdevice_queue().
As a prep, let's set itn->fb_tunnel_dev to NULL and remove
remove for_each_netdev_safe() in ip6gre_exit_rtnl_net().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260916230353.367014-4-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct ip6_tnl has a pointer to the next one.
Single linked list requires O(n) iteration for device removal
and IPv4 tunnel already uses hlist for its hash table.
Let's convert ip6gre_net.tunnels[][] to hlist.
Once we convert other users (ip6_tunnel.c, sit.c), we can remove
the *next pointer from struct ip6_tnl.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260916230353.367014-3-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ip6gre_init_net() links the fallback device ip6gre0 to
ign->tunnels_wc[0] after publishing it by register_netdev().
While ip6_gre module is being loaded, there is a small race window.
If ioctl(SIOCADDTUNNEL) is called before ip6gre0 is linked to
the hash table, a new device could be linked to ign->tunnels_wc[0].
Then, the fallback device overwrites ign->tunnels_wc[0], and the new
device will be no longer found by ip6gre_tunnel_lookup(), resulting
in no RX.
Let's link the fallback device before register_netdev().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260916230353.367014-2-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tariq Toukan says:
====================
net/mlx5: more HWS misc enhancements
This series by Yevgeny brings more misc improvements to the mlx5 HWS
driver.
====================
Link: https://patch.msgid.link/20260915111912.3926585-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Remove the unneeded WRITE_ONCE, for two reasons:
a) This write is erroneous - it just writes to a local variable
and doesn't have any effect.
b) This code originated from another place (copy-paste bug),
where there was actually a CQ polling right after this line,
and the WRITE_ONCE was writing to another place.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Reviewed-by: Erez Shitrit <erezsh@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260915111912.3926585-7-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Handle a case in mlx5hws_send_stes_fw where
draining a queue fails with timeout.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Reviewed-by: Erez Shitrit <erezsh@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260915111912.3926585-6-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
HWS has a timeout mechanism for usual polling for completion,
but it was missing such a mechanism for draining the send queues.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Reviewed-by: Erez Shitrit <erezsh@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260915111912.3926585-5-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Linus Walleij says:
====================
net: dsa: microchip: Add support for KSZ8995XA/KS8995XA
This series breaks with the dated attempt to polish the old
KS8995 driver, and instead implement support for the KS8995XA
in the KSZ driver, and after that delete the old KS8995 driver.
The hardware clearly has the same ancestry, the KSZ8995XA is
just a rebrand of the much older Micrel KX8995XA switch.
The old driver identified the shared 0x95/0x0 ID as KS8995MA, but
this ID cannot distinguish MA from XA. No KS8995MA users are known,
and KS8995E has no documented SPI management interface. Neither
variant has been verified with the replacement driver.
Add new compatibles, add special code paths for the KSZ8995XA,
including support for its two-level DCB priority model, and add a
new tagger for the special front tag found in the KSZ8995XA.
The patches, including the per-port PHY reset polling, were tested
with the Actiontec MI424WR rev D (which has the KS8995XA) and
OpenWrt as userspace.
====================
Link: https://patch.msgid.link/20260916-ks8995-to-ksz8-v15-0-8825ff5fd4be@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Microchip KSZ driver now handles the KS(Z)8995XA. The old
driver identified the shared 0x95/0x0 ID as KS8995MA, but this ID
cannot distinguish MA from XA. No KS8995MA users are known, and
KS8995E has no documented SPI management interface. Neither variant
has been verified with the replacement driver.
The two in-tree device trees using the "micrel,ks8995" compatible:
arch/arm/boot/dts/intel/ixp/intel-ixp42x-linksys-wrv54g.dts
arch/arm/boot/dts/intel/ixp/intel-ixp42x-actiontec-mi424wr.dtsi
both use KS8995XA hardware and continue to be supported by the
replacement driver without regressions.
Delete the old driver, but leave a stub behind in Kconfig so new
users will be automatically phased over to the new symbol when
migrating their configs.
The old driver supports platform data (board file) instantiation,
but nothing in the kernel tree makes use of this legacy mechanism so
it is fine to delete.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260916-ks8995-to-ksz8-v15-4-8825ff5fd4be@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This adds support for the Microchip KSZ8995XA also known as the
Micrel KS8995XA switch to the KSZ driver.
The KSZ8995XA shares family ID 0x95 and chip-ID nibble 0x0 with
the KS8995MA, so hardware detection cannot distinguish them. The
legacy "micrel,ks8995" compatible is therefore treated as KSZ8995XA.
No KS8995MA users are known, and KS8995E has no documented SPI
management interface. Neither MA nor E has been verified with this
driver.
The helper macros are named ksz_is_ksz8995xa() to make it
possible to add E and MA support in the future.
Wait for the self-clearing per-port PHY reset bits before continuing
with switch setup. Poll each port for up to 600 ms and allow an
additional millisecond for the PHYs to settle.
The KSZ8995XA has eight global TOS priority registers with one
bit per DSCP code point, providing two internal priority levels.
The registers are ordered in the opposite direction from the
other KSZ8 switches. Describe the two priorities in the chip
data, then augment the DCB helpers for this.
Practical testing also shows that its packet-size control bits use
the same semantics as the other KSZ8 switches. The polarity in the
manual appears to be wrong and makes the switch hang on big packets.
The legacy KS8995 driver also matches the Micrel compatibles for
KSZ8864 and KSZ8795. Add these to the KSZ SPI driver here and use
an exact tristate dependency to make the drivers mutually exclusive.
This transfers ownership atomically, avoiding module probe races and
gaps in driver coverage between patches.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260916-ks8995-to-ksz8-v15-3-8825ff5fd4be@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KS8995 100Mbit switch can do proper DSA per-port tagging
with the proper set-up. This adds the code to handle ingress
and egress KS8995 tags.
The tagger is used by the KSZ8995XA support added later in this
series.
The tag is a modified 0x8100 ethertype tag where a bit in the
last nibble is set for each target port.
Always insert a distinct outer switch tag. User ports remove this
field on egress, so reusing an existing 802.1Q header would consume
the sender VLAN tag instead of preserving it.
Push any hardware-accelerated VLAN tag into the packet first. This
keeps the switch tag at offset 12 while retaining 802.1Q, 802.1ad and
stacked VLAN headers as inner payload, and avoids relying on a valid
SKB MAC header in direct transmit paths.
Rate-limit receive untagging errors so repeated failures cannot flood
the kernel log.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260916-ks8995-to-ksz8-v15-2-8825ff5fd4be@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ8995XA is just like the KSZ8795 and KSZ8864 a Micrel
product. It was renamed from KS8995XA to KSZ8995XA at some point,
but it has the same properties as the KS8995XA.
Be careful to use the full product name in this new compatible:
there is also KSZ8995MA and KSZ8995E which are not compatible
with the KS8995XA.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260916-ks8995-to-ksz8-v15-1-8825ff5fd4be@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
inet_unhash() sets inet_csk(sk)->unhashed_state only when the
socket is hashed because tcp_set_state(sk, TCP_CLOSE) could be
called multiple times, e.g. tcp_abort() calls it directly and
tcp_done_with_error().
However, inet_twsk_hashdance_schedule() also unhashes a socket
when replacing it with twsk, allowing the socket to bypass
checks for inet_csk(sk)->unhashed_state.
Let's update inet_csk(sk)->unhashed_state there as well.
Fixes: 8cc3aef0cb ("tcp: Do not allow buggy transitions between ehash and lhash2.")
Reported-by: Daniel Zahka <daniel.zahka@gmail.com>
Closes: https://lore.kernel.org/netdev/DLHLRA8GVI5B.2Q1IRQG5BVJNZ@gmail.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260917191554.1600494-1-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The phy_may_wakeup() documentation refers to
device_set_wakeup_enabled(), but the function is named
device_set_wakeup_enable(). Correct the reference.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260917063051.52727-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
PHY fixup registration is used from platform code in init phase only.
Let's move the PHY fixup code from the modular part of phylib to the
always built-in part of phylib. This allows to annotate the fixup
registration as __init. No caller uses the return code of PHY fixup
registration, therefore change related functions to return void.
phy_needs_fixup() and phy_scan_fixups() wouldn't have to be moved to
the built-in part of phylib. But doing so allows to fully factor out
legacy fixup support into its own source code file, and make struct
phy_fixup and phy_fixup_list strictly private to phy_fixup.c.
phy_scan_fixups() is used after init phase only, then phy_fixup_list
is read-only. So we don't need the mutex when accessing the list.
Also when registering PHY fixups the mutex isn't needed, because
fixup registration is done sequentially from platform init code.
Actually there is only one platform with more than one fixup.
In addition this change lays the foundation for enabling modular
phylib on platforms where the fixup just sets a flag.
Last but not least reflect the change in the documentation,
and add a hint that fixup's are legacy functionality.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://patch.msgid.link/2d722b84-a263-400b-ac91-bf37125eb85b@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
