On E825, the TX-CLK and TSPLL DPLL devices are registered as
DPLL_TYPE_GENERIC. Their clock_id was derived from the board-level
PCIe DSN, which is identical for all interfaces sharing the same
NAC/quad. As a result, userspace (e.g. 'dpll device show') reports
several DPLL devices with the same clock_id and no board or signal
label, making it impossible to unambiguously map a DPLL device to
the interface it belongs to.
Since these DPLLs are per-interface, use the permanent port MAC as
the clock_id basis for E825 generic DPLLs:
* TX-CLK uses the plain MAC-derived value.
* TSPLL on the source-timer owner PF uses the same MAC-derived
value with a dedicated tag bit, so it stays distinct from
TX-CLK while remaining stable per interface.
Other DPLL objects (EEC/PPS and non-E825 paths) keep the board
DSN-derived clock_id. When the permanent MAC is not yet valid, fall
back to the existing board-level clock_id to preserve init behavior.
Reviewed-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
This extends the E825 advanced sync-timing support introduced by the
tx-clk series, which added the TXC DPLL device for TX reference clock
control. The TSPLL, the source timer PLL, is now also exposed through
the dpll subsystem so that its lock status and clock source selection
are visible and controllable from userspace.
On E825 devices the TSPLL is the source timer PLL, distinct from the
EEC and PPS DPLLs used on E810. Register it as a DPLL_TYPE_GENERIC
device for owner PFs.
Add struct ice_dplls::tspll_in, a fwnode-backed input pin named
"time_ref". The state_on_dpll_get callback queries ICE_CGU_R23 via
ice_tspll_get_clk_src() and returns CONNECTED when TIME_REF is
selected as clock source, DISCONNECTED otherwise. The state_on_dpll_set
callback switches the source between TIME_REF and TCXO via the new
ice_tspll_set_cfg() helper. Registration is deferred via the dpll
notifier path if the pin is not yet visible in the subsystem at probe
time.
Initialize TSPLL DPLL state from direct clock-source/lock reads so the
first published state reflects hardware and prev_dpll_state matches.
During periodic polling, the DPLL worker consumes
READ_ONCE(pf->ptp.tspll_locked), maintained and recovered by the PTP
periodic worker. When the TSPLL clock source is TCXO (TIME_REF pin not
selected), UNLOCKED is reported unconditionally to reflect the
free-running state of the oscillator regardless of the raw lock bit.
To avoid stale lock-status reads after synchronous source changes, the
set callback now refreshes tspll.dpll_state immediately and emits a DPLL
change notification when the cached state changed.
If a TSPLL reconfiguration is applied but the PLL has not yet
re-acquired lock, treat the internal -EAGAIN result as success so the
PTP periodic worker can complete recovery, while real -EBUSY failures
from reset/SBQ paths still propagate to userspace.
The TSPLL userspace reconfiguration path (state_on_dpll_set) and the
PTP periodic worker (ice_ptp_tspll_monitor) both read TSPLL HW state
and write the pf->ptp.tspll_locked cache consumed by the DPLL worker.
Serialize both with pf->dplls.lock across their HW-read -> cache-write
sequence; otherwise a preempted monitor could overwrite an accurate
cache update from the DPLL callback with stale HW state. The mutex
lifetime is lifted to PF-features scope (initialized in
ice_init_features() before ice_ptp_init(), destroyed in
ice_deinit_features() after ice_ptp_release()) so the PTP monitor
can take it unconditionally regardless of DPLL init state.
Extend ice_dpll_deinit_txclk_pins() with a "flush" parameter so the
E825 init error path for the TSPLL fwnode pin can tear down TXCLK
pins without flushing pf->dplls.wq. If the flush ran here, notifier
work items queued during earlier init steps would be blocked on
pf->dplls.dpll_init, which is only completed at the unregister_pins
label reached after this teardown. destroy_workqueue() at that label
drains the queued items safely. Existing full-teardown callers pass
flush=true and keep current behavior.
Reviewed-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
On E825 devices that own the source timer, the TSPLL can lose lock when
the TCXO or TIME_REF signal is disrupted. Recovery requires re-enabling
the TSPLL via CGU register writes; without it, the PHC keeps running on
a degraded reference indefinitely.
The DPLL periodic worker (ice_dpll_periodic_work()) would be a natural
home for this monitoring, but placing it there has two problems:
1. ice_dpll_init_e825() sets ICE_FLAG_DPLL only after all initialization
steps succeed. If any earlier step fails, the driver would run
without any TSPLL recovery mechanism.
2. When CONFIG_DPLL=n, the DPLL worker is compiled out and TSPLL
recovery would be silently absent.
Add the monitor to ice_ptp_periodic_work() instead, which always runs on
E825 owner PFs regardless of DPLL init state or config. Introduce two
small helpers, ice_tspll_lost_lock_e825c() and ice_tspll_restart_e825c(),
which encapsulate the CGU register reads/writes required to observe and
recover the TSPLL.
Cache the observed lock state in pf->ptp.tspll_locked using
WRITE_ONCE()/READ_ONCE() so a follow-up change can consume it from the
DPLL periodic worker (for user-space notification via
dpll_device_change_ntf()) and drop the redundant poll+recovery from
that path. Precise synchronization is not required: both workers converge
on the same value within one poll period.
Reviewed-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
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>
Nikolay Aleksandrov says:
====================
net: bridge: vlan: minor cleanups and annotations
In preparation for a complete vlan fast-path re-work, this set cleans up
a few minor things - removing legacy code barriers that don't help,
annotating lockless accesses and using proper helpers.
No functional changes are intended. Sashiko will find many pre-existing
problems, none of them are related to this set. I will try to fix
everything pre-existing separately in -net, there will probably be a few
critical items. So if there are missed places to annotate, or if there're
actual functional changes, these obviously should be addressed in this set.
====================
Link: https://patch.msgid.link/20260903143138.1574598-1-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The vlan state can change under RTNL or RCU (mst), so use the helper
to get the state properly throughout the bridge driver.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260903143138.1574598-10-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When I annotated data races around tinfo.tunnel_id before, I missed a few
places (e.g. bridge notifications, rhashtable compare), so add them now.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260903143138.1574598-9-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Annotate data races around vlan msti field, it can be read lockless.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260903143138.1574598-8-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Annotate data races around vlan group's num_vlans, it can be read lockless.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260903143138.1574598-7-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Annotate vlan private flags data races, they can be read lockless.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260903143138.1574598-6-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Annotate vlan flags data races, they can be read lockless.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260903143138.1574598-5-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The only place that accessed pvid directly outside of the bridge vlan code
was mst, change it to use the br_get_pvid helper.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260903143138.1574598-4-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Use READ/WRITE_ONCE to annotate lockless pvid use, br_get_pvid() is the
helper that should be used outside of the bridge vlan code. The rest of
the vlan places that access pvid directly all have rtnl.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260903143138.1574598-3-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
These memory barriers are legacy code from the old vlan implementation
that is not needed anymore. They're also affecting the fast-path.
The pvid is changed under lock and is read with rcu only in the fast-path
there is no need for a barrier, nothing to commit prior to changing it nor
invalidate prior to reading.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260903143138.1574598-2-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The issue was discovered via smatch static analyzer:
make CHECK="smatch -p=kernel" C=2 drivers/net/phy/microchip_t1.o
CHECK scripts/mod/empty.c
DESCEND objtool
CHECK drivers/net/phy/microchip_t1.c
drivers/net/phy/microchip_t1.c:1295 lan887x_phy_init() warn: 'priv->clock' can also be NULL
mchp_rds_ptp_probe() returns NULL when CONFIG_MICROCHIP_PHY_RDS_PTP or
CONFIG_PTP_1588_CLOCK is disabled. However, lan887x_phy_init() only checks
for an error pointer before using the returned clock to configure the
periodic output pin, which can result in a NULL pointer dereference.
Handle the NULL return as PTP being unavailable and skip the event pin
configuration in that case. Smatch no longer reports the NULL dereference
warning after the change.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Reviewed-by: Divya Koppera <Divya.Koppera@microchip.com>
Signed-off-by: Henry Hu <huhai@kylinos.cn>
Link: https://patch.msgid.link/20260903113046.163630-1-15815827059@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Reviewed-by: Alexander Sverdlin <alex@sverdlin.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-27-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since sentinel is the last entry and we do not expect further entries
following it, remove the comma.
Acked-by: Vivian Wang <wangruikang@iscas.ac.cn>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20260904043724.2955444-26-s-vadapalli@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
