In generic_ocp_{read,write}(), the *while* loops look very strange:
the last iteration is implemented differently to the previous ones
(doing some useless assignments before *break*) for no good reason.
Merge the different iterations into one, using the local variables
in the loop bodies...
Found by a static analysis tool.
Suggested-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev>
Link: https://patch.msgid.link/863dac62-89ef-42d7-9108-d4a0600913a4@auroraos.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Compal EXC-T1 is a Qualcomm MDM9207-based LTE modem which reports
"EXC-x1" as its USB product string. It exposes its QMI function on
interface 5.
Add a fixed-interface match for the QMI function.
Tested on a Compal EXC-T1 modem using an Ubuntu kernel build. Interface
5 bound to qmi_wwan and exposed cdc-wdm2 and wwan1.
Signed-off-by: Ian Lin <ian.lin@jetone.com.tw>
Link: https://patch.msgid.link/20260904075741.55778-1-ian.lin@jetone.com.tw
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 0a36a75c68 ("selftests: icmp_redirect: support expected failures")
added xfail support to icmp_redirect.sh because the test "IPv6: mtu
exception plus redirect" was failing at the time due to a perceived
kernel bug described in commit 99513cfa16 ("selftest: Fixes for
icmp_redirect test").
However, commit 0e02bf5de4 ("selftests: icmp_redirect: IPv6 PMTU info
should be cleared after redirect") subsequently fixed the test logic:
after redirecting to a new path, the old PMTU information should indeed
be cleared, so the test was adjusted to verify the redirect without the
old PMTU.
Since that fix, the test has been passing and is no longer expected to
fail.
Leaving xfail=1 in log_test() for all IPv6 tests was not only obsolete,
but had the undesirable side effect of masking any future IPv6 failure
as XFAIL instead of FAIL. Furthermore, commit 3748939bce ("selftests:
icmp_redirect: pass xfail=0 to log_test()") had to work around a bash
syntax error caused by the empty xfail argument on IPv4 tests.
Remove the obsolete xfail support from log_test() and restore standard
pass/fail reporting across all tests.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260908091327.349091-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ9897 has an SGMII/1000BASE-X capable port 7, but its chip_info
entry never set .sgmii_port. ksz_has_sgmii_port() is therefore false,
ksz9477_pcs_create() is never called and ksz9477_phylink_mac_select_pcs()
returns NULL for port 7, so a phy-mode = "sgmii" or "1000base-x" link on
that port cannot come up.
Only the KSZ9897S has that port; the KSZ9897R has a second RGMII port
instead. Both report chip ID 0x00989700, so the port cannot be enabled
from the chip ID alone, and enabling it unconditionally breaks the
KSZ9897R badly: ksz9477_setup() propagates the failure of
xpcs_create_pcs_mdiodev() on a part without an XPCS, so the switch as a
whole stops probing.
The variants do differ in the read-only bit 7 of the port 7 XMII control
0 register, which reads one on the KSZ9897S and zero on the KSZ9897R.
Compare the KSZ9897S data sheet DS00002394C section 5.2.4.1 with the
KSZ9897R data sheet DS00002330D section 5.2.3.1.
Read that bit in ksz_switch_register() and use it to select a KSZ9897S
chip_data entry, which is the KSZ9897 one plus .sgmii_port = 7, with
port 7 no longer marked as supporting MII, RMII and RGMII. On the
KSZ9897S that port is permanently an SGMII port and only its
differential pairs are brought out, so advertising the xMII modes on it
would let phylink accept a mode the driver never programs:
ksz_phylink_need_config() skips the XMII control registers for the SGMII
port. The KSZ9477, which also has SGMII on port 7, is described the same
way. See DS00002394C section 4.11.
KSZ9897S_CHIP_ID selects that chip_data entry and nothing else.
dev->chip_id keeps the KSZ9897 chip ID that both parts report, so no
other chip ID comparison has to know about the variant,
ksz_check_device_id() is unchanged, and a device tree naming the KSZ9897
keeps matching whichever part is fitted. No binding change is needed and
existing device trees keep working.
Tested on a KSZ9897S with a 1000BASE-LX fibre SFP on port 7: bit 7 of
the port 7 XMII control 0 register reads one, the switch is identified
as a KSZ9897S and the PCS is created. The port advertises
1000baseX/Full, clause 37 in-band autonegotiation completes against the
link partner, and the link comes up at 1Gbps/full duplex and passes
traffic.
Suggested-by: Nicolai Buchwitz <nb@tipi-net.de>
Suggested-by: Jerry Ray <Jerry.Ray@microchip.com>
Suggested-by: Tristram Ha <Tristram.Ha@microchip.com>
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260904-ksz9897-sgmii-port-v5-1-9bd4a0381aa8@vaisala.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
page_pool.rst asks net/core/page_pool.c for page_pool_put_page_bulk().
Commit 024bfd2e9d ("page_pool: make page_pool_put_page_bulk() handle
array of netmems") renamed the function to page_pool_put_netmem_bulk().
Since then the directive finds nothing and the bulk release helper is
missing from the rendered page.
Use the current name.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260905084711.40105-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Gustavo Luiz Duarte says:
====================
netconsole: validate a target's IP address configuration
This series adds two validations to the target configuration when the
user tries to enable it: first whether remote_ip was set, and second
whether local_ip and remote_ip address families match. Refuse to enable
the target if any of those validations fail.
These validations are already done for the target passed on the
command-line, so this aligns dynamic targets with the command-line
behavior.
The first two patches replace the per-target 'ipv6' flag with a
per-address 'family' field, which makes it easier to detect these error
conditions. Patches 3 and 4 implement the actual validations.
Patches 5-7 are follow-ups from previous reviews: move inet_addr from
netpoll.h into netconsole.c, show an unset address as an empty string
rather than "0.0.0.0", document local_ip auto-selection.
====================
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-0-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
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>
