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>
The DMA API guarantees support for masks of 32 bits or wider and
explicitly identifies retrying a 32-bit mask after a 64-bit 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.
Update the error message to identify the combined streaming and coherent
DMA mask operation.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/20260903084339.870562-11-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 47-bit mask, so remove the
redundant using_dac flag and advertise NETIF_F_HIGHDMA directly.
Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com>
Link: https://patch.msgid.link/20260903084339.870562-6-zhouruizhe@resnics.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct sockaddr_spn does not exist; the name is struct sockaddr_pn.
Use struct sockaddr_pn.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260905104123.43511-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Wang Zhan says:
====================
net: sysfs: use ops lock for speed and duplex
Reading speed and duplex from sysfs currently holds RTNL across the
get_link_ksettings callback. This unnecessarily serializes monitoring
reads with unrelated rtnetlink operations.
On CPU-throttled hosts, a periodic reader such as node-exporter can hold
RTNL for hundreds of milliseconds while an mlx5 callback runs, delaying
unrelated rtnetlink operations.
Factor the shared link settings read first, then change only the helper's
locking. Legacy devices and callbacks which request
ETHTOOL_OP_NEEDS_RTNL_LINKSETTINGS retain the existing RTNL path.
v1: https://lore.kernel.org/netdev/20260831080623.1064001-1-wang.zhan@smartx.com/
====================
Link: https://patch.msgid.link/20260903133314.3703381-1-wang.zhan@smartx.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reading /sys/class/net/<dev>/{speed,duplex} takes rtnl_lock() even for
ops-locked devices whose get_link_ksettings callback does not require it.
This unnecessarily serializes monitoring reads with unrelated rtnetlink
operations.
On CPU-throttled hosts, a periodic reader such as node-exporter can hold
RTNL for hundreds of milliseconds while an mlx5 callback runs, delaying
unrelated rtnetlink operations.
Use the netdev instance lock for these devices. Retain sysfs_rtnl_lock()
for legacy devices and callbacks that request
ETHTOOL_OP_NEEDS_RTNL_LINKSETTINGS.
Preserve the existing speed and duplex sysfs ABI, including -EINVAL for
devices that are down or callbacks that fail.
Assisted-by: LLM
Signed-off-by: Wang Zhan <wang.zhan@smartx.com>
Link: https://patch.msgid.link/20260903133314.3703381-3-wang.zhan@smartx.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
speed_show() and duplex_show() duplicate device validation, RTNL
locking and the link settings query. Move this common work to
sysfs_get_link_ksettings() so later locking changes stay in one place.
RTNL is released before calling sysfs_emit(). The lock only protects the
link settings query; formatting uses the local cmd copy, so the sysfs
output and error handling remain unchanged.
No functional changes.
Assisted-by: LLM
Signed-off-by: Wang Zhan <wang.zhan@smartx.com>
Link: https://patch.msgid.link/20260903133314.3703381-2-wang.zhan@smartx.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
irq_of_parse_and_map() returns 0 when parsing or mapping an IRQ fails.
The current condition also checks for negative values, even though
irq_of_parse_and_map() does not return negative error codes.
Check only for a zero return value to match the semantics of
irq_of_parse_and_map().
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260903075753.346647-1-phucduc.bui@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
After commit cd51b74bdd ("ipv6: Fix redirect exception creation for
UDP/RAW sockets") the two redirect calls are now equivalent and there is
no need to specifically call ip6_redirect() for tunnel sockets. Simplify
and call ip6_sk_redirect() for both tunnel sockets and regular sockets.
Note that for ICMPv6 Redirect Message packets the VRF driver does not
reset skb->dev to the VRF device, so skb->dev->ifindex is equivalent to
inet6_iif(skb), even when the packet was received from a VRF port.
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260907101358.596953-1-idosch@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260907064346.3288-1-hemanth.selam@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Count the cases where the driver fails to allocate a buffer or an skb,
such as when try_fill_recv() fails with ENOMEM, and report them via the
rx-alloc-fail qstat.
Plumb alloc-fail into virtnet_get_base_stats() to keep this new stat
reported consistently at both queue and device scope, matching how
packets, bytes, stop and wake are handled.
This counter does not cover every allocation failure in all RX paths.
It is intentionally limited to the common skb and RX buffer allocation
paths to keep its meaning clear.
$ ./tools/net/ynl/ynltool/ynltool qstats show --json scope queue
[{"ifname":"ens3",
"ifindex":2,
"queue-type":"rx",
"queue-id":0,
"rx":{"packets":3722,"bytes":374806,"alloc-fail":0}},
{"ifname":"ens3",
"ifindex":2,
"queue-type":"tx",
"queue-id":0,
"tx":{"packets":622,"bytes":77495,"stop":0,"wake":0}}]
Signed-off-by: Longjun Tang <tanglongjun@kylinos.cn>
Link: https://patch.msgid.link/20260903022848.33595-1-lange_tang@163.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Jakub Kicinski says:
====================
netlink: specs: fou: spec tweaks
FOU was one of the initial families I used to develop YNL against.
It's not using YNL features which were added later, fill in the gaps.
====================
Link: https://patch.msgid.link/20260904191412.3872344-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The spec defines encap-type (unspec / direct / gue), but no attribute
references it, so the definition exists only to emit FOU_ENCAP_* into
the uAPI header - while FOU_ATTR_TYPE is exactly that value space:
fou_create() switches on FOU_ENCAP_DIRECT / FOU_ENCAP_GUE and returns
-EINVAL for anything else. Python YNL could not accept or display the
names and the generated C exposed a raw __u8 setter.
The global policy entry becomes NLA_POLICY_MAX(NLA_U8, 2). For add
that only moves the existing fou_create() rejection earlier; del and
get ignore FOU_ATTR_TYPE altogether, so a bogus type there now fails
validation instead of being dropped on the floor.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Link: https://patch.msgid.link/20260904191412.3872344-4-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
fou_core.c uses nla_get_in_addr() / nla_put_in_addr() on both, i.e.
they are __be32, and port / peer-port in the same spec are already
annotated. Without byte-order YNL swaps them on little endian hosts.
The generated policy goes from NLA_U32 to NLA_BE32, which changes
nothing: lib/nlattr.c gives the two the same length in nla_attr_len[]
and the same range handling, and neither attribute has a range check.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Link: https://patch.msgid.link/20260904191412.3872344-3-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
parse_nl_config() is the only place the address family is chosen: it
defaults cfg->udp_config.family to AF_INET and only switches to
AF_INET6 when FOU_ATTR_AF is present. The &all_attrs anchor - the add
request, and the get do and dump reply - does not list af, so a ynl
generated client has no fou_add_req_set_af() and can never create an
IPv6 FOU port; the local-v6 / peer-v6 attributes it does list are read
by nothing. On the reply side fou_fill_info() puts FOU_ATTR_AF
unconditionally, and struct fou_get_rsp has no member for it.
kernel-policy is global, so fou_nl_ops[] carries no per-op attribute
list and af is already in fou_nl_policy through &select_attrs - only
the user space codegen and the rendered docs change, ynl-regen.sh
produces no diff.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Link: https://patch.msgid.link/20260904191412.3872344-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Geert Uytterhoeven says:
====================
net: Make sure clk_init_data is fully initialized
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Hence this series aims to make sure all members are fully initialized,
to avoid such bugs, and to prevent future breakage when converting
drivers to a different method for specifying the parents.
Part One[1] fixed all cases that I identified to be real bugs, in
response to a crash I saw on BeagleBone Black.
This series is the networking subpart of Part Two, which fixes remaining
cases that are currently harmless. These are still fragile, and may
cause future breakage when converting drivers to a different method for
specifying the parents.
[1] "[PATCH treewide 0/5] clk: Make sure clk_init_data is fully
initialized (part 1)"
https://lore.kernel.org/cover.1787165329.git.geert+renesas@glider.be
[2] "[PATCH net-next 0/3] net: Make sure clk_init_data is fully
initialized"
https://lore.kernel.org/cover.1787240118.git.geert+renesas@glider.be
====================
Link: https://patch.msgid.link/cover.1788425654.git.geert+renesas@glider.be
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://patch.msgid.link/0e869f49c910ce054aa22ae84480aab69420bb92.1788425654.git.geert+renesas@glider.be
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://patch.msgid.link/98e2b71c333fea0ed59bf615c818cb7b56e2f2b5.1788425654.git.geert+renesas@glider.be
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The clk_init_data structure contains several mutually-exclusive members
for different methods to specify the possible parents of a clock,
prompting drivers to initialize only the members they need. However,
not initializing all members may cause subtle issues, which are only
exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is
enabled.
Make sure all members are fully initialized, to avoid such bugs, and to
prevent future breakage when converting drivers to a different method
for specifying the parents.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/62cfa62a8f39e0014d2fe9b30a668df20ace4a0c.1788425654.git.geert+renesas@glider.be
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no optional IRQ is available. Other errors should be propagated so
that the caller can handle them appropriately.
The existing code propagates -EPROBE_DEFER, but ignores other negative
errors. Propagate negative errors other than -ENXIO.
Found by manual code inspection.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260903074638.345952-1-phucduc.bui@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Correct "protcol" to "protocol", reported by 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>
Link: https://patch.msgid.link/20260904123638.39273-1-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix typos in comments, reported by 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>
Link: https://patch.msgid.link/20260904122157.29281-1-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Correct "trigged" to "triggered", reported by 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>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260904115917.13695-1-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Correct "asymetric" to "asymmetric", reported by 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>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260904104107.12832-3-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Correct "framwork" to "framework", reported by 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>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260904104107.12832-2-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Recently, IPV6_ADDRFORM has received many AI-driven bug reports.
Fixing them properly would needlessly churn the fast paths in TCP
and UDP.
IPV6_ADDRFORM was initially introduced in RFC 2133 in 1997,
but only two years later, it was removed from RFC 2553 in 1999.
In 2026, modern applications natively support dual-stack sockets;
notably, systemd's socket activation does not use IPV6_ADDRFORM.
Also, getsockopt(IPV6_ADDRFORM) can be replaced with SO_DOMAIN.
Let's remove IPV6_ADDRFORM.
Later, we can remove sk->sk_prot_creator and revert commit
c26c192c3d ("udp: properly deal with xfrm encap and ADDRFORM").
Reported-by: Daehyeon Ko <4ncienth@gmail.com>
Closes: https://lore.kernel.org/netdev/20260902010408.1057857-1-4ncienth@gmail.com/
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Closes: https://lore.kernel.org/netdev/20260824033331.1084971-1-imv4bel@gmail.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260904033543.2635540-3-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
