In the following patch, we want to call rtnl_fill_prop_list() without
RTNL being held, but after a device reference was taken.
We need to free altnames in netdev_run_todo() instead of
unregister_netdevice_many_notify().
Freeing will only happen once all device references
have been released.
Note that dev->name_node serves as the anchor for altnames,
thus must be also freed in netdev_run_todo().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260525083542.1565964-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Avoid corrupting a netlink message and confuse user space in the
very unlikely case rtnl_fill_prop_list was able to produce a very big
nested element.
This is extremely unlikely, because rtnl_prop_list_size()
provisions nla_total_size(ALTIFNAMSIZ) per altname.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260525083542.1565964-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
cavium_ptp_get() acquires a reference to the PTP PCI device
through pci_get_device(). If any initialization step fails
after cavium_ptp_get(), the PTP PCI device reference is leaked.
Add a common error path to release the PTP reference before
returning from probe failures.
Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
Link: https://patch.msgid.link/20260525082611.61817-1-lihaoxiang@isrc.iscas.ac.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Supervision frames are only valid if terminated with a zero-length EOT
TLV. The current check fails to reject non-EOT entries as the terminal
TLV, potentially allowing malformed supervision traffic.
Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT with
a length of zero.
Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Link: https://patch.msgid.link/20260523130420.62144-1-luka.gejak@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJdBAABCABHFiEEgKkgxbID4Gn1hq6fcJGo2a1f9gAFAmoUkkcbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyDRxmd0BzdHJsZW4uZGUACgkQcJGo2a1f9gAFMhAA
qHgELYG9qfSiLidzoGX2vwp/J3ZZ4s2u4Ro+aK9kUvceavzTk9g2ZSoRmVrqQr5s
Z21rxPmNbQsE1N5c1Fh2LEMw0DuUNmGmb6g7pPO2OE/hal1rj0QzsH8zCIfl6xi/
1bJT9yAR2Z9DkPqWvW3kxDmeUqR8RJ4t1obzTtwdc/N2+DKpP3uWND7Sdf+SLfm9
5QBmGryP7MO0MB11xOGZPr8Vhk7P9auV6i2+BchaN6iQv4AavMq+QNrc1b9NpZpA
z+BDmpfrNDU7N2RsOe/AMehoBpSLn1er8k3moB+d39GRFaDHs6lZhP/KwgS5fVRw
NJ0LfWw3q/fBUkWuLlOfDJ7WtaVb+lU1CUsbcVuBrZx02WWjJbEcgzzWVQODtrCI
pLY8M6+eT2XE45pZmfcCQexIF6Qxok5x64jdhJlFxfUPqobSt1DLOAtDBqbTWx1U
WGRv/jsRTUxds7RnqcJE+OMhV6PyExxcY1Z3PqHEEn0iP8e6ozL0/qquXERjC4hz
loMz/mQeJ/EyyWk9Ioon7dE0oU2x/PYm1K4Do2DXxNY/gud/Mg81FsoZGOYD7gvG
5TYEuAF7Es6YWSl0KTypolORQqfre9hSHIToi7M271UuVzo0mDNmt493JvfjRTGe
h0fLSIvP3SGnGLeS9p3Vq1BzDQ9dyZ3mfh/K484KcPQ=
=bkBh
-----END PGP SIGNATURE-----
Merge tag 'nf-next-26-05-25' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next
Florian Westphal says:
====================
netfilter: updates for net-next
The following patchset contains Netfilter fixes and small enhancements:
1) Disable 32-bit x_tables compatibility (32bit binaries on 64bit
kernel) interface in user namespaces. This is 'last warning'
before this is removed for good.
2) Add a configuration toggle for netfilter GCOV profiling. Provide
dedicated toggles for ipset and ipvs.
3) Remove modular support for nfnetlink and restrict it to built-in only.
From Pablo Neira Ayuso.
4) Use per-rule hash initval in nf_conncount. This avoids unecessary
lock contention with short keys (e.g. conntrack zones) in different
namespaces.
5) Use nf_ct_exp_net() in ctnetlink expectation dumps.
From Pratham Gupta.
6) Remove a dead conditional in nft_set_rbtree.
7) Fix conntrack helper policy updates to apply per-class values correctly.
From David Carlier.
8) Fix an off-by-one OOB read in nf_conntrack_irc:parse_dcc(). Use strict
less-than comparison in the newline search loop to respect the
exclusive-end pointer convention. From Muhammad Bilal.
9) Fix typos in nf_conntrack_proto_tcp comments. From Avinash Duduskar.
10) Restore performance optimization in nft_set_pipapo_avx2 by passing
the next map index. Refactor lookup logic for clarity and add a
DEBUG_NET check to document this.
11) Avoid (harmless) u16 overflow in nf_conntrack_ftp when parsing FTP PORT
and EPRT commands. Ignore commands where single octet exceeds 255.
From Giuseppe Caruso.
Patch 12, which removes incorrect (and obviously unused) code from
nft_byteorder was kept back to avoid a net -> net-next merge conflict.
* tag 'nf-next-26-05-25' of https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
netfilter: nf_conntrack_ftp: avoid u16 overflows
netfilter: nft_set_pipapo_avx2: restore performance optimization
netfilter: nf_conntrack_proto_tcp: fix typos in comments
netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read
netfilter: nfnl_cthelper: apply per-class values when updating policies
netfilter: nft_set_rbtree: remove dead conditional
netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump
netfilter: nf_conncount: use per-rule hash initval
netfilter: allow nfnetlink built-in only
netfilter: add option for GCOV profiling
netfilter: x_tables: disable 32bit compat interface in user namespaces
====================
Link: https://patch.msgid.link/20260525182924.28456-1-fw@strlen.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
'struct configfs_item_operations' and 'configfs_group_operations' are not
modified in this driver.
Constifying these structures moves some data to a read-only section, so
increases overall security, especially when the structure holds some
function pointers.
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
64259 24272 608 89139 15c33 drivers/net/netconsole.o
After:
=====
text data bss dec hex filename
64579 23952 608 89139 15c33 drivers/net/netconsole.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/7ff56bdb0cee826a56365f930dcdf457b44931df.1779711734.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mlxsw_sp_fid_port_vid_list_add() inserts into a list sorted by
local_port. It walks the list to find the first entry with a
larger local_port, then inserts the new entry before it:
list_add_tail(&port_vid->list, &tmp_port_vid->list);
If the loop falls through (the new local_port is the largest),
tmp_port_vid runs off the end of the list. &tmp_port_vid->list
then ends up at the list head itself (container_of() offsets
cancel), and list_add_tail() inserts at the tail. So the code
works today.
It is fragile though. Anyone who later adds a read of another
field of tmp_port_vid will hit memory outside the list head.
Track the insertion point with a dedicated list_head pointer.
Initialise insert_before to &fid->port_vid_list, set it to
&tmp_port_vid->list only on early break, and pass insert_before
to list_add_tail(). The cursor is no longer touched after the
loop. Behaviour is unchanged.
Same shape as the Koschel cleanups from 2022 (e.g. 99d8ae4ec8
tracing, 2966a9918d clockevents, dc1acd5c94 dlm).
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260525071759.1517576-1-maoyixie.tju@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
NET_DSA_NETC_SWITCH selects NXP_NTMP, NXP_NETC_LIB and FSL_ENETC_MDIO,
but these symbols depend on NET_VENDOR_FREESCALE which may not be
enabled. This results in Kconfig warnings and linker errors like:
undefined reference to `ntmp_bpt_update_entry'
undefined reference to `ntmp_fdbt_search_port_entry'
undefined reference to `ntmp_free_cbdr'
undefined reference to `enetc_hw_alloc'
...
Therefore, add "depends on NET_VENDOR_FREESCALE" to NET_DSA_NETC_SWITCH,
ensuring that the selected symbols NXP_NTMP, NXP_NETC_LIB and
FSL_ENETC_MDIO, which all depend on NET_VENDOR_FREESCALE, can only be
selected when that dependency is already satisfied.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605240046.8MvKuOMg-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202605240706.EuGmnrz5-lkp@intel.com/
Fixes: 187fbae024 ("net: dsa: netc: introduce NXP NETC switch driver for i.MX94")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260524070310.2429819-1-wei.fang@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a test to check that temporary IPv6 address is regenerated properly
after the base prefix is deprecated and restored.
Fib6 temporary address renewal test
TEST: IPv6 temporary address cleanly deprecated and regenerated [ OK ]
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260523103811.3790-2-fmancera@suse.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When a router temporarily deprecates an IPv6 prefix (either by sending a
Router Advertisement with Preferred Lifetime = 0 or by letting the
lifetime expire) and later restores it, the kernel permanently loses its
ability to generate temporary privacy addresses (RFC 8981) for that
prefix.
This happens because the address worker attempts to generate a
replacement temporary address when the current one nears expiration. As
the base prefix is deprecated already, the generation fails after
marking the temporary address as already having spawned a replacement
(ifp->regen_count++).
When the router eventually restores the prefix, the temporary address
becomes active again. However, once it naturally expires, the address
worker sees this temporary address already tried to generate one and
skips the regeneration.
Fix the issue by resetting the regen_count check of the latest temp
address generated for the prefix updated by the incoming RA.
Reported-by: Łukasz Stelmach <steelman@post.pl>
Closes: https://lore.kernel.org/netdev/87340td30q.fsf%25steelman@post.pl/
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260523103811.3790-1-fmancera@suse.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Skip the extra call to napi->poll(), if the gro timer is armed at the
end of busy polling. This removes the need for having a separate
__busy_poll_stop() routine and its code is moved directly into the
relevant places in busy_poll_stop(). Remove obsolete comment about
ndo_busy_poll_stop().
This is a follow-up to commit 58e2330bd4 ("net: napi: Avoid gro timer
misfiring at end of busypoll"), which has deferred arming the gro timer
to the end of __busy_poll_stop() to eliminate a race condition between
a short timer and long poll that could leave the queue stuck with
interrupts disabled and no timer armed.
Co-developed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Martin Karsten <mkarsten@uwaterloo.ca>
Link: https://patch.msgid.link/20260523012247.1574691-1-mkarsten@uwaterloo.ca
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add appropriate SPDX-License-Identifier lines to llc header (.h)
files, and remove other license text from the files.
Signed-off-by: Tim Bird <tim.bird@sony.com>
Link: https://patch.msgid.link/20260523002354.28831-1-tim.bird@sony.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Most of the lls source files are missing SPDX-License-Identifier
lines. Add appropriate IDs to these files, and remove other license
info from the header. In once case, leave the existing id line
and just remove the license reference text.
Signed-off-by: Tim Bird <tim.bird@sony.com>
Link: https://patch.msgid.link/20260522225508.24006-1-tim.bird@sony.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Minxi Hou says:
====================
Add OVS packet family YNL spec and unicast notification support
This series adds a YAML netlink spec for the OVS_PACKET_FAMILY genetlink
family and a bind-only ntf_bind() helper for receiving unicast
notifications.
====================
Link: https://patch.msgid.link/20260522174154.720293-1-houminxi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add ntf_bind() method to YnlFamily for binding the netlink
socket without joining a multicast group. This enables receiving
unicast notifications through the existing poll_ntf/check_ntf
path.
The OVS packet family sends MISS and ACTION upcalls via
genlmsg_unicast() to a per-vport PID rather than through a
multicast group. The existing ntf_subscribe() couples bind()
with setsockopt(ADD_MEMBERSHIP), which does not fit the unicast
case. ntf_bind() provides the bind-only alternative, with the
address defaulting to (0, 0) but exposed as an explicit argument.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Link: https://patch.msgid.link/20260522174154.720293-3-houminxi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add YAML netlink spec for the OVS_PACKET_FAMILY (ovs_packet).
This completes the set of OVS genetlink family specs (ovs_datapath,
ovs_flow, ovs_vport already exist).
The spec defines three operations: MISS (event), ACTION (event),
and EXECUTE (do). MISS and ACTION are kernel-to-userspace upcalls
sent via genlmsg_unicast(); EXECUTE is the only registered genl
operation.
Key, actions, and egress-tun-key attributes are typed as binary
rather than nest because the nested attribute definitions belong
to the ovs_flow spec and cross-spec references are not supported
by the YNL framework.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Link: https://patch.msgid.link/20260522174154.720293-2-houminxi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The .driver_data member of the struct pci_device_id array were
initialized by a list expressions to zero without making use of that
value. In this case it's better to not specify a value at all and let
the compiler fill in the zeros. Same for the list terminator that can
better be completely empty.
This patch doesn't introduce changes to the compiled array.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Acked-by: Alexandra Winter <wintera@linux.ibm.com>
Link: https://patch.msgid.link/20260522153010.777081-2-u.kleine-koenig@baylibre.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Wei Fang says:
====================
net: enetc: Prepare for ENETC v4 VF support
This patch series refactors and extends the ENETC driver infrastructure
to prepare for upcoming ENETC v4 Virtual Function (VF) support. The main
focus is on code commonization, improved VF-PF communication, and dynamic
resource allocation.
The ENETC IP has evolved across different revisions, and the existing
driver architecture was primarily designed around v1 hardware. To support
v4 VFs efficiently, we need to share common code between PF drivers of
different IP versions while maintaining compatibility.
Key changes in this series:
1. VF-PF Messaging Infrastructure:
- Convert mailbox messages to new formats
- Use read_poll_timeout() for simplifying VF mailbox polling
- Add support for IP minor revision query via messaging
2. Code Commonization:
- Relocate SR-IOV configuration helpers to common PF code
- Move VF message handlers to dedicated enetc_msg.c
- Integrate enetc_msg.c into enetc-pf-common driver
3. CBDR (Control Buffer Descriptor Ring) Improvements:
- Align v1 CBDR API with v4 for VF driver sharing
- Add CBDR setup/teardown hooks to enetc_si_ops
4. Dynamic Resource Management:
- Dynamically allocate rxmsg based on actual VF count
- Use MADDR_TYPE constant for MAC filter array sizing
5. Generic SR-IOV Initialization:
- Add generic helper to initialize SR-IOV resources
This refactoring lays the groundwork for cleanly integrating ENETC v4 VF
support in subsequent patch series, allowing code reuse between v1 and v4
PF drivers while maintaining a clean separation of version-specific
logic.
v1: https://lore.kernel.org/imx/20260511080805.2052495-1-wei.fang@nxp.com/
====================
Link: https://patch.msgid.link/20260522092438.1264020-1-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The constant ENETC_MAX_NUM_VFS is defined as 2 when enabling support for
LS1028A. This works for LS1028A because its ENETC hardware supports up
to 2 VFs. However, ENETC v4 has varying VF capabilities depending on the
SoC:
i.MX94 standalone ENETC: 0 VFs
i.MX94 internal ENETC: 3 VFs
i.MX952: 1 VF
Using a fixed ENETC_MAX_NUM_VFS for memory allocation leads to
over-allocation on SoCs with fewer or no VF support. To better match
hardware capabilities and avoid unnecessary memory usage, change rxmsg
memory allocation from a fixed-size array to dynamic allocation based
on the actual VF count retrieved via pci_sriov_get_totalvfs().
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-13-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The mac_filter array in struct enetc_pf is sized as
ENETC_MAX_NUM_MAC_FLT, defined as (ENETC_MAX_NUM_VFS + 1) * MADDR_TYPE.
This resulted in an array of 6 elements (for 2 VFs), but only the first
2 entries are actually used.
The PF driver maintains MAC filters for unicast (UC) and multicast (MC)
addresses, indexed by the enum enetc_mac_addr_type (UC=0, MC=1). The
code only iterates over MADDR_TYPE (2) entries and directly accesses
mac_filter[UC] and mac_filter[MC]. The extra space allocated for
(ENETC_MAX_NUM_VFS * MADDR_TYPE) entries is never used because VF MAC
filtering is not implemented yet.
Remove the ENETC_MAX_NUM_MAC_FLT macro and size the array as
MADDR_TYPE, reducing the allocation from 6 to 2 entries. This saves 48
bytes per PF and better reflects the actual usage.
This change has no functional impact. Future VF MAC filtering support
will move mac_filter into struct enetc_si, allowing each SI (PF or VF)
to maintain its own independent filter table.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-12-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The upcoming ENETC v4 PF driver will support SR-IOV, and its logic for
initializing VF resources is identical to the existing ENETC v1 PF
implementation. To avoid code duplication across PF drivers, factor out
the common SR-IOV initialization logic into the enetc-pf-common driver.
Add enetc_init_sriov_resources() to handle:
- Querying the total number of VFs supported by the device via
pci_sriov_get_totalvfs()
- Allocating memory for the VF state array (struct enetc_vf_state)
The implementation uses devm_kcalloc() instead of kzalloc() to simplify
memory management. This automatically frees VF state memory when the PF
device is removed, eliminating the need for explicit cleanup in error
and remove paths.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-11-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The upcoming ENETC v4 VF will share the enetc-vf driver with the
existing v1 VF. However, ENETC v4 uses a revised CBDR (command BD ring)
setup/teardown API that differs from v1.
To support both versions in the same driver, add setup_cbdr() and
teardown_cbdr() function pointers to struct enetc_si_ops. This allows
each hardware version to register its own CBDR implementation:
- ENETC v1 VF registers enetc_setup_cbdr/enetc_teardown_cbdr (existing)
- ENETC v4 VF will register enetc4_setup_cbdr/enetc4_teardown_cbdr
Update the enetc-vf driver to call CBDR operations through si->ops
instead of directly invoking the v1 functions. This enables runtime
selection of the correct CBDR backend based on hardware version.
Changes:
- Add setup_cbdr() and teardown_cbdr() hooks to struct enetc_si_ops
- Register v1 CBDR functions in enetc_vsi_ops
- Replace direct calls with si->ops->setup_cbdr() and
si->ops->teardown_cbdr() in enetc_vf.c
No functional changes to existing v1 VF behavior.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-10-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The upcoming ENETC v4 VF will share the enetc-vf driver with the v1 VF.
However, ENETC v4 introduces different CBDR (command BD ring) setup and
teardown semantics that are incompatible with v1.
To support both versions in the same driver, the .setup_cbdr() and
.teardown_cbdr() hooks will be added to struct enetc_si_ops, allowing
the driver to register version-specific implementations. So refactor the
v1 CBDR functions to match the v4-style interface (taking struct enetc_si*
instead of individual parameters), enabling them to be registered via
si_ops in the subsequent patch.
Changes:
- Update enetc_setup_cbdr() and enetc_teardown_cbdr() prototypes to
take 'struct enetc_si *' as the sole parameter
- Extract parameters (dev, hw) from the enetc_si structure within the
function implementations
- ENETC_CBDR_DEFAULT_SIZE has always been used as the number of command
BDs, and there is no need to adjust the size of the command BD ring.
Therefore, ENETC_CBDR_DEFAULT_SIZE is moved into the enetc_setup_cbdr()
- Update all call sites in enetc_pf.c and enetc_vf.c
No functional changes. This prepares for adding v4-specific CBDR handling
in subsequent patches.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-9-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
For ENETC v4, different SoCs use different minor revisions, such as
i.MX95 v4.1, i.MX94 v4.3, and i.MX952 v4.6. Unlike the PF, the VF does
not have access to a global register that exposes the IP minor revision.
In the current driver model, the VF must select the appropriate driver
data based on this revision information.
To support this requirement, the VF now sends a minor revision query
message to the PF through the VSI-to-PSI mailbox mechanism. The PF
responds with the IP minor revision so that the VF can match the correct
driver data.
This patch adds PF-side support for replying to the minor revision
message and VF-side support for sending the query.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-8-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
On the LS1028A platform, the PF-VF mailbox was only used to update the
VF's MAC address. The original message format is minimal, lacks a clear
structure, and provides no means for the receiver to validate message
integrity, making it difficult to extend for new features.
With the introduction of i.MX ENETC v4, the interaction between PF and
VF has become significantly more complex. Typical deployments now include
scenarios where the PF is controlled by an M core while the VF is driven
by either the Linux kernel or DPDK, or where the PF is controlled by the
Linux kernel while the VF is controlled by DPDK. These heterogeneous
driver combinations require a unified and extensible message format to
ensure compatibility across different operating environments.
This patch introduces a newly defined PF-VF message structure and
converts the existing MAC-update mechanism to use the new format. The
redesigned message layout provides:
- extensibility to support future PF-VF features on ENETC v4,
- consistent framing for all message types,
- improved data integrity checking,
- a common protocol usable across Linux, M core firmware, and DPDK.
Additional PF-VF message types will be added in subsequent patches.
Note that switch to the new message format will not affect ENETC v1
(LS1028A). Due to a hardware limitation of ENETC v1, the ENETC PF and
VFs can only be controlled by the same OS. If the PF is controlled by
the Linux kernel driver, then the VFs must also be controlled by the
Linux kernel driver.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-7-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Replace the manual do-while polling loop in enetc_msg_vsi_send() with
the standard read_poll_timeout() helper to simplify the code.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-6-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move enetc_msg.c from the fsl-enetc driver to the nxp-enetc-pf-common
driver so that SR-IOV mailbox handling can be shared between ENETC v1
and v4 PF drivers.
Changes:
- Move enetc_msg.o compilation from fsl-enetc to nxp-enetc-pf-common
- Export enetc_sriov_configure() with EXPORT_SYMBOL_GPL for use by
both PF drivers
The fsl-enetc driver now depends on nxp-enetc-pf-common for SR-IOV
functionality.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-5-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move enetc_sriov_configure() from enetc_pf.c to enetc_msg.c to prepare
for integrating enetc_msg.c into the enetc-pf-common driver, where it
will be shared between ENETC v1 and v4 PF drivers.
Since enetc_msg_psi_init() and enetc_msg_psi_free() are now only called
from enetc_sriov_configure() within the same file, make them static.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-4-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move enetc_msg_pf_set_vf_primary_mac_addr() and enetc_msg_handle_rxmsg()
to enetc_msg.c to consolidate VF mailbox message handling logic.
Make enetc_msg_handle_rxmsg() static since it's only called from
enetc_msg_task() within the same file.
This prepares for integrating enetc_msg.c into the enetc-pf-common
driver to be shared between ENETC v1 and v4 PF drivers.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-3-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Replace enetc_pf_set_primary_mac_addr() with the generic
enetc_set_si_hw_addr() function. This prepares for moving
enetc_msg_pf_set_vf_primary_mac_addr() to the enetc-pf-common driver,
where it can be shared between ENETC v1 and v4 PF drivers.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20260522092438.1264020-2-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
There is no register access anymore in
mv88e6352_g2_scratch_port_has_serdes. So, remove the locks
surrounding the function.
Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com>
Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com>
Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com>
Link: https://patch.msgid.link/20260521202924.727929-5-fidan.aliyeva.ext@ericsson.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
1. Refactor mv88e6352_g2_scratch_port_has_serdes to use the cached
scratch config3 value instead of reading it everytime.
2. Remove err<0 check from mv88e6352_phylink_get_caps as it is never
true anymore
Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com>
Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com>
Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com>
Link: https://patch.msgid.link/20260521202924.727929-4-fidan.aliyeva.ext@ericsson.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Changes:
1. Add g2_scratch_config3 member to mv88e6xxx_chip.
2. Add mv88e6352_g2_cache_global_scratch_config3 which reads the
CONFIG3 value from the scratch register and caches it.
3. Call this function in mv88e6352_reset.
Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com>
Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com>
Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com>
Link: https://patch.msgid.link/20260521202924.727929-3-fidan.aliyeva.ext@ericsson.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
1. Add mv88e6352_reset which calls the previous ops->reset function
- mv88e6352_g1_reset.
2. Make all 6352 family use this new function as ops->reset
Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com>
Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com>
Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com>
Link: https://patch.msgid.link/20260521202924.727929-2-fidan.aliyeva.ext@ericsson.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Markus Stockhausen says:
====================
net: mdio: realtek-rtl9300: Groundwork for multi SOC support
The Realtek Otto switch platform consist of four different series
- RTL838x aka maple : 28 port 1G Switches
- RTL839x aka cypress : 52 port 1G Switches
- RTL930x aka longan : 28 port 1G/2.5G/10G Switches
- RTL931x aka mango : 56 port 1G/2.5G/10G Switches
The existing realtek-rtl9300 MDIO driver was only designed for RTL930x
devices. The three other SOCs are not supported although they basically
incorporate a very similar MDIO controller.
This series is the first step in a multi-stage approach to also support
the missing SOCs. Device specific properties and registers are converted
into designated initializers. Based on this new devices can be added
much easier in future commits.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
====================
Link: https://patch.msgid.link/20260521175918.1494797-1-markus.stockhausen@gmx.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The MDIO controller registers of the different devices of the
Realtek Otto switch series are very similar. Nevertheless each
device will need to feed the whole command data distributed over
the controller registers slightly different.
E.g. the combined C22/command register has different field layouts.
On RTL930x bits 24-20 define the to-be-accessed C22 register number
while on RTL839x this is stored in bits 9-5.
Thus there need to be device specific read/write functions that
are called dynamically. Add them into the info structure and make
use of them where needed.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260521175918.1494797-10-markus.stockhausen@gmx.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
MDIO controller commands work on ports. These are converted by
the driver and hardware forth and back to bus/address. For write
commands a port mask register needs to be filled. Each bit tells the
controller to which PHY the write will be issued. Setting multiple
bits allows to program multiple PHYs in one step. The driver will
not make use of this parallel write feature. But it must at least
fill the bit of the target port that it wants to write to.
Depending on the SOC type and the number of supported PHYs this is
either one or two 32 bit port mask registers. The driver currently only
supports the 28 port RTL930x SOCs. So provide only the mask register
for the lower 32 ports. Add it to the register structure and make use
of it where needed.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260521175918.1494797-9-markus.stockhausen@gmx.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The MDIO data that needs to be written or read to registers of the
controller is handled by an I/O register. Add that to the register
structure and make use of it where needed.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260521175918.1494797-8-markus.stockhausen@gmx.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Command issuing/status bits and C22 data share the same register. In the
future the number of places where this register is used will be:
- One generic command helper/runner for all devices that will access the
command bits of the register
- 8 device specific C22 read/write functions that will access the C22
data fields.
Thus name the register c22_data to align with the existing c45_data
register. This way all device specific helpers will have a common
view on the to-be-fed data. Add the register to the existing structure
and make use of it where needed.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260521175918.1494797-7-markus.stockhausen@gmx.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The MDIO controller of the Realtek Otto switches has either 4 or 7 command
registers. This depends on the number of supported ports. These registers
are "scattered" around the MMIO block and their addresses depend on the
specific model.
Nevertheless all command registers share a common pattern:
- A mask register with one bit per addressed port
(remark: the driver internally works on ports instead of bus/address)
- A I/O data register that transfers the to be read/written data
- A C45 registers that takes devnum and regnum
- A C22 register that also includes run and status bits
(remark: this also takes the Realtek proprietary C22 PHY page)
Provide an additional structure for these command registers so it can be
reused in two places.
1. For defining the register addresses in the regmap.
2. For defining the to be read/written register data
This will finally result in access patterns like
static int otto_emdio_run_cmd(u32 cmd,
struct rtl_mdio_cmd_regs *cmd_regs, ...)
{
regmap_write(regmap, priv->info->reg->cmd_regs.c45_data,
cmd_regs->c45_data);
...
}
static int otto_emdio_9300_write_c45(...)
{
struct otto_emdio_cmd_regs cmd_regs = {
.c45_data = ...
.io_data = ...,
.port_mask = ...,
};
return otto_emdio_run_cmd(RTL9300_CMD_WRITE_C45, &cmd_regs, ...);
}
As a first step start with the C45 register. This one takes the
devnum/regnum data that is stored in the high/low 16 bits.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260521175918.1494797-6-markus.stockhausen@gmx.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The Realtek ethernet MDIO controller has a proprietary paging feature
that is closely aligned with Realtek based PHYs. These PHY know "pages"
for C22 access. Those can be switched via reads/writes to register 31.
Usually the paged access must be programmed in four steps.
1. read/save page register
2. change "page" register 31
3. read/write data register (on the given page)
4. restore page register
The controller can run all this in hardware with one single request
from the driver. It is given the page, the register and the data
and takes care of all the rest. This reduces CPU load. The number
of supported pages depend on the model. This is either 4096 for low
port count SOCs (up to 28 ports) or 8192 for high port count SOCs
(up to 56 ports).
There is however one special page that allows to pass through all C22
commands directly to the PHY - without any caching. This so called raw
page is dependent of the hardware. It is the highest supported page
number minus 1.
Provide the number of supported pages as a device specific property.
This new "num_pages" aligns with the existing properties and gives
an better insight into the hardware layout than just defining the
number of the raw page. The later directly derives from that and
can be accessed with the new RAW_PAGE() macro. Make use of it where
needed.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260521175918.1494797-5-markus.stockhausen@gmx.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The ethernet MDIO controller in the Realtek Otto series has a very special
command register style. Instead of working with bus/address it works on
ethernet port numbers. For this the controller is initialized via mapping
registers that tell which port is mapped to which bus/address. Every
request to the driver is then converted as follows
1. Kernel calls driver with bus/address
2. Driver converts bus/address to port and issues command
3. Hardware maps port back to bus/address
The number of ports is different for each device. Make this configurable
by adding a property to the info structure. Switch the existing usage of
MAX_PORTS to this new property where needed.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260521175918.1494797-4-markus.stockhausen@gmx.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Device properties of the RTL930x SOCs are hardcoded into the MDIO driver.
This must be relaxed to support additional devices like the RTL838x or
RTL839x. These do not have 4 SMI buses but 1 or 2 instead.
To support multiple devices establish an info structure that contains
individual variations of each series. As a first use case add the number
of buses into this structure and use it where needed.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260521175918.1494797-3-markus.stockhausen@gmx.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The Realtek ethernet MDIO driver currently only serves SOCs from the
Realtek RTL930x series. This is only one lineup of the Realtek Otto
switch series that also knows RTL838x, RTL839x, RTL931x devices.
All of these share similar hardware with comparable MMIO access logic
but have individual variations. Important to note
- Controller works on switch ports instead of buses and addresses.
- Devices incorporate additional MDIO hardware. E.g.
- an auxiliary MDIO controller for GPIO expanders [1]
- a MDIO style SerDes controller [2]
To avoid future confusion enhance the driver documentation and
function naming. Make clear what this driver is about and what
parts are generic and what parts are device specific. For this
rename the function and structure prefix as follows:
- for generic functions use otto_emdio_
- for device specific helpers use e.g. otto_emdio_9300_
This prefix naming tries to align with the watchdog timer [3].
It paves the way so that drivers for the other Realtek Otto MDIO
controllers can be added in future commits using the same naming
convention.
Remark 1: The read/write functions are kept device specific for now
because they will only fit the RTL930x SOCs. Renaming will take place
as soon as the I/O handling will be generalized.
Remark 2: The driver name "mdio-rtl9300" is kept for now.
[1] https://git.openwrt.org/openwrt/openwrt/tree/target/linux/realtek/patches-6.18/723-net-mdio-Add-Realtek-Otto-auxiliary-controller.patch
[2] https://git.openwrt.org/openwrt/openwrt/tree/target/linux/realtek/files-6.18/drivers/net/mdio/mdio-realtek-otto-serdes.c
[3] https://elixir.bootlin.com/linux/v7.0/source/drivers/watchdog/realtek_otto_wdt.c
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://patch.msgid.link/20260521175918.1494797-2-markus.stockhausen@gmx.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The 'dpaa2_ethtool_stats' and 'dpaa2_ethtool_extras' structures are
initialized in their declarations and never changed. So, constify them
to reduce the attack surface.
Before the patch (size dpaa2-ethtool.o):
text data bss dec hex
33433 5992 0 39425 9a01
After the patch (size dpaa2-ethtool.o):
text data bss dec hex
34937 4488 0 39425 9a01
Signed-off-by: Len Bao <len.bao@gmx.us>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Link: https://patch.msgid.link/20260523150737.36988-1-len.bao@gmx.us
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ratheesh Kannoth says:
====================
octeontx2-af: npc: Enhancements. [part]
Patch 1 reduces stack usage in mlx5e_pcie_cong_get_thresh_config()
by reusing a single union devlink_param_value across four
devl_param_driverinit_value_get() calls (instead of
union devlink_param_value val[4] on the stack) and assigning each
vu16 into mlx5e_pcie_cong_thresh, so the helper stays under the
frame-size warning limit as the union grows.
Patch 2 changes devlink_nl_param_value_put() and
devlink_nl_param_value_fill_one() to pass union devlink_param_value
by pointer instead of by value. Passing two copies of the union
by value in the param netlink path consumes over 500 bytes of argument
stack and risks CONFIG_FRAME_WARN as the union grows beyond its
historical size.
====================
Picking a couple of uncontroversial changes from the series
since it's making very slow progress.
Link: https://patch.msgid.link/20260521095303.2395584-1-rkannoth@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
union devlink_param_value grows substantially once U64 array
parameters are added to devlink (from 32 bytes to over 264 bytes).
devlink_nl_param_value_fill_one() and devlink_nl_param_value_put()
copy the union by value in several places. Passing two instances as
value arguments alone consumes over 528 bytes of stack; combined with
deeper call chains the parameter stack can approach 800 bytes and trip
CONFIG_FRAME_WARN more easily.
Switch internal helpers and exported driver APIs to pass pointers to
union devlink_param_value rather than passing the union by value.
Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw
Acked-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Arthur Kiyanovski <akiyano@amazon.com> #for ena
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Link: https://patch.msgid.link/20260521095303.2395584-4-rkannoth@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
union devlink_param_value grew when U64 array parameters were added.
Keeping union devlink_param_value val[4] in
mlx5e_pcie_cong_get_thresh_config() exceeded the compiler's
-Wframe-larger-than limit.
Reuse one union: call devl_param_driverinit_value_get() once per
MLX5 PCIe congestion threshold and assign each vu16 to the
corresponding mlx5e_pcie_cong_thresh member.
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
Link: https://patch.msgid.link/20260521095303.2395584-3-rkannoth@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
