An unset local_ip is auto-populated from the egress interface at enable
time, but any value the user writes, including 0.0.0.0, is used as-is.
This deviates from the behavior prior to "netconsole: use the address
family instead of the ipv6 flag", which interpreted 0.0.0.0 as unset.
Document this so the distinction between "unset" and "set to 0.0.0.0" is
clear.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-7-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The struct inet_addr lives in netpoll.h, but since commit a111639647
("netconsole: move local_ip/remote_ip/ipv6 to netconsole_target") the
only user is netconsole. Move the definition into netconsole.c
Suggested-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-6-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
An unset address (local_ip/remote_ip), now denoted by AF_UNSPEC,
currently shows "0.0.0.0" in configfs. Print an empty string instead,
which is more clear.
In netconsole_print_banner() we can be even more explicit about it, as
we don't have the risk of userspace trying to parse it.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-5-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The local_ip and remote_ip configfs attributes are written independently
and nothing stops a user from mixing ipv4 and ipv6. This leads to an
ipv4 address being zero-extended into an ipv6 header or an ipv6 address
being truncated to its first 4 bytes for an ipv4 header.
The command-line parser already refuses such a mismatch. This adds a
similar check when a dynamic target is being enabled.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-4-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The command-line path already requires a remote address, but if a user
creates a dynamic target and enables it without setting a remote
address, we currently try sending netconsole traffic to "0.0.0.0".
Refuse to enable a target if the remote address is unset.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-3-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that we have the address family in inet_addr, use that and remove
nt->ipv6.
We no longer need netcons_local_ip_unset() to check that all bytes are
zeroes, as that is now denoted by (family == AF_UNSPEC).
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-2-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netconsole_target stores a single 'bool ipv6' to denote the target's
address family. This makes it hard to detect conditions like "no address
set" or ipv4/ipv6 mixup between local_ip and remote_ip.
Add a 'family' field to inet_addr so each address stores its own address
family: AF_UNSPEC while unset, else AF_INET or AF_INET6.
Nothing reads the new field yet. The next patch switches the users over
and removes the bool. No functional change.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-1-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct sk_key does not exist; the type is struct mctp_sk_key.
Use it.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260905095150.42180-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct netdevice does not exist; the type is struct net_device.
Use it.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260905095116.42147-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jan Havran says:
====================
net: dsa: lantiq_gswip: SGMII/2500BASE-X and flow-control fixes
This series fixes three issues in the lantiq_gswip / mxl-gsw1xx DSA driver
found while bringing up a MaxLinear GSW145 over SGMII on a Marvell
Armada 7040 board, with the switch CPU port running 2500BASE-X and the
user ports at 1000BASE-T.
Patch 1 reorders the SerDes NCO clock-rate setup ahead of the SGMII shell
reset. Without it, only the rate the switch was left at by the straps or
the boot loader links up; the other rate comes up but forwards no traffic.
Patch 2 adds the missing SPEED_2500 case to gswip_port_set_speed(); without
it the CPU port was forced to 10 Mbps at 2.5G link-up.
Tested on GSW145 hardware only. The register values are backed by the
public GSW145 data sheet and by the driver's own field encoding; the
xRX200/xRX300 data sheets are not public.
====================
Link: https://patch.msgid.link/20260907134818.16670-1-havran.jan@email.cz
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The mxl-gsw1xx driver advertises 2500BASE-X on its SGMII port (via
supports_2500m and gsw1xx_phylink_get_caps()), but the shared
gswip_port_set_speed() has no SPEED_2500 case: at 2.5G every field keeps
its initializer, so mdio_phy = 0 pins the MDIO speed override to 10 Mbps
and no data passes.
At the MAC/MDIO level 2500BASE-X is identical to 1 Gbps (same wide GMII
datapath, same speed override); the rate itself is set in the PCS and
SerDes, not here. This matches the boot loader's PHY_ADDR_4 = 0x32A4 for
the 2.5G strap ("1 Gbps or above"), whose SPEED field is
GSWIP_MDIO_PHY_SPEED_G1 (the field has no encoding above G1). Share the
SPEED_1000 arm via a stacked case label. Its mii_cfg value is a no-op
for 2.5G: gswip_mii_mask_cfg() writes it only for the RGMII port
(mii_cfg[SGMII port] == -1), which cannot reach 2.5G anyway.
Cc: stable+noautosel@kernel.org # never worked
Signed-off-by: Jan Havran (Advantech Czech) <havran.jan@email.cz>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260907134818.16670-3-havran.jan@email.cz
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gsw1xx_pcs_config() releases the SGMII shell from reset via
gsw1xx_pcs_reset() and only afterwards programs NCO_CTRL to select the
SerDes clock rate (1G NCO1 vs 2.5G NCO2). The chip boot loader uses the
other order: NCO_CTRL -> RST_REQ -> SGMII_PHY_HWBU_CTRL (GSW145 data
sheet, section 3.2.8, table 13).
Program NCO_CTRL before gsw1xx_pcs_reset() to follow that order. On an
Armada 7040 board driving a GSW145 whose switch comes up at 2.5G (pin strap
PS_SUBTYPE_MD[2] = 1, pin LED42 / PS1 bit 14; GSW145 data sheet tables 23
and 25), a 1 Gbps SGMII link only carried traffic with this change. It
matters when the rate the switch is left at - by the straps or by the boot
loader - differs from the rate the driver selects, which is likely why it
has not been seen before.
Cc: stable+noautosel@kernel.org # never worked
Signed-off-by: Jan Havran (Advantech Czech) <havran.jan@email.cz>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260907134818.16670-2-havran.jan@email.cz
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The LED core defines delay_on == 0 as steady off and delay_off == 0 as
steady on, which was treated as a blink in our LED driver. Fix it.
Fixes: 9af9a81682 ("net: dsa: motorcomm: Add LED support")
Signed-off-by: David Yang <mmyangfl@gmail.com>
Link: https://patch.msgid.link/20260904134752.635133-1-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Drop repeated words reported by checkpatch.pl. Only touches
documentation text.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20260907095446.27290-5-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix a typo in comments, found with scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20260907095446.27290-4-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix typos in comments, found with scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20260907095446.27290-3-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix typos in comments, found with scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20260907095446.27290-2-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In case iproute2 is older than version 5.11.0, released ~Feb 23, 2021,
the vrftable support is not available and the tests
contained in the following 2 test files
- srv6_end_dt4_l3vpn_test.sh
- srv6_end_dt6_l3vpn_test.sh
are failing in some kernel backports.
This is the result of one of those tests in an unsupported environment:
##########################################################################
TEST SECTION: SRv6 VPN connectivity test among hosts in the same tenant
##########################################################################
TEST: Hosts connectivity: hs-t100-1 -> hs-t100-2 (tenant 100) [FAIL]
TEST: Hosts connectivity: hs-t100-2 -> hs-t100-1 (tenant 100) [FAIL]
TEST: Hosts connectivity: hs-t200-3 -> hs-t200-4 (tenant 200) [FAIL]
TEST: Hosts connectivity: hs-t200-4 -> hs-t200-3 (tenant 200) [FAIL]
The test installs a route with the vrftable feature; if this feature is
not available, the approach taken is to skip the test rather than
failing it.
Signed-off-by: Alessio Faina <alessio.faina@canonical.com>
Reviewed-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Link: https://patch.msgid.link/20260907100631.1923148-1-alessio.faina@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski says:
====================
dpll: fix lies in the Netlink spec
Clashiko started accumulating pre-existing issues in specs so I did
a scan of the families. This set fixes issues discovered in dpll.
====================
Link: https://patch.msgid.link/20260904191023.3869690-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
get_maintainer.pl on Documentation/netlink/specs/dpll.yaml returns only
the YNL and NETWORKING [GENERAL] entries, so a change to the DPLL uAPI
description does not CC any of the DPLL maintainers. Ten other families
(binder, dev-energymodel, ethtool, handshake, mptcp_pm, ovpn, psp,
team, wireguard, rt-*) already list their spec explicitly.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260904191023.3869690-5-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The op doc promises "dump request with target dpll - list all the pins
registered with a given dpll device" and "do request with target dpll
and target pin". Neither exists. pin-get uses attribute-set: pin, so
the id in both requests is DPLL_A_PIN_ID, not a device id; there is no
reachable "target dpll" attribute at all (DPLL_A_PIN_PARENT_ID is in
neither list). dpll_nl_pin_get_dumpit() does not look at the request,
it walks dpll_pin_xa from ctx->idx and emits every registered,
available pin, and there is no dump start callback to consume an id
either.
So the generated dpll_pin_get_dump() sends an id, gets the full list
back and reports no error. Drop the id from the dump request and the
two targeting claims from the doc.
Present since commit 3badff3a25 ("dpll: spec: Add Netlink spec in
YAML").
Same caveat as for pin-set: sending DPLL_A_PIN_ID in a pin-get dump now
fails validation instead of being ignored.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260904191023.3869690-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
pin-set advertises top level direction, prio and state, so the
generated policy accepts them and the generated user space API grows
setters for them. dpll_pin_set_from_nlattr() has cases only for
FREQUENCY, PHASE_ADJUST, PARENT_DEVICE, PARENT_PIN, ESYNC_FREQUENCY and
REFERENCE_SYNC - the request succeeds, does nothing and produces no
extack. The three values are only actionable inside the parent-device
nest, where dpll_pin_parent_device_set() handles them next to
DPLL_A_PIN_PARENT_ID, which is what makes them meaningful: a pin can be
registered with more than one device.
Never implemented - "git log -S 'case DPLL_A_PIN_PRIO'" on
dpll_netlink.c comes up empty - the spec has advertised them since
commit 3badff3a25 ("dpll: spec: Add Netlink spec in YAML").
Note that this does change what the kernel accepts: sending one of the
three now fails validation instead of being ignored.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260904191023.3869690-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dpll_device_get_one() calls dpll_msg_add_clock_quality_level(), which
puts DPLL_A_CLOCK_QUALITY_LEVEL into every device-get reply, dump entry
and device-*-ntf of a device whose driver implements
clock_quality_level_get() - mlx5 does. The &dev-attrs anchor lists 12
attributes and not this one, so struct dpll_device_get_rsp has no field
for it, dpll_device_get_rsp_parse() drops it and dpll.rst does not
document it.
The attribute itself is correctly declared in the dpll attribute set,
only the reply list was missing an entry. Missing since commit
a1afb959ad ("dpll: add clock quality level attribute and op").
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260904191023.3869690-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
"max" is the exclusive upper bound of enum handshake_handler_class, not
a class a handler can ask for, but the spec lists it as a plain entry.
_init_checks() derives the policy limit from the highest entry, so the
generated policy came out as NLA_POLICY_MAX(NLA_U32, 2) and
handshake_nl_accept_doit() takes class 2 all the way into
handshake_req_next(), which walks hn_requests under hn_lock before
returning -EAGAIN instead of the -EINVAL a bad class deserves.
render-max is how YNL spells this, and unlike a hand written limit it
stays correct when a second handler class is added.
It does change what HANDSHAKE_HANDLER_CLASS_MAX means - the highest
valid class rather than one past it, as in every other Netlink/YNL
family - with the count left as __HANDSHAKE_HANDLER_CLASS_MAX.
The constant is uAPI, but I could not find any user space user,
this constant seems to have been added for kernel's benefit.
I think the risk of changing this is worth taking, having MAX
with different semantics than the rest of Netlink is very confusing.
Acked-by: Chuck Lever <cel@kernel.org>
Reviewed-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Link: https://patch.msgid.link/20260904190410.3864660-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
include/linux/key.h has "typedef int32_t key_serial_t" and commit
160f404495 ("handshake: Fix sign of key_serial_t fields") converted
x509.cert and x509.privkey to s32, but accept.peer-identity,
accept.keyring and done.remote-auth were left as u32 - the same
quantity typed both ways inside one family, and a generated user space
struct with __s32 cert next to __u32 keyring. All three come from
key_serial_t storage in net/handshake/tlshd.c (treq->th_peerid[],
treq->th_keyring), and special keyrings are legitimately negative
(KEY_SPEC_PROCESS_KEYRING is -2).
NLA_U32 and NLA_S32 have the same length and no range check here, so
the only wire effect is how the value is printed.
Acked-by: Chuck Lever <cel@kernel.org>
Reviewed-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Link: https://patch.msgid.link/20260904190410.3864660-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Matthieu Baerts says:
====================
selftests: net: use KHDR_INCLUDES in CFLAGS
KHDR_INCLUDES is typically used to include headers from the kernel
source directory instead of only relying on the ones from the host: they
can be missing or outdated. See the issue reported in [1] where users
have to set USERCFLAGS instead, which shouldn't be needed.
The kselftest doc [2] recommends assigning KHDR_INCLUDES to CFLAGS in a
target Makefile. lib.mk will set KHDR_INCLUDES to "-isystem
$(top_srcdir)/usr/include" if the user didn't set it, e.g. if the kernel
was built in a different build directory.
Other net targets have KHDR_INCLUDES added to their CFLAGS.
Link: https://lore.kernel.org/275ba183-49fd-45b1-881d-0f362b4c74c0@ovn.org [1]
Link: https://docs.kernel.org/dev-tools/kselftest.html#contributing-new-tests-details [2]
====================
Link: https://patch.msgid.link/20260904-net-sft-nf-khdr_includes-v1-0-92455af428e9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KHDR_INCLUDES is typically used to include headers from the kernel
source directory instead of only relying on the ones from the host: they
can be missing or outdated.
The kselftest doc recommends assigning KHDR_INCLUDES to CFLAGS in a
target Makefile. lib.mk will set KHDR_INCLUDES to "-isystem
$(top_srcdir)/usr/include" if the user didn't set it, e.g. if the kernel
was built in a different build directory.
Other net targets have KHDR_INCLUDES added to their CFLAGS.
Link: https://docs.kernel.org/dev-tools/kselftest.html#contributing-new-tests-details
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
Link: https://patch.msgid.link/20260904-net-sft-nf-khdr_includes-v1-2-92455af428e9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KHDR_INCLUDES is typically used to include headers from the kernel
source directory instead of only relying on the ones from the host: they
can be missing or outdated.
The kselftest doc recommends assigning KHDR_INCLUDES to CFLAGS in a
target Makefile. lib.mk will set KHDR_INCLUDES to "-isystem
$(top_srcdir)/usr/include" if the user didn't set it, e.g. if the kernel
was built in a different build directory.
Other net targets have KHDR_INCLUDES added to their CFLAGS.
Link: https://docs.kernel.org/dev-tools/kselftest.html#contributing-new-tests-details
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
Link: https://patch.msgid.link/20260904-net-sft-nf-khdr_includes-v1-1-92455af428e9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test requires at least two CPUs to exercise the distribution of
connections between per-CPU listeners. It currently enforces this
prerequisite with an assertion, causing all test cases to fail on
single-vCPU systems even though no kernel functionality was tested.
Report the unsupported environment as a skip instead. Check the
prerequisite before setting up the network namespace so skipped tests do
not make unnecessary system changes.
Link: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2023546
Signed-off-by: Kuba Pawlak <kuba.pawlak@canonical.com>
Link: https://patch.msgid.link/20260904140334.562593-1-kuba.pawlak@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Drop the second 'to', reported by checkpatch.pl as a possible repeated
word. Only touches a comment, no code changes.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260907063804.26581-1-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Andrei Gherzan says:
====================
netdevsim: fix IPsec debugfs byte order
The netdevsim IPsec debugfs file (used by selftests/net/rtnetlink.sh's
ipsec_offload subtest) prints the SA salt and key in host CPU byte
order instead of network byte order, because nsim_sa.key[]/salt are
typed as plain u32 and printed directly with "%08x". This makes the
reported values differ between little-endian and big-endian hosts for
the same underlying key material, and breaks the selftest on
big-endian (e.g. s390x), which hardcodes the little-endian output.
A driver-side fix was proposed in 2022 but stalled in review: keeping
the fields as plain u32 meant sparse could not validate the added
ntohl()/be32_to_cpu() conversions.
https://lore.kernel.org/20220308135106.890270-1-kleber.souza@canonical.com
====================
Link: https://patch.msgid.link/20260908140325.13367-1-andrei.gherzan@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The previous patch ("netdevsim: print IPsec salt/key in network byte
order") makes the netdevsim IPsec debugfs file print salt/key in
network byte order on every host, instead of host CPU byte order.
Update the expected output of kci_test_ipsec_offload() to match: the
values change from the little-endian-only representation to the new,
endianness-independent one. No other changes are needed since the
output is now the same on every architecture.
This depends on the previous driver patch: applied on its own, this
change would regress the test on little-endian hosts (which still
print the old host-order value), though it happens to have no effect
on big-endian hosts (whose old host-order output already matched).
Reported-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Link: https://lore.kernel.org/netdev/20220308135106.890270-1-kleber.souza@canonical.com/
Signed-off-by: Andrei Gherzan <andrei.gherzan@canonical.com>
Link: https://patch.msgid.link/20260908140325.13367-3-andrei.gherzan@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
nsim_sa.key[] and nsim_sa.salt hold raw key material in network byte
order, but are typed as plain u32 and printed with "%08x" in the
debugfs read handler. This prints host-endian, so output differs
between little- and big-endian hosts for the same key:
little-endian: salt=0x61626364 key=0x34333231 38373635 32313039 36353433
big-endian: salt=0x64636261 key=0x31323334 35363738 39303132 33343536
This breaks selftests/net/rtnetlink.sh's ipsec_offload subtest on
big-endian (e.g. s390x), which hardcodes the little-endian output.
Retype key[]/salt to __be32, matching ipaddr[], and convert with
be32_to_cpu() before printing. Output is now network-order on every
host, independent of endianness.
A similar fix was proposed in 2022 but kept the u32 typing, so sparse
couldn't validate the added ntohl() calls and it stalled in review.
Retyping first avoids that problem. `make C=2` on netdevsim reports
the same zero warnings as before this change.
Selftest update follows in the next patch.
Cc: stable+noautosel@kernel.org # never worked
Reported-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Link: https://lore.kernel.org/netdev/20220308135106.890270-1-kleber.souza@canonical.com/
Signed-off-by: Andrei Gherzan <andrei.gherzan@canonical.com>
Link: https://patch.msgid.link/20260908140325.13367-2-andrei.gherzan@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
napi_id.py intermittently fails to start its helper on Intel and Google
HW runners:
CMD: /srv/netdev/drivers/net/napi_id_helper 3001::1 37569
EXIT: 1
STDERR: bind failed: Cannot assign requested address
Either keep_addr_on_down is not set or more likely the address is
configured without nodad. Having to make sure that all tests
always wait for DAD after impacting the link would be a whack-a-mole
so we expect the env to have nodad and keep_addr_on_down set.
Warn about both while validating the environment, and document this.
We could fail completely but most tests don't impact the link so for
quick local testing it'd be annoying to have to apply the settings.
I hope the warninging stikes the right balance.
Link: https://patch.msgid.link/20260908181956.1357684-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add source address and port verification in recv_verify_packet_* and
recv_udp: non-matching packets are skipped.
The receiver reads from PF_PACKET and UDP sockets to verify incoming
packets to test hardware checksum offload. It did not validate the
packet source address or source port.
During tests expecting an invalid checksum (-E) or zero checksum (-Z),
background packets can fail the test.
For -Z, build_packet_udp chooses a specific source port that causes
the checksum to sum to zero. When running in receive-only mode (-R),
call build_packet in do_rx to compute the expected source port so
that source port filtering can be applied to -Z as well.
Also
- add an inter-packet delay to avoid drops from bursts.
- remove a comment that is no longer correct.
Fixes: 91a7de8560 ("selftests/net: add csum offload test")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260908155537.813889-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ABI file documents .../endpoint_id/monitor_rx, but
drivers/net/ipa/ipa_sysfs.c has only ever created modem_rx and modem_tx
in the endpoint_id group. No monitor endpoint attribute exists.
Drop the entry.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260905092719.41497-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
smc9.rst was removed with the separate smc91c92 driver. Stop
pointing SMC91X users to the nonexistent file.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260905051944.11604-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When I tried to install and run bonding selftests via:
make INSTALL_PATH=/tmp/kself TARGETS=drivers/net/bonding \
-C tools/testing/selftests install
Some tests fail because net/lib/sh/defer.sh is missing:
/tmp/kself/net/forwarding/../lib.sh: line 5: /tmp/kself/net/lib/sh/defer.sh: No such file or directory
One option is to add defer.sh directly to TEST_INCLUDES. Alternatively,
follow the approach from commit f72aa1b276 ("selftests: net: include
lib/sh/*.sh with lib.sh"), which pulls in all .sh files to accommodate
future changes to the library directory.
This patch adds a wildcard to include all shell files for drivers/net
tests that consume net lib.sh. TEST_INCLUDES is also sorted to avoid
ordering‑related problems for future modifications. The team driver is
not affected by this bug, but we use the wildcard for it as well, rather
than listing only defer.sh.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260907-selftest_lib_defer-v1-1-8af94645aaa3@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
To test for the presence of zerocopy support in the available liburing,
a small check program is compiled.
The CC value used for the io_uring library check defaults to the host
compiler, which will incorrectly validate liburing based on the host's
sysroot and not the target's.
Normally the CC for cross-compile is set in lib.mk, but this also
requires the test list to be set when we include it, and this check
needs to run first.
Note that this doesn't cover the LLVM cross-compiling case though, as
with LLVM we may still detect based on the host liburing.
Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Matthieu Baerts (Netdev Foundation) <matttbe@kernel.org>
Signed-off-by: Maxime Chevallier (Netdev Foundation) <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260907161438.755125-3-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ynl tool and libraries may be built standalone or through the
drivers/net/hw selftest machinery. This may target a different arch, so
we need to take the CROSS_COMPILE variable into account for LLVM and
gcc.
Let's include the tools/scripts/Makefile.include that deals with the
CC/AR resolution.
Fixup the ynltool CFLAGS handling to use +=, so that we don't override
the ones set in Makefile.include.
Makefile.include also sets the Q variable for verbose mode, so we can
drop it from the ynltool Makefile. This will allow properly selection
the verbosity of ynltool builds with the V=1 make flag.
Reviewed-by: Matthieu Baerts (Netdev Foundation) <matttbe@kernel.org>
Signed-off-by: Maxime Chevallier (Netdev Foundation) <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260907161438.755125-2-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Maxime Chevallier says:
====================
net: phy: motorcomm: Enable analog frontend DAC on yt8531S
It enables the analog frontend DAC at config_init() similar to what the
most recent vendor driver does.
Sashiko thought this would break after suspend/resume, this has been
tested and it's actually fine. This V2 just rewords a bit patch 3's
commit log, no other changes.
====================
Link: https://patch.msgid.link/20260905072830.28986-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The YT6801 PCIe NIC includes the dwmac-motorcomm IP for the MAC part, as
well as a YT8531S PHY, configured in GMII mode.
It seems this PHY requires the Analog Front-end (AFE) DAC clock to be
enabled for link to reliably establish, otherwise the link just doesn't
come up.
Let's enable it at config_init() whenever the PHY is in GMII mode.
This logic has been extracted from the vendor driver provided by
Motorcomm.
It's really unclear if this is specific to the integrated version of
that PHY, and how this potentially interacts with the fiber mode this
PHY supports, so this configuration is only enabled when the interface
is GMII, i.e. the PHY is integrated.
With this, the PHY reliably establishes link and the YT6801 PCIe card
becomes fully functional. Supend/Resume was also tested, the link
stays operational after resume.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260905072830.28986-4-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The YT8531S PHY configuration logic is similar to the YT8521, but with
some extra steps for the RGMII configuration. In preparation for
improvements in the YT8531S configuration for the version found
integrated with the YT6801 PCIe NIC, let's split the logic out by
extending the YT8521 configuration sequence.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260905072830.28986-3-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In preparation for separate .config_init() implementations for YT8521
and YT8531S, let's split the yt8521_config_init() into a high-level
helper that deals with page handling, and another one that implements
the logic. This will ease splitting the YT8531S-specific logic out.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260905072830.28986-2-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When of_get_mac_address() fails, return the actual error code (rc)
instead of the hardcoded -ENODEV. This preserves the original error
information, which may be more specific (e.g., -EINVAL, -EPROBE_DEFER)
and helps callers handle the failure appropriately.
Use dev_err_probe() to avoid printing an extra error message in case of
-EPROBE_DEFER.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260903213241.1040204-1-rosenp@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ruizhe Zhou says:
====================
net: Remove obsolete 32-bit DMA mask fallbacks
A lot of Ethernet drivers set a >32 bit DMA mask and retry with a
32-bit mask if the first call fails. This treats the return value of
dma_set_mask_and_coherent() as an indication that the platform requires
a narrower DMA width.
That is not a correct interpretation of dma_set_mask_and_coherent().
The mask describes the DMA addresses the device can accept and constrains
subsequent mappings to that range. A wider mask includes every address
permitted by a 32-bit mask, including addresses from a platform that only
produces 32-bit DMA addresses. Retrying with 32 bits therefore adds a stricter
constraint and cannot correct a failure to establish the wider mask.
The DMA API HOWTO explicitly calls this fallback pattern incorrect [1].
See [2] and [3] for details.
A net subsystem tree-wide audit found 28 Ethernet drivers with this pattern.
This series contains 14 straightforward cases where the fallback can be
removed without changing the mask selected for the device. The return-value
check is retained. DMA setup errors are still reported and still abort device
initialization. The other 14 cases are less straightforward. So I will submit
those as a separate follow-up after review of this series concludes and any
issues are resolved.
Testing was compile-only. No hardware testing was performed.
[1] DMA API HOWTO, "DMA addressing capabilities"
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
[2] DMA direct addressability change, commit 91ef26f914https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=91ef26f914171cf753330f13724fd9142b5b1640
[3] DMA HOWTO correction, commit f7ae20f2fchttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7ae20f2fc4e
====================
Link: https://patch.msgid.link/20260903084339.870562-1-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a wider request as
incorrect:
https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities
Remove the obsolete fallback while retaining the error check so that a
genuine DMA setup failure is still reported and aborts initialization.
A successful setup now necessarily uses the 44-bit mask, so advertise
NETIF_F_HIGHDMA directly after checking the result.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-15-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
