There is not much sense in incrementing multiple conntrack counters for
the same situation. Defining insert_failed as a situation where a valid
packet's conntrack can't be confirmed due to unresolvable clash sets it
apart from 'drop' (ENOMEM situation) and 'chaintoolong'.
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Fix typos 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>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
In nf_osf_ttl(), the break statement after return in NF_OSF_TTL_TRUE
case is unreachable dead‑code. The return statement exits the function
immediately, so break will never execute.
Remove the useless break, no functional change.
Signed-off-by: Linkui Xiao <xiaolinkui@kylinos.cn>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The documentation for nf_conntrack_expect_max incorrectly states that the
default value is nf_conntrack_buckets / 256. However, the code in
nf_conntrack_expect_init() shows:
nf_ct_expect_hsize = nf_conntrack_htable_size / 256;
nf_ct_expect_max = nf_ct_expect_hsize * 4;
This means the default value is actually nf_conntrack_buckets / 64
(i.e. 4 times the hash table size, which defaults to
nf_conntrack_buckets / 256).
Fix the documentation to reflect the correct default value and add
explanation of the calculation.
Signed-off-by: Shaojie Sun <sunshaojie@kylinos.cn>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
SYNPROXY is resetting conntrack seqadj when a closed connection is
re-opened, but it was using nf_ct_seqadj_init() which is a no-op for a
zero offset.
This patch introduces nf_ct_seqadj_reset() which sets the offset values
directly to zero and avoid setting IPS_SEQ_ADJUST_BIT flag, it changes
SYNPROXY code to use it when needed.
Fixes: 48b1de4c11 ("netfilter: add SYNPROXY core/target")
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Remove stale @vport parameter descriptions from
idpf_rx_desc_rel_all() and idpf_vport_queue_grp_rel_all().
Signed-off-by: Ayush Yaduvanshi <ayush37735@gmail.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925000244.72480-1-ayush37735@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Remove stale @count and @cgu parameter descriptions from
ice_dpll_init_fwnode_pins() and ice_dpll_init_pins_e825().
Signed-off-by: Ayush Yaduvanshi <ayush37735@gmail.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260924232138.69492-1-ayush37735@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski says:
====================
dpll: fix LLM nit picks from the spec scan
Fix issues found by an LLM scan of the Netlink spec for DPLL.
====================
Link: https://patch.msgid.link/20260924231211.568213-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The lock-status doc tells userspace that DPLL_LOCK_STATUS_UNLOCKED
can be forced by setting DPLL_A_MODE to DPLL_MODE_DETACHED.
But no such value has been defined so far. enum dpll_mode has only
MANUAL and AUTOMATIC. Let's make sure the doc reflects current
reality.
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20260924231211.568213-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pads need to be propagated to subsets if they are used.
Otherwise Python YNL can fail with:
YnlException: Space 'frequency-range' has no attribute with value '4'
This affects only platforms which care about alignment
so not much real impact.
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20260924231211.568213-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
DPLL_A_PIN_FREQUENCY is a u64 on the wire and dpll_pin_freq_set() keeps it
as one, but dpll_pin_is_freq_supported() takes a u32 while the ranges it
compares against are u64. The supported-frequency check therefore only
looks at the low 32 bits, and the full value is what reaches the driver.
Nothing is hitting this today. Reaching it at all needs a pin-set above
U32_MAX, which no sane caller sends, and the outcome is mild: a pin
advertising 10 kHz accepts 0x1_0000_2710, ice narrows it straight back to
10 kHz in ice_dpll_pin_freq_set(), so the hardware still ends up on an
advertised frequency and only the "frequency is not supported by the
device" rejection goes missing. The other direction - a legitimate request
above U32_MAX wrapping out of the pin's range - needs a driver advertising
such a range, and none does; zl3073x_pin_check_freq() refuses one outright.
So this is types rather than a live bug. Widen the check to match the
attribute, the ranges and the driver callback instead of adding a U32_MAX
rejection, so that the second case stays right if such a driver appears.
dpll_pin_esync_set() already keeps u64 throughout its equivalent loop.
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20260924231211.568213-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MXL86211C also supports 2.5G via 2500BASEX, switch the config init
to indicate support for that mode. Datasheet checks indicate that the
2.5G speed indication is the same between GPY211 & MXL86211C.
The same should be true for MXL86252 & MXL86282, those are not modified
for a lack of testing hardware.
With this change 2.5G negotiates correctly with a Mikrotik
CRS310-8G+2S+IN.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
Link: https://patch.msgid.link/20260924-mainline-rouven-mxl2g5-v2-1-fc8367a4c3ad@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert the deprecated send and receive completion tasklets in
net/rds/ib to BH work items queued on system_bh_wq.
In rds_ib_conn_path_shutdown(), replace tasklet_kill() with
disable_work_sync(), and call enable_work() after destroying the CQs so
the work items can be used again when the connection reconnects.
Signed-off-by: Sunny Tiwari <sunnytiwari@google.com>
Reviewed-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20cbfc32678019daadd3c67fd75262b8264aa180.1790178801.git.sunnytiwari@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kim Wooseok via says:
====================
net: macb: Rework hardware timestamp configuration
This started with two problems I found while using PTP hardware
timestamping on a Raspberry Pi 5. A rejected RX filter could still
change the TX one-step setting, and the PTPv1 Sync and Delay_Req filters
returned success without enabling RX timestamps.
This series reworks gem_set_hwtst() to validate the whole request before
programming the hardware. It calculates the settings locally, then
updates the registers and saved configuration under bp->lock. With the
register writes now in the setter, the two helpers are no longer needed.
The remaining patches use the existing ALL fallback for the specific
PTPv1 filters and clear SRTSM when switching away from a PTPv2 filter.
Each change is kept in its own patch.
For v1, I compared the old and new behavior on the Pi 5. When I
requested a TX mode change together with an invalid RX filter, the
patched driver rejected the request without changing the saved settings
or NCR. I also checked transitions between PTPv2 RX and the other
receive filters. SRTSM followed the selected RX filter without changing
unrelated NCR bits.
For the PTPv1 filters, I checked the effect by sending Sync and Delay_Req
packets over Ethernet. Before the change, the packets arrived without
hardware timestamps. With the patches, the driver returned ALL and I
could read the hardware timestamps from the received packets. PTPv2
multicast reception continued to provide hardware timestamps, and
selecting NONE disabled timestamping. I ran these tests with the changes
backported to the Pi's existing Linux 6.18.46 RT kernel.
====================
Link: https://patch.msgid.link/20260923-macb-hwtstamp-rework-v2-0-75c909b2676d@khu.ac.kr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A PTPv2 receive filter sets NCR.SRTSM, but switching to NONE, ALL or a
PTPv1 filter leaves it set. As a result, selecting the same filter can
produce a different register setting depending on whether PTPv2 was
used before.
Update SRTSM whenever the RX filter changes, setting it only for PTPv2.
Switching away from PTPv2 then clears the old setting, so the bit follows
the currently selected filter.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
Tested-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Kim Wooseok <5mghybrid@khu.ac.kr>
Link: https://patch.msgid.link/20260923-macb-hwtstamp-rework-v2-3-75c909b2676d@khu.ac.kr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Selecting a PTPv1 Sync or Delay_Req filter in gem_set_hwtst() returns
success, but leaves rx_bd_control at its initial value of
TSTAMP_DISABLED. The requested filter therefore appears to have been
applied, even though received packets have no hardware timestamps.
The PTPv1 event case already enables timestamping for all frames, so
use that path for Sync and Delay_Req as well. This enables timestamping
for both requests and returns HWTSTAMP_FILTER_ALL to tell the caller
which filter was actually applied.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
Tested-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Kim Wooseok <5mghybrid@khu.ac.kr>
Link: https://patch.msgid.link/20260923-macb-hwtstamp-rework-v2-2-75c909b2676d@khu.ac.kr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gem_set_hwtst() can reject a request after changing the TX one-step
setting, because it programs the TX mode before checking the RX
filter. The call returns -ERANGE, but the hardware may no longer match
the cached configuration.
Validate both settings first and keep the adjusted RX filter local
until validation succeeds. Then apply the register settings and update
the configuration. A rejected request now leaves the hardware, the
caller's settings and the cached configuration unchanged.
Protect the NCR read-modify-write with bp->lock, keeping the descriptor
writes and cache update in the same section. With the register writes
now in the setter, remove gem_ptp_set_one_step_sync() and
gem_ptp_set_ts_mode().
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
Tested-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Kim Wooseok <5mghybrid@khu.ac.kr>
Link: https://patch.msgid.link/20260923-macb-hwtstamp-rework-v2-1-75c909b2676d@khu.ac.kr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Sergey Shtylyov says:
====================
ch9200: stop ignoring the register write errors
The successful register writes, done via the USB control requests, seem
vital for the normal functioning of the device, however the driver tends
to completely ignore the register write errors, even though it could well
propagate the errors from its bind() method. Additionally, it masks any
USB errors returned by usb_control_msg(), pretending that the call was
successful. Let's stop doing all that and see how it goes... :-)
====================
Link: https://patch.msgid.link/20260923201440.36966-1-s.shtylyov@auroraos.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Compared with control_read(), control_write() looks really strange:
it ignores any errors returned by usb_control_msg(), always returning
0 instead, despite overriding a positive result of usb_control_msg()
(indicating short transfer) to -EINVAL before doing that. Drop that
dubious *return* and propagate USB errors to the callers...
Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev>
Link: https://patch.msgid.link/20260923201440.36966-3-s.shtylyov@auroraos.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The successful register writes, done via the USB control requests in
control_write(), seem vital for the normal functioning of the device,
however the driver's bind() method ignores error codes returned from
control_write(). Do bail out of ch9200_bind() on failed writes...
Signed-off-by: Sergey Shtylyov <s.shtylyov@auroraos.dev>
Link: https://patch.msgid.link/20260923201440.36966-2-s.shtylyov@auroraos.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The Lynx PCS setup for 10g-qxgmii and usxgmii programs the
USXGMII replicator advertisement, but does not explicitly enable and
restart in-band autonegotiation or program the replicator link timers.
This leaves the PCS dependent on firmware or bootloader state. Systems
which do not get the USXGMII replicator preconfigured before Linux may
therefore fail to negotiate the link correctly.
After programming the USXGMII device ability, configure the replicator
BMCR with reset, autonegotiation enable and autonegotiation restart. Also
program the replicator link timer registers using the value returned by
phylink_get_link_timer_ns().
Co-developed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Patryk Biel <pbiel7@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20260923-b4-fix-pcs-lynx-an-v4-1-3f7927606d12@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Similar to commit 87d1268521 ("net: sfp: improve Huawei MA5671a
fixup"), in order to be able to communicate with the module for
configuration even if the fiber is not connected, apply also the
sfp_fixup_ignore_los() fixup to the following SFP modules:
Hisense-Leox LXT-010S-H
Hisense ZNID-GPON-2311NA
HSGQ HSGQ-XPON-Stick
Note: tested only on the Hisense-Leox LXT-010S-H module, but applying to
all three modules, since they were all added in the same
commit 95aca8602e ("net: sfp: add quirks for Hisense and HSGQ GPON
ONT SFP modules"), which says they are all based on the same chipset
Realtek RTL960x.
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260924115055.196631-1-kabel@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 2922078094 ("net: sched: fix erspan_opt settings in cls_flower")
removed the unconditional memset of the erspan_metadata mask in
fl_set_erspan_opt(). On the mask-parse pass, when userspace supplies the
encap option key but no mask (TCA_FLOWER_KEY_ENC_OPTS without
TCA_FLOWER_KEY_ENC_OPTS_MASK), the !depth early return leaves the mask
zeroed -- a wildcard. A filter keyed on an ERSPAN index (v1), or dir/hwid
(v2), then matches every ERSPAN packet's values instead of exact-matching.
Default the match fields on the no-mask path the same way the with-mask
branches default them: v1 index to 0xff, v2 dir and hwid to their
exact-match masks. The union cannot just be memset to 0xff -- that would
re-mask the overlapping timestamp/sgt bytes of the v2 header that the
commit deliberately left to 0.
A mask and a key that declare different ERSPAN versions describe different
union layouts, so the mask would silently wildcard the key's matched
fields. Reject that combination. Have fl_set_erspan_opt() report the
parsed key's version back through a u8 pointer so the mask pass uses it
without re-reading the union.
This is a follow-up to commit fee1065570 ("net/sched: cls_flower:
validate mask pointer after nla_next()").
Conditions to recreate the bug: add an ERSPAN encap-opts flower filter
with a key but no mask (raw netlink, TCA_FLOWER_KEY_ENC_OPTS present,
TCA_FLOWER_KEY_ENC_OPTS_MASK absent); dump the filter and observe the
match mask is zero (wildcard) instead of exact for the supplied fields.
For the mismatch case, pair a v1 key with a v2 mask (or vice versa) and
observe the request is accepted with a mask of the other version.
Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826025123.62758-1-ljp1205831794@gmail.com
Link: https://lore.kernel.org/netdev/20260826025123.62758-1-ljp1205831794@gmail.com/
Reported-by: Sashiko (nipa) <sashiko-bot@kernel.org>
Link: https://lore.kernel.org/netdev/179003833955.2160803.1077681716391858800@kernel.org/
Suggested-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/QDISC-4CSL.v2.20260924114800@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
David Yang says:
====================
net: dsa: motorcomm: Add SerDes PCS
Rework chip_info to tell SERDES ports from xMII ones, identify the port type
at runtime from the pad configuration, and add a phylink PCS driver for the
internal SerDes, so that the link of SERDES ports can be established through
in-band negotiation instead of a fixed configuration.
====================
Link: https://patch.msgid.link/20260923021945.2203368-1-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
yt921x_poll_mib() open-codes the same container_of_const() expression
that leds.c defines as to_yt921x_priv(). Move the macro to chip.h as
yt921x_port_to_priv() so both files use one definition.
Signed-off-by: David Yang <mmyangfl@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260923021945.2203368-7-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
FIELD_PREP values cannot be used as case labels. Introduce enum for
future use.
Signed-off-by: David Yang <mmyangfl@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260923021945.2203368-6-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Review and fix the incorrectness in the bit field names. No functional
change.
Signed-off-by: David Yang <mmyangfl@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260923021945.2203368-5-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The yt921x_port_is_internal/external() macros hardcoded the port layout:
they treat ports 8 and 9 as external on every chip and count the dummy
ports as internal.
Identify the actual port capabilities using chip info and track
configuration of external ports (although only SerDes is supported now).
This is a hardening and cleanup step ahead of the SerDes PCS support, no
behavior changes intended.
Signed-off-by: David Yang <mmyangfl@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260923021945.2203368-4-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace external_mask with xmii_mask and serdes_mask, and advertise the
interface modes it actually supports.
Also move struct yt921x_info into chip.h for future use.
Signed-off-by: David Yang <mmyangfl@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260923021945.2203368-3-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Remove YT921X_PORT_MASK_* macros since they are only thin wrappers
around BIT() and GENMASK() and are not used in other places (plain BIT()
and GENMASK() are used there). No functional change.
Signed-off-by: David Yang <mmyangfl@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260923021945.2203368-2-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Nathan Whitehorn says:
====================
net: macb: 1000BASE-X on internal PCS
This series adds support for 1000BASE-X autonegotiation to the Cadence macb
driver when using the MAC-internal PCS. The existing driver code is oriented
toward the PCS being used with an on-board SGMII PHY, so uses Cisco
SGMII-style autonegotiation exclusively and does not anticipate e.g. link
state changes arising from fiber attach/detach events since the SGMII endpoint
is permanently attached in such cases. The first patch changes the driver
to monitor the PCS's link by polling, following the approach used currently
by this driver for fixed links when the PCS is enabled since the driver
does not currently monitor PCS link state otherwise and this had not come up
with permanently-attached SGMII PHYs that report link state out of band.
The second extends the existing SGMII autonegotiation code to also support
1000BASE-X autonegotiation.
Tested on Microchip PolarFire SoC with a variety of SFPs (copper, fiber, GPON)
attached to the I/O Bank-5 PCS lines.
Thanks to Charles Perry, Andrew Lunn, Paolo Abeni, Théo Lebrun, and
Jakub Kicinski for helpful suggestions and discussion on this patch series.
As a brief summary of that discussion, there are a few areas near this patch
that are existing non-idealities in the macb driver, in particular that it uses
polling to monitor link-state with the internal PCS and the driver does not
currently have support for using the link-state change interrupt. The
intention is to address this in a later patch that would remove polling from
both this case and the fixed-link one. Other discussion in earlier rounds
of the patches was related to handling some ZynqMP-specific code that is
related to specific SGMII-only hardware that is not relevant in the 1000BASE-X
case.
====================
Link: https://patch.msgid.link/20260922151429.23272-1-nwhitehorn@pa.msu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The current PCS code unconditionally uses SGMII autonegotiation, though
the hardware supports both SGMII and 1000BASE-X modes. Decouple the
choice of PCS enablement from use of the SGMII mode when running at
gigabit rates and announce to phylink that 1000BASE-X is a supported
operating mode. This enables direct attachment of the PCS to e.g. an
SFP.
The 1000BASE-X code in phylink also sometimes calls the autonegotiation
restart method, so add an implementation of autonegotiation restart and
make sure that pcs_config() signals to phylink when the AN advertisement
has changed.
Signed-off-by: Nathan Whitehorn <nwhitehorn@pa.msu.edu>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260922151429.23272-3-nwhitehorn@pa.msu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When used with an offboard transceiver (e.g. an SFP), link state needs
to be measured at the PCS rather than an onboard PHY. Poll the link
state when the PCS is active to allow the kernel to detect link state
changes in this case.
Signed-off-by: Nathan Whitehorn <nwhitehorn@pa.msu.edu>
Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20260922151429.23272-2-nwhitehorn@pa.msu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
idt82p33_ptp_clock_unregister_all() cancels each channel's adjtime work
before unregistering its PTP clock. An adjustment callback already in
progress can schedule that work after cancellation returns. Device
removal then frees the channel while its delayed work remains queued,
causing a use-after-free.
Mark the device as stopping under its lock before draining work. Reject
new adjustment and EXTS requests, clear the EXTS polling mask, and
synchronously drain the EXTS and channel adjustment work before the
device storage is released.
With an i2c-stub device and kprobe-controlled callback timing, three
runs of the unmodified driver reported KASAN use-after-free after
unbind. Three runs with this change completed without a kernel
diagnostic. No physical IDT82P33 device was tested.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path race
Signed-off-by: Yibo Tan <lhfff@tju.edu.cn>
Link: https://patch.msgid.link/20260922113601.855416-1-lhfff@tju.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Niklas Söderlund says:
====================
ravb: Add gPTP support for Gen4
This series is the second part cleaning up how PTP timer support is
implemented on R-Car Gen4. Currently there is partial support for it
in some of the Ethernet devices that can use it, but not all.
On Gen2 and Gen3 each RAVB instance have it's own private PTP clock as
part of the RAVB register space. For this reason the PTP functionally
was implemented directly in the RAVB driver. For Gen4 however there is
a system-wide PTP clock shared by all RAVB instances, and on some Gen4
platforms with other Ethernet devices.
The RAVB Gen4 driver currently advertise PTP support to user-space, but
the support is in fact completely broken. It tries to use RAVB private
PTP clock, which do not exist on Gen4.
Further more the PTP clock behaved slightly different on Gen2 and Gen3.
These differences have been handled by adding platform specific flags
inside the driver.
The usage of these flags have grown organically and been extended all
over the driver as it gained new features. Adding a new third set of
flags for Gen4 would be messy and add to the confusion.
Therefore patches 1/10 thru 8/10 refactors the usage of the PTP flags
into optional callbacks and untangles the usage. This allows adding Gen4
support easy as it can just implement it's own set of Gen4 specific
callbacks without altering the driver logic.
Patch 9/10 is a small DT binding addition adding an optional phandle to
link a RAVB device to the external PTP clock. Ideally this property
should be mandatory, but for backward comp ability is is made optional.
If the phandle is not set, or the PTP clock not enabled, the RAVB driver
will continue to faction as before, but no longer advertise PTP support
to user space.
Finally patch 10/10 adds the Gen4 specific PTP callbacks which allows
the driver to use the external PTP clock.
For part one of this work see [1]. The two series are independent of
each other but both are needed before a third series liking the RAVB to
the PTP clock in the platforms device tree. I will hold posting the
third series until all dependencies are merged. For this reason there
is no user of the new renesas,gptp device tree property added in this
series.
The work is tested on both Gen3 and Gen4 R-Car devices (with [1] and
appropriate DTS). I do however not have access to any Gen2 device where
the RAVB IP is wired to a MAC, so the small rework of the flags for Gen2
to callbacks have only been compiled tested. If anybody have a RZ device
where RAVB is wired and uses the Gen2 method of starting/stopping the
PTP timer together with the DMAC please test this.
[1] https://lore.kernel.org/20260803095232.3527111-1-niklas.soderlund+renesas@ragnatech.se/
====================
Link: https://patch.msgid.link/20260921175037.4084310-1-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
While driver advertises gPTP support on Gen4 platforms it is in fact
completely broken. On R-Car Gen4 devices the RAVB module have no
internal gPTP clock as generations before it. Instead it utilizes a
system-wide gPTP clock.
This change utilizes the refactoring of the RAVB gPTP code to add
support for a system-wide clock and stops the Gen4 devices trying to use
the non-existing internal gPTP clock.
To remain backward compatible the ptp-timer property is optional.If not
present, or not enabled, the RAVB driver will no longer advertise gPTP
support to user-space.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Sergey Shtylyov <sergei.shtylyov@gmail.com>
Link: https://patch.msgid.link/20260921175037.4084310-11-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The RAVB module on Gen4 have no gPTP clock as part of the RAVB module
itself, instead it relies on an external system wide gPTP clock. The
gPTP clock is shared with RTSN on V4H and RSWITCH on S4.
Add an optional phandle so that the RAVB driver can find and use the
gPTP clock. Ideally this should have been a mandatory property but for
backward compatible it is optional. The RAVB module is capable of
functioning without it, but can in such cases not provided PTP
functionality.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Sergey Shtylyov <sergei.shtylyov@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260921175037.4084310-10-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Prepare for adding Gen4 support which have an optional external gPTP
clock. Add a callback to get the clock index and use it to determine if
the device shall report gPTP support.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Sergey Shtylyov <sergei.shtylyov@gmail.com>
Link: https://patch.msgid.link/20260921175037.4084310-9-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Different generations of the RAVB IP have different needs when it probes
the gPTP timer clock. Add a callback in the PTP information to allow
each generation to probe its own way.
With this the last gPTP specific flag (gptp_ref_clk) can be removed.
However the primary motivation for the change is to prepare for Gen4
support, which compared to other generations with gPTP support does not
have the clock as part of the IP itself.
Gen4 will not need to compute GTI value as it have nowhere to write it,
as the gPTP clock is external. For this reason move the computation of
it into the newly gPTP probe specific callbacks for the RAVB IP's that
support it.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Sergey Shtylyov <sergei.shtylyov@gmail.com>
Link: https://patch.msgid.link/20260921175037.4084310-8-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Prepare for adding Gen4 support which will add a third and new way to
interact with the gPTP clock by replacing the flags for Gen2 behavior
(info->gptp) and Gen3 behavior (info->ccc_gac) with callbacks.
This will make adding Gen4 support cleaner as the code will not have "if
else if else" sprinkled all over to handle each generations special
cases.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Sergey Shtylyov <sergei.shtylyov@gmail.com>
Link: https://patch.msgid.link/20260921175037.4084310-7-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
There is no need to explicitly pass the struct platform_device pointer
to ravb_ptp_init(), it can retrieve it directly from the private data
structure.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Sergey Shtylyov <sergei.shtylyov@gmail.com>
Link: https://patch.msgid.link/20260921175037.4084310-5-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For devices that do not support the gPTP clock in config mode the
somewhat oddly named flag gptp is set, compared to devices that do
support the gPTP clock in config and operation mode where the flag
ccc_gac is set instead. The two flags are mutually exclusive.
For the gptp-flag devices (Gen2) the clock is tied to the AVB-DMAC, when
it is stopped so is the gPTP clock. For ccc_gac-flag devices (Gen3) the
gPTP clock is available whenever the ndev is open.
Prepare to add Gen4 support which will add a third way by cleaning the
Gen2 and Gen3 cases up a bit.
Fold the gptp-flag start and stop calls into ravb_dmac_init() and
ravb_stop_dma(), which start and stop the AVB-DMAC. There are no
functional change as all call sites to the construct:
if (info->gptp)
ravb_ptp_init(ndev, priv->pdev);
are always just after a call to into ravb_dmac_init() and all call sites
to the construct:
if (info->gptp)
ravb_ptp_stop(ndev);
are always directly followed by a call to ravb_stop_dma().
There are two special cases where the calling construct covers both the
gptp-flag and info->ccc_gac devices, one for start and one for stop. The
condition that it is preceded by a call to ravb_dmac_init(), or followed
by a call to ravb_stop_dma() are however true for them too. Reworked the
two special cases to drop the check of info->gptp.
The end result is that the gPTP clock will be started or stopped for the
gptp-flag devices in tandem with the AVB-DMAC, while the info->ccc_gac
devices will be controlled, as before, when the ndev is opened or
closed.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Sergey Shtylyov <sergei.shtylyov@gmail.com>
Link: https://patch.msgid.link/20260921175037.4084310-4-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit f384ab481c ("net: ravb: Split GTI computation and set
operations") broke apart the operations of computing the timer interval
and programming of it. However it kept the programming of the interval
in the RAVB main logic.
Having split the two apart this can be improved further by moving the
programming to the gPTP initialization function, as the first action of
the gPTP init function is to wait for the timer interval programming to
be acknowledge by the hardware.
As an added bonus the interaction with the gPTP registers for the
programming can then also be done while holding the gPTP registers lock.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Sergey Shtylyov <sergei.shtylyov@gmail.com>
Link: https://patch.msgid.link/20260921175037.4084310-3-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since commit a6a85ba36f ("net: ravb: Move PTP initialization in the
driver's ndo_open API for ccc_gac platorms") the gPTP clock (if
supported) is stopped and started by opening and closing the ndev.
This makes the special case to stop and start it when resuming from WoL
redundant. As the ndev will always be closed and re-opened when
resuming the system.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Sergey Shtylyov <sergei.shtylyov@gmail.com>
Link: https://patch.msgid.link/20260921175037.4084310-2-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet says:
====================
net: ethtool: make netdev_rss_key_fill() spread flows over all queues
netdev_rss_key_fill() hands drivers a uniformly random key. Because the
Toeplitz hash is linear over GF(2), a random key is singular for a given
header field and queue count with probability 1/2: flows differing only
in the low order bits of that field (such as a burst of consecutive
ephemeral ports) then cannot reach all RX queues. On one affected 16-queue
host, only 4 queues received traffic until the key was replaced.
Patch 1 synchronizes proc_do_rss_key() with netdev_rss_key_fill() using an
smp_wmb()/smp_rmb() pair and a boolean flag so readers of
/proc/sys/net/core/netdev_rss_key print zero bytes until the key is fully
populated.
Patch 2 keeps the key random but constrains 1008 of its 2048 bits so that,
at every 16-bit aligned position and for every power-of-two queue count up
to 256, consecutive values of a field ending there visit every queue once.
Applying the fixup on the 16-bit grid covers standard 2-tuple/4-tuple
hashes as well as encapsulated or bitmap-selected layouts (such as PSP
inner TCP ports at byte 78) without enumerating them in the core. The
fixup is a bijection onto the set of valid keys, and redraws in the ~1 in
5 case where two 32-bit windows a multiple of 8 bits apart alias.
Patch 3 adds RSS key, indirection table, and flow-hash reporting to
netdevsim so the selftest can exercise both the host key and ethtool
netlink RSS reporting in a virtual machine without hardware.
Patch 4 adds a selftest under tools/testing/selftests/drivers/net/rss_key.py
checking /proc/sys/net/core/netdev_rss_key and the live RSS key,
indirection table, and flow-hash layouts reported by a device via ethtool
netlink.
====================
Link: https://patch.msgid.link/20260922163458.3900996-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a selftest under tools/testing/selftests/drivers/net/rss_key.py
checking both the host RSS key (/proc/sys/net/core/netdev_rss_key) and
the RSS key, indirection table, and flow-hash layouts reported by a
device over ethtool netlink.
When invoked without NETIF, NetDrvEnv creates a 4-queue netdevsim device,
which calls netdev_rss_key_fill() and allows exercising both the host key
and the netlink RSS reporting path in a virtual machine without special
hardware. When invoked with NETIF, it checks the key and indirection
table of that interface.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260922163458.3900996-5-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
