Switch the function to use the proper sysfs_emit("%pb").
Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Link: https://patch.msgid.link/20260319201713.941956-3-ynorov@nvidia.com
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The driver uses bitmap_print_to_pagebuf() to store human-readable
bitmaps representations in a temporary buffers; and then feed
seq_printf() with it.
Switch to using seq_printf("%*pb") directly and drop intermediate
buffer.
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Link: https://patch.msgid.link/20260319201713.941956-2-ynorov@nvidia.com
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Raju Rangoju says:
====================
amd-xgbe: TX resilience improvements for link-down handling
This series enhances the AMD 10GbE driver's TX queue handling during
link-down events to improve resilience, prevent resource leaks, and
enable fast failover in link aggregation configurations.
The three patches form a complete link-down handling solution:
1. Patch 1: Fast detection (know quickly when link goes down)
2. Patch 2: Quick response (stop TX immediately, skip waits)
3. Patch 3: Clean recovery (reclaim abandoned resources)
====================
Link: https://patch.msgid.link/20260319163251.1808611-1-Raju.Rangoju@amd.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add intelligent TX descriptor cleanup mechanism to reclaim abandoned
descriptors when the physical link goes down.
When the link goes down while TX packets are in-flight, the hardware
stops processing descriptors with the OWN bit still set. The current
driver waits indefinitely for these descriptors to complete, which
never happens. This causes:
- TX ring exhaustion (no descriptors available for new packets)
- Memory leaks (skbs never freed)
- DMA mapping leaks (mappings never unmapped)
- Network stack backpressure buildup
Add force-cleanup mechanism in xgbe_tx_poll() that detects link-down
state and reclaims abandoned descriptors. The helper functions and DMA
optimizations support efficient TX shutdown:
- xgbe_wait_for_dma_tx_complete(): Wait for DMA completion with
link-down optimization
- Restructure xgbe_disable_tx() for proper shutdown sequence
Implementation:
1. Check link state at the start of tx_poll
2. If link is down, set force_cleanup flag
3. For descriptors that hardware hasn't completed (!tx_complete):
- If force_cleanup: treat as completed and reclaim resources
- If link up: break and wait for hardware (normal behavior)
The cleanup process:
- Frees skbs that will never be transmitted
- Unmaps DMA mappings
- Resets descriptors for reuse
- Does NOT count as successful transmission (correct statistics)
Benefits:
- Prevents TX ring starvation
- Eliminates memory and DMA mapping leaks
- Enables fast link recovery when link comes back up
- Critical for link aggregation failover scenarios
Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
Link: https://patch.msgid.link/20260319163251.1808611-4-Raju.Rangoju@amd.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Optimize the TX shutdown sequence when link goes down by skipping
futile hardware wait operations and immediately stopping TX queues.
Current behavior creates delays and resource issues during link-down:
1. xgbe_txq_prepare_tx_stop() waits up to XGBE_DMA_STOP_TIMEOUT for
TX queues to drain, but when link is down, hardware will never
complete the pending descriptors. This causes unnecessary delays
during interface shutdown.
2. TX queues remain active after link-down, allowing the network stack
to continue queuing packets that cannot be transmitted. This leads
to resource buildup and complicates recovery.
This patch adds two optimizations:
Optimization 1: Skip TX queue drain when link is down
In xgbe_txq_prepare_tx_stop(), detect link-down state and return
immediately instead of waiting for hardware. Abandoned descriptors
will be cleaned up by the force-cleanup mechanism (next patch).
Optimization 2: Immediate TX queue stop on link-down
In xgbe_phy_adjust_link(), call netif_tx_stop_all_queues() as soon
as link-down is detected. Also wake TX queues on link-up to resume
transmission.
Benefits:
- Faster interface shutdown (no pointless timeout waits)
- Prevents packet queue buildup in network stack
- Cleaner state management during link transitions
- Enables orderly descriptor cleanup by NAPI poll
Note: We do not call netdev_tx_reset_queue() on link-down because
NAPI poll may still be running, which would trigger BQL assertions.
BQL state is cleaned up naturally during descriptor reclamation.
Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
Link: https://patch.msgid.link/20260319163251.1808611-3-Raju.Rangoju@amd.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Implement adaptive link status polling to enable fast link-down detection
while conserving CPU resources during link-down periods.
Currently, the driver polls link status at a fixed 1-second interval
regardless of link state. This creates a trade-off:
- Slow polling (1s): Misses rapid link state changes, causing delays
- Fast polling: Wastes CPU when link is stable or down
This enhancement introduces state-aware polling:
When carrier is UP:
Poll every 100ms to enable rapid link-down detection. This provides
~100-200ms response time to link failures, minimizing packet loss and
enabling fast failover in link aggregation configurations.
When carrier is DOWN:
Poll every 1s to conserve CPU resources. Link-up detection is less
time-critical since no traffic is flowing.
Performance impact:
- Link-down detection: 1000ms → 100-200ms (10x improvement)
- CPU overhead when link up: 0.1% → 1% (acceptable for active links)
- CPU overhead when link down: unchanged at 0.1%
This is particularly valuable for:
- Link aggregation deployments requiring sub-second failover
- Environments with flaky links or cable issues
- Applications sensitive to connection recovery time
Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
Link: https://patch.msgid.link/20260319163251.1808611-2-Raju.Rangoju@amd.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The io_uring_zerocopy.sh kselftest assumes that io_uring support is
enabled on the host system. When io_uring is disabled via the
kernel.io_uring_disabled sysctl, the test fails.
Explicitly enable io_uring for the test by setting
kernel.io_uring_disabled=0.
Save the original value of kernel.io_uring_disabled before changing
it and restore it in cleanup handler to ensure the system state is
restored regardless of test outcome.
Signed-off-by: Aleksei Oladko <aleksey.oladko@virtuozzo.com>
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
Link: https://patch.msgid.link/20260321215908.175465-5-aleksey.oladko@virtuozzo.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The reuseport_* tests (bpf, bpf_cpu, bpf_numa, dualstack) currently use
a fixed port range. This can cause intermittent test failures when the
ports are already in use by other services:
failed to bind receive socket: Address already in use
To avoid conflicts, run these tests in separate network namespaces using
unshare. Each test now has its own isolated network stack, preventing
port collisions with the host services.
Signed-off-by: Aleksei Oladko <aleksey.oladko@virtuozzo.com>
Link: https://patch.msgid.link/20260321215908.175465-2-aleksey.oladko@virtuozzo.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Allison Henderson says:
====================
selftests: rds: add config file and config.sh -c option
This series adds an RDS-specific config file for ksft CI and extends
config.sh with a -c flag to specify an alternate config file path.
Users can now specify the path of the config they want to update, or
default to .config if none is specified.
====================
Link: https://patch.msgid.link/20260320041834.2761069-1-achender@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch adds a new -c flag to config.sh that enables callers
to specify the file path of the config they would like to update.
If no config is specified, the default will be the .config of the
current directory.
Signed-off-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20260320041834.2761069-3-achender@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ksft CI runtime needs an rds specific config file to build a
minimal kernel with the right options enabled. This patch adds
an rds selftest config containing the required CONFIG_RDS* and
CONFIG_NET_* options.
Signed-off-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20260320041834.2761069-2-achender@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a selftest to reproduce the infinite recursion in bond_header_parse()
when bonds are stacked (bond1 -> bond0 -> gre). When a packet is received
via AF_PACKET SOCK_DGRAM on the topmost bond, dev_parse_header() calls
bond_header_parse() which used skb->dev (always the topmost bond) to get
the bonding struct. This caused it to recurse back into itself
indefinitely, leading to stack overflow.
Before commit b7405dcf73 ("bonding: prevent potential infinite loop
in bond_header_parse()"), the test triggers:
./bond_stacked_header_parse.sh
[ 71.999481] BUG: MAX_LOCK_DEPTH too low!
[ 72.000170] turning off the locking correctness validator.
[ 72.001029] Please attach the output of /proc/lock_stat to the bug report
[ 72.002079] depth: 48 max: 48!
...
After the fix, everything works fine:
./bond_stacked_header_parse.sh
TEST: Stacked bond header_parse does not recurse [ OK ]
Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
Link: https://patch.msgid.link/20260320022245.392384-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
All six PTP-over-IP test frames (3x IPv4 + 3x IPv6) contain incorrect
UDP checksums. The stored values are the ones-complement sums of just
the pseudo-headers, not the complete UDP checksums over pseudo-header +
UDP header + payload. This is characteristic of frames captured on the
sender before TX checksum offload completion.
For example, the IPv4 Sync and Follow-Up frames both store checksum
0xa3c8 despite having different UDP payloads and port numbers - 0xa3c8
is their shared pseudo-header sum (same src/dst IP, same protocol and
UDP length).
While most L2 switches forward frames without verifying transport
checksums, hardware that performs deep packet inspection or has PTP
awareness may validate UDP checksums and drop frames that fail
verification. This causes the 1588v2 over IPv4/IPv6 tests to fail on
such hardware even though L2 PTP (which has no UDP checksum) passes
fine.
Replace all six pseudo-header partial sums with the correctly computed
full UDP checksums:
IPv4 Sync: 0xa3c8 -> 0x9f41
IPv4 Follow-Up: 0xa3c8 -> 0xeb8a
IPv4 Peer Delay Req: 0xa2bc -> 0x9ab9
IPv6 Sync: 0x2e92 -> 0x1476
IPv6 Follow-Up: 0x2e92 -> 0xf047
IPv6 Peer Delay Req: 0xb454 -> 0x891f
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://patch.msgid.link/651c3decb80023e4395ec149fd81110afa3869a1.1774067006.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Björn Töpel says:
====================
ethtool: Dynamic RSS context indirection table resizing
Some NICs (e.g. bnxt) change their RSS indirection table size based on
the queue count, because the hardware table is a shared resource. The
ethtool core locks ctx->indir_size at context creation, so drivers
have to reject channel changes when RSS contexts exist.
This series adds resize helpers and wires them up in bnxt. It also
adds tracking of the user provided indirection table size to the
ethtool core.
Patch 1 tracks the user-provided indirection table size (user_size)
in ctx->indir_user_size for non-default RSS contexts and in
dev->ethtool->rss_indir_user_size for context 0. It is set when the
indirection table is configured via netlink or ioctl, and cleared to
zero on reset-to-default.
IFF_RXFH_CONFIGURED is removed, and replaced with rss_indir_user_size.
The flag is redundant now that user_size captures the same
information.
Patch 2 adds core resize helpers:
ethtool_rxfh_indir_can_resize() - read-only validation for context 0
ethtool_rxfh_indir_resize() - fold/unfold context 0 table in place
ethtool_rxfh_ctxs_can_resize() - validate all non-default contexts
ethtool_rxfh_ctxs_resize() - resize all non-default contexts,
with locking and RSS_NTF notifications
Patch 3 uses the resize helpers in bnxt_set_channels().
Patch 4 adds HW tests in rss_drv.py (devices without dynamic table
sizing are skipped):
resize_periodic - fold/unfold with a non-default [3,2,1,0]
sub-table (user_size=4), verifying exact content preservation
(main + ctx)
resize_below_user_size_reject - periodic sub-table with user_size
between big and small device table sizes; verifies that shrinking
below user_size is rejected even when the table is periodic
(main + ctx)
resize_nonperiodic_reject - non-periodic table blocks channel
reduction, with an extra periodic context to exercise
multi-context validation (main + ctx)
resize_nonperiodic_no_corruption - failed resize leaves table
contents and channel count unchanged (main + ctx)
Running the tests:
# On real hardware
sudo NETIF=eth0 ./rss_drv.py
====================
Link: https://patch.msgid.link/20260320085826.1957255-1-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add resize tests to rss_drv.py. Devices without dynamic table sizing
are skipped via _require_dynamic_indir_size().
resize_periodic: set a periodic 4-entry table, shrink channels to
fold, grow back to unfold. Check the exact pattern is preserved. Has
main and non-default context variants.
resize_below_user_size_reject: send a periodic table with user_size
between the big and small device table sizes. Verify that shrinking
below user_size is rejected even though the table is periodic. Has
main and non-default context variants.
resize_nonperiodic_reject: set a non-periodic table (equal N), verify
that channel reduction is rejected.
resize_nonperiodic_no_corruption: verify a failed resize leaves both
the indirection table contents and the channel count unchanged.
Signed-off-by: Björn Töpel <bjorn@kernel.org>
Link: https://patch.msgid.link/20260320085826.1957255-5-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
bnxt_set_channels() previously rejected channel changes that alter the
RSS table size when RSS contexts exist, because non-default context
sizes were locked at creation.
Replace the rejection with the new resize helpers.
RSS table size only changes on P5 chips with older firmware; newer
firmware always uses the largest table size.
Signed-off-by: Björn Töpel <bjorn@kernel.org>
Link: https://patch.msgid.link/20260320085826.1957255-4-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The core locks ctx->indir_size when an RSS context is created. Some
NICs (e.g. bnxt) change their indirection table size based on the
channel count, because the hardware table is a shared resource. This
forces drivers to reject channel changes when RSS contexts exist.
Add driver helpers to resize indirection tables:
ethtool_rxfh_indir_can_resize() checks whether the default context
indirection table can be resized.
ethtool_rxfh_indir_resize() resizes the default context table in
place. Folding (shrink) requires the table to be periodic at the new
size; non-periodic tables are rejected. Unfolding (grow) replicates
the existing pattern. Sizes must be multiples of each other.
ethtool_rxfh_ctxs_can_resize() validates all non-default RSS contexts
can be resized.
ethtool_rxfh_ctxs_resize() applies the resize.
Signed-off-by: Björn Töpel <bjorn@kernel.org>
Link: https://patch.msgid.link/20260320085826.1957255-3-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Track the number of indirection table entries the user originally
provided (context 0/default as well!).
Replace IFF_RXFH_CONFIGURED with rss_indir_user_size: the flag is
redundant now that user_size captures the same information.
Add ethtool_rxfh_indir_lost() for drivers that must reset the
indirection table.
Convert bnxt and mlx5 to use it.
Signed-off-by: Björn Töpel <bjorn@kernel.org>
Link: https://patch.msgid.link/20260320085826.1957255-2-bjorn@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a helper to get netdev from private data pointer, so drivers won't
have to store redundant netdev in priv.
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
Link: https://patch.msgid.link/20260320075605.490832-1-dqfext@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This driver includes the legacy header <linux/gpio.h> but does
not use any symbols from it. Drop the inclusion.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260320215230.3236005-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
Link: https://patch.msgid.link/20260305104313.15898-1-johan@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Russell King says:
====================
net: stmmac: improve PCS support
This series is the next of the three part series sorting out the PCS
support in stmmac, building on part 2:
net: stmmac: qcom-ethqos: further serdes reorganisation
Similar patches have been posted previously. This series does away with
the common SerDes PHY support, instead using a flag to indicate whether
2500Mbps mode is supported (STMMAC_FLAG_SERDES_SUPPORTS_2500M.) At this
time, I have no plans to resurect the common SerDes PHY support - the
generic PHY layer implementations are just too random to consider that,
and I certainly do not want the extra work of fixing that.
The reasoning here is that these patches should be safe to merge and
should not impact qcom-ethqos in any way.
We can then figure out how to work around qcom-ethqos hacks without
having to keep re-posting these same patches time and time again.
====================
Link: https://patch.msgid.link/abrNYVfZ1Iwff2EI@shell.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dwmac-qcom-ethqos supports SGMII and 2500BASE-X using the integrated
PCS, so we need to expand the PCS support to include support for
BASE-X modes.
Add support to the prereset configuration to detect 2500BASE-X, and
arrange for stmmac_mac_select_pcs() to return the integrated PCS if
its supported_interfaces bitmap reports support for the interface mode.
This results in priv->hw->pcs now being write-only, so remove it.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1w2tPj-0000000DYAv-2JcZ@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The integrated PCS supports 802.3z (BASE-X) modes when the Synopsys
IP is coupled with an appropriate SerDes to provide the electrical
interface. The PCS presents a TBI interface to the SerDes for this.
Thus, the BASE-X related registers are only present when TBI mode is
supported.
dwmac-qcom-ethqos added support for using 2.5G with the integrated PCS
by calling dwmac_ctrl_ane() directly.
Add support for the following to the integrated PCS:
- 1000BASE-X protocol unconditionally.
- 2500BASE-X if the coupled SerDes supports 2.5G speed.
- The above without autonegotiation.
- If the PCS supports TBI, then optional BASE-X autonegotiation for each
of the above.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1w2tPe-0000000DYAp-1qpV@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Report the link, speed and duplex for SGMII links, read from the
SGMII, RGMII and SMII status and control register.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1w2tPZ-0000000DYAj-1MdI@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
We need to describe one more register (offset and field bitmask) to
the PCS code. Move the existing PCS offset and interrupt enable bits
to a new struct and pass that in to stmmac_integrated_pcs_init().
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1w2tPU-0000000DYAd-0ssk@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Move the default_an_inband flag from struct mdio_bus_data to struct
plat_stmmacenet_data. This is to allow platforms that do not use the
integrated MDIO bus to enable inband mode.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1w2tPP-0000000DYAX-0TKw@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Davide Caratti says:
====================
netdevsim: support ETS offload
- patch 1 moves netdevsim tc offloads to a dedicated file
- patch 2 enables ETS offload on netdevsim
- patch 3 is a tdc test for ets offload on netdevsim
====================
Link: https://patch.msgid.link/cover.1773945414.git.dcaratti@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
While reviewing the fix for unintentional u32 overflows in ets offload
code, Jamal said:
[...]
> otherwise a tdc test should cover it fine (when you get to the
> netdevsim change perhaps)
Extend tdc to allow setting hw-tc-offload via ethtool, and
add a test case to reproduce the division by zero fixed in [1].
[1] https://lore.kernel.org/all/CAM0EoMm17wsYZmdFLshH3_-GrZtzd=i0xnoO2yiVB=-N4761mw@mail.gmail.com/
Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Co-developed-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Link: https://patch.msgid.link/39129c374cbd00147b8c5afc04db59db62b50acc.1773945414.git.dcaratti@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix the format hint by replacing "unit" with "uint" in the pr_err() string.
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260319060812.495488-1-alok.a.tiwari@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
set_rx_mode handler was skipped on uplink representor, since uplink
relies on FDB to forward all traffic to it by default, which works
perfectly on a single PF per physical port configuration, as explicit
mac request isn't required, but In case of multi-host and DPU
environments, uplink can only use own mac address, as set_rx_mode
wasn't honored in uplink rep.
Since MPFs (Multi PF switch) requires PFs to request explicit mac
forwarding, this patch enables set_rx_mode on uplink representor to
allow PF mac programming into MPFs table in switchdev mode, allowing
use-cases such as arbitrary mac address forwarding via linux bridge.
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260319005456.82745-1-saeed@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ9477 maintains the SGMII port's state for speed, duplex and link
status to be able to fixup the accesses to its internal older version of
the Designware XPCS. However, it does so by embedding a full instance of
struct phy_device, only to use the 'speed', 'link' and 'duplex' fields.
This is also only used for the SGMII port, it's otherwise unused for all
other regular ports.
Replace that with simple int/bool values.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260319181705.1576679-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Damien Dejean says:
====================
net: phy: realtek: pair order and polarity
The RTL8224 PHY gives the manufacturer some flexbility with the pair
order and polarity to ease the wiring on the PCB. Then the correct pair
order and pair polarity must be provided to the PHY to function
properly. This series adds the support to configure the pair order and
the pair polarity to the Realtek PHY driver.
====================
Link: https://patch.msgid.link/20260318215502.106528-1-dam.dejean@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The RTL8224 has a register to configure the polarity of every pair of
each port. It provides device designers more flexbility when wiring the
chip.
Unfortunately, the register is left in an unknown state after a reset.
Thus on devices where the bootloader don't initialize it, the driver has
to do it to detect and use a link.
The MDI polarity swap can be set in the device tree using the property
enet-phy-pair-polarity. The u32 value is a bitfield where bit[0..3]
control the polarity of pairs A..D.
Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
Link: https://patch.msgid.link/20260318215502.106528-5-dam.dejean@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add the property enet-phy-pair-polarity to describe the polarity of the
PHY pairs. To ease PCB designs some manufacturers allow to wire the
pairs with a reverse polarity and provide a way to configure it.
The property 'enet-phy-pair-polarity' sets the polarity of each pair.
Bit 0 to 3 configure the polarity or pairs A to D, if set to 1 the
polarity is reversed for this pair.
Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260318215502.106528-4-dam.dejean@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The RTL8224 has a register to configure a pair swap (from ABCD order to
DCBA) providing PCB designers more flexbility when wiring the chip. The
swap parameter has to be set correctly for each of the 4 ports before
the chip can detect a link.
After a reset, this register is (unfortunately) left in a random state,
thus it has to be initialized. On most of the devices the bootloader
does it once for all and we can rely on the value set, on some other it
is not and the kernel has to do it.
The MDI pair swap can be set in the device tree using the property
enet-phy-pair-order. The property is set to 0 to keep the default order
(ABCD), or 1 to reverse the pairs (DCBA).
Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
Link: https://patch.msgid.link/20260318215502.106528-3-dam.dejean@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add property enet-phy-pair-order to the device tree bindings to define
the pair order of the PHY. To simplify PCB design some manufacturers
allow to wire the pairs in a reverse order, and change the order in
software.
The property can be set to 0 to force the normal pair order (ABCD), or 1
to force the reverse pair order (DCBA).
Signed-off-by: Damien Dejean <dam.dejean@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260318215502.106528-2-dam.dejean@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Most local #include in the ethtool command handling is out of order,
with either :
#include "netlink.h"
#include "common.h"
or even :
#include "netlink.h"
#include "common.h"
#include "bitset.h"
One of the reasons is because bitset.h s lacking definitions for
nlattr, netlink_ext_ack, ETH_GSTRING_LEN, and types such as u32, bool,
etc.
Make bitset.h standalone by including <linux/ethtool.h> for
ETH_GSTRING_LEN, and <linux/netlink.h> for nlattr, netlink_ext_ack and
the rest.
While at it, take a pass on ethnl sources to re-order the local
includes :
- put them after the global includes
- add a newline between global and local includes
- alpha-sort the local includes
One notable exception is the cmis.h include, that needs definitions from
module_fw.h. Keep them in this order for now.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260319180555.1531386-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A warm reset on boards using an EEPROM-only strap configuration (where
no MAC address is set in the image) can cause the driver to incorrectly
revert to RGMII mode. This occurs because the ENET_CONFIG_LOAD_STARTED
bit may not persist or behave as expected.
Update pci11x1x_strap_get_status() to use revision-specific validation:
- For PCI11x1x A0: Continue using the legacy check (config load started
or reset protection) to validate the SGMII strap.
- For PCI11x1x B0 and later: Use the newly available
STRAP_READ_USE_SGMII_EN_ bit in the upper strap register to validate
the lower SGMII_EN bit.
This ensures the SGMII interface is correctly identified even after a
warm reboot.
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Link: https://patch.msgid.link/20260318063228.17110-1-thangaraj.s@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Bobby Eshleman says:
====================
selftests/vsock: support nested VM runner for vmtest.sh
This series fixes a few issues trying to launch vmtest.sh in a nested VM
environment and were discovered when trying to prepare the tests for
netdev CI/CD.
When taken together these patches make vmtest.sh work both on bare metal
and in nested VMs, regardless of the outer VM's user, coincidental path
overlaps, or filesystem settings.
====================
Link: https://patch.msgid.link/20260317-vsock-vmtest-nested-fixes-v2-0-0b3f53b80a0f@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The /root mount introduced for nested VM support shadows any host paths
under /root. This breaks systems where the outer VM runs as root and the
vsock_test binary path is something like:
/root/linux/tools/testing/selftests/vsock/vsock_test
Fix this by copying vsock_test into the temporary home directory that
gets mounted as /root in the guest, and using a relative path to invoke
it.
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Link: https://patch.msgid.link/20260317-vsock-vmtest-nested-fixes-v2-2-0b3f53b80a0f@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When running vmtest.sh inside a nested VM, there occurs a problem
with stacking two sets of virtiofs/overlay layers (the first set from
the outer VM and the second set from the inner VM). The virtme init
scripts (sshd, udhcpd, etc...) fail to execute basic programs (e.g.,
/bin/cat) and load library dependencies (e.g., libpam) due to ESTALE.
This only occurs when both layers (outer and inner) use virtiofs. Work
around this by using 9p in the inner VM via --force-9p.
Additionally, when the outer VM is read-only, the inner VM's attempt at
populating SSH keys to the root filesystem fails:
virtme-ng-init: mkdir: cannot create directory '/root/.cache': Read-only file system
Work around this by creating a temporary home directory with generated
SSH keys and passing it through to the guest as /root via --rwdir.
Disable strict host key checking in vm_ssh() since the VM will be seen
as a new host each run.
The --rw arg had to be removed to prevent a vng complaint about overlay
(in combination with the other parameters). The guest doesn't really
need write access anyway, so this was probably overly permissive to
begin with.
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
Link: https://patch.msgid.link/20260317-vsock-vmtest-nested-fixes-v2-1-0b3f53b80a0f@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
bonding_priv.h only defined DRV_NAME and DRV_DESCRIPTION, but caused
unnecessary recompilation: it included <generated/utsrelease.h> to
define bond_version, which is used solely in bond_procfs.c. With
CONFIG_LOCALVERSION_AUTO=y, utsrelease.h is regenerated on every git
commit, so any git operation triggered recompilation of bond_main.c
which also included bonding_priv.h.
Remove the header entirely, as suggested by Jakub, given the macros on
this file can be integrated into the C files directly.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260318-bond_uts-v2-1-033fe0d4e903@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add debug for the phy_config_inband() call so we can see which inband
modes are being configured at the PHY.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/E1w2mFk-0000000DXW2-2PR9@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Before this patch, the PPE cpu port configuration used for a specific GDM
device was set just running ndo_init() callback during the device
initialization. The selected PPE cpu port configuration depends on the QDMA
block assigned to the GDM port. The QDMA block is selected according to
the GDM port LAN/WAN configuration as specified in the commit
'8737d7194d6d ("net: airoha: select QDMA block according LAN/WAN
configuration"). However, the user selected PPE cpu port configuration can
be different with respect to the one hardcoded in the NPU firmware binary.
The hardcoded NPU PPE cpu port configuration is loaded initializing the PPE
engine running the NPU ops ppe_init() callback in airoha_ppe_offload_setup
routine (this is executed at runtime by the netfilter flowtable
infrastructure during flow offloading).
Reset the PPE cpu port configuration in airoha_ppe_hw_init routine in
order to apply the user requested setup according to the device DTS.
Please note this patch is fixing an issue not visible to the user (so we
do not need to backport it) since airoha_eth driver currently supports just
the internal phy available via the MT7530 DSA switch and there are no WAN
interfaces officially supported since PCS/external phy is not merged
mainline yet (it will be posted with following patches).
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260317-airoha-fix-ppe-def-cpu-v1-1-338533d8e234@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The write loop in mxl862xx_api_wrap() computes the word count as
(size + 1) / 2, rounding up for odd-sized structs.
On the last iteration of an odd-sized buffer it reads a full __le16
from data[i], accessing one byte past the end of the caller's struct.
KASAN catches this as a stack-out-of-bounds read during probe (e.g.
from mxl862xx_bridge_config_fwd() because of the odd length of
sizeof(struct mxl862xx_bridge_config) == 49).
The read-back loop already handles this case, it writes only a single
byte when (i * 2 + 1) == size. The write loop lacked the same guard.
In practice the over-read is harmless: the extra stack byte is sent to
the firmware which ignores trailing data beyond the command's declared
payload size.
Apply the same odd-size last-byte handling to the write path: when the
final word contains only one valid byte, send *(u8 *)&data[i] instead
of le16_to_cpu(data[i]). This is endian-safe because data is
__le16-encoded and the low byte is always at the lowest address
regardless of host byte order.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/83356ad9c9a4470dd49b6b3d661c2a8dd85cc6a1.1773803190.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ACPI driver interface used by the Fujitsu Extended Socket (fjes)
Network Device driver is redundant because its only role is to create
a platform device the fjes platform driver can bind to, which can be
done already at the module initialization time.
Namely, acpi_find_extended_socket_device() looks for the requisite ACPI
device object anyway and it may as well check its resources, and the
platform device can be created when the ACPI object in question
has been found (and it can be freed when the module is unloaded).
Moreover, as a rule, it is better to avoid binding drivers directly to
ACPI device objects [1].
Accordingly, drop fjes_acpi_driver, adjust the module initialization
and exit code as per the above and set the fwnode for the fjes platform
device to point to the corresponding ACPI device object as its ACPI
companion.
While this is not expected to alter functionality, it changes sysfs
layout and so it will be visible to user space.
Link: https://lore.kernel.org/all/2396510.ElGaqSPkdT@rafael.j.wysocki/ [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/12857407.O9o76ZdvQC@rafael.j.wysocki
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
