JIRA: https://issues.redhat.com/browse/RHEL-100501
commit 1345e9f4e3f3bc7d8a0a2138ae29e205a857a555
Author: Jon Hunter <jonathanh@nvidia.com>
Date: Wed Apr 1 11:29:39 2026 +0100
net: stmmac: Fix PTP ref clock for Tegra234
Since commit 030ce919e114 ("net: stmmac: make sure that ptp_rate is not
0 before configuring timestamping") was added the following error is
observed on Tegra234:
ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed
It turns out that the Tegra234 device-tree binding defines the PTP ref
clock name as 'ptp-ref' and not 'ptp_ref' and the above commit now
exposes this and that the PTP clock is not configured correctly.
In order to update device-tree to use the correct 'ptp_ref' name, update
the Tegra MGBE driver to use 'ptp_ref' by default and fallback to using
'ptp-ref' if this clock name is present.
Fixes: d8ca113724 ("net: stmmac: tegra: Add MGBE support")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260401102941.17466-2-jonathanh@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 8c01cc2382bc351672c8eb946c16f567cfffef60
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Date: Wed Sep 10 21:41:22 2025 +0100
dt-bindings: net: pcs: renesas,rzn1-miic: Add RZ/T2H and RZ/N2H support
Add device tree binding support for RZ/T2H and RZ/N2H SoCs to the
existing RZ/N1 MIIC converter binding. These SoCs share similar MIIC
functionality but have architectural differences that require schema
updates.
Add new compatible strings "renesas,r9a09g077-miic" for RZ/T2H and
"renesas,r9a09g087-miic" for RZ/N2H, with the latter falling back to
the RZ/T2H variant. The new SoCs require reset support with two reset
lines for converter register reset and converter reset, which are not
present on RZ/N1.
Update port configurations to accommodate the different architectures.
RZ/N1 supports 5 ports numbered 1-5 with complex input mappings
covering indices 0-13, while RZ/T2H and RZ/N2H support 4 ports
numbered 0-3 with simplified input mappings covering indices 0-8.
Extend the switch port configuration property to support value 0 for
the new SoCs.
Add a new dt-bindings header file with media interface connection
matrix constants that map GMAC, ESC, and ETHSW ports to numeric
identifiers for use with RZ/T2H and RZ/N2H device trees.
Update DT schema validation to ensure proper port numbering and input
mappings per SoC variant.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20250910204132.319975-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
Conflicts: Only the stmmac driver changes were applies, as the rest of
the patch is aalready present in RHEl
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 9ff2aa4206eff40a202e425f232036bc84ad4c0e
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Mon Mar 17 23:07:30 2025 -0400
net: ethtool: mm: extract stmmac verification logic into common library
It appears that stmmac is not the only hardware which requires a
software-driven verification state machine for the MAC Merge layer.
While on the one hand it's good to encourage hardware implementations,
on the other hand it's quite difficult to tolerate multiple drivers
implementing independently fairly non-trivial logic.
Extract the hardware-independent logic from stmmac into library code and
put it in ethtool. Name the state structure "mmsv" for MAC Merge
Software Verification. Let this expose an operations structure for
executing the hardware stuff: sync hardware with the tx_active boolean
(result of verification process), enable/disable the pMAC, send mPackets,
notify library of external events (reception of mPackets), as well as
link state changes.
Note that it is assumed that the external events are received in hardirq
context. If they are not, it is probably a good idea to disable hardirqs
when calling ethtool_mmsv_event_handle(), because the library does not
do so.
Also, the MM software verification process has no business with the
tx_min_frag_size, that is all the driver's to handle.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Co-developed-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Signed-off-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Tested-by: Choong Yong Liang <yong.liang.choong@linux.intel.com>
Tested-by: Furong Xu <0x1207@gmail.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit d9db25723677c3741a0cf3643f7f7429fc983921
Author: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Date: Thu Nov 13 11:27:20 2025 +0000
net: stmmac: Fix VLAN 0 deletion in vlan_del_hw_rx_fltr()
When the "rx-vlan-filter" feature is enabled on a network device, the 8021q
module automatically adds a VLAN 0 hardware filter when the device is
brought administratively up.
For stmmac, this causes vlan_add_hw_rx_fltr() to create a new entry for
VID 0 in the mac_device_info->vlan_filter array, in the following format:
VLAN_TAG_DATA_ETV | VLAN_TAG_DATA_VEN | vid
Here, VLAN_TAG_DATA_VEN indicates that the hardware filter is enabled for
that VID.
However, on the delete path, vlan_del_hw_rx_fltr() searches the vlan_filter
array by VID only, without verifying whether a VLAN entry is enabled. As a
result, when the 8021q module attempts to remove VLAN 0, the function may
mistakenly match a zero-initialized slot rather than the actual VLAN 0
entry, causing incorrect deletions and leaving stale entries in the
hardware table.
Fix this by verifying that the VLAN entry's enable bit (VLAN_TAG_DATA_VEN)
is set before matching and deleting by VID. This ensures only active VLAN
entries are removed and avoids leaving stale entries in the VLAN filter
table, particularly for VLAN ID 0.
Fixes: ed64639bc1 ("net: stmmac: Add support for VLAN Rx filtering")
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20251113112721.70500-2-ovidiu.panait.rb@renesas.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit dbbec8c5a79f4c7aa8d07da8c0b5a34d76c50699
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Fri Jan 30 20:04:57 2026 +0000
net: stmmac: fix stm32 (and potentially others) resume regression
Marek reported that suspending stm32 causes the following errors when
the interface is administratively down:
$ echo devices > /sys/power/pm_test
$ echo mem > /sys/power/state
...
ck_ker_eth2stp already disabled
...
ck_ker_eth2stp already unprepared
...
On suspend, stm32 starts the eth2stp clock in its suspend method, and
stops it in the resume method. This is because the blamed commit omits
the call to the platform glue ->suspend() method, but does make the
call to the platform glue ->resume() method.
This problem affects all other converted drivers as well - e.g. looking
at the PCIe drivers, pci_save_state() will not be called, but
pci_restore_state() will be. Similar issues affect all other drivers.
Fix this by always calling the ->suspend() method, even when the network
interface is down. This fixes all the conversions to the platform glue
->suspend() and ->resume() methods.
Link: https://lore.kernel.org/r/20260114081809.12758-1-marex@nabladev.com
Fixes: 07bbbfe7addf ("net: stmmac: add suspend()/resume() platform ops")
Reported-by: Marek Vasut <marex@nabladev.com>
Tested-by: Marek Vasut <marex@nabladev.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vlujh-00000007Hkw-2p6r@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit e8ca461f7d19464b47c64fe4cf2f83162421bcc0
Author: Daniel Golle <daniel@makrotopia.org>
Date: Wed Jan 21 02:23:17 2026 +0000
net: pcs: pcs-mtk-lynxi: report in-band capability for 2500Base-X
It turns out that 2500Base-X actually works fine with in-band status on
MediaTek's LynxI PCS -- I wrongly concluded it didn't because it is
broken in all the copper SFP modules and GPON sticks I used for testing.
Hence report LINK_INBAND_ENABLE also for 2500Base-X mode.
This reverts most of commit a003c38d9bbb ("net: pcs: pcs-mtk-lynxi:
correctly report in-band status capabilities").
The removal of the QSGMII interface mode was correct and is left
untouched.
Link: https://github.com/openwrt/openwrt/issues/21436
Fixes: a003c38d9bbb ("net: pcs: pcs-mtk-lynxi: correctly report in-band status capabilities")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Link: https://patch.msgid.link/b1cf26157b63fee838be09ae810497fb22fd8104.1768961746.git.daniel@makrotopia.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit c171e679ee66d7c0e2b58db9531af96797a76bca
Author: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Date: Thu Nov 13 11:27:21 2025 +0000
net: stmmac: Disable EEE RX clock stop when VLAN is enabled
On the Renesas RZ/V2H EVK platform, where the stmmac MAC is connected to a
Microchip KSZ9131RNXI PHY, creating or deleting VLAN interfaces may fail
with timeouts:
# ip link add link end1 name end1.5 type vlan id 5
15c40000.ethernet end1: Timeout accessing MAC_VLAN_Tag_Filter
RTNETLINK answers: Device or resource busy
Disabling EEE at runtime avoids the problem:
# ethtool --set-eee end1 eee off
# ip link add link end1 name end1.5 type vlan id 5
# ip link del end1.5
The stmmac hardware requires the receive clock to be running when writing
certain registers, such as those used for MAC address configuration or
VLAN filtering. However, by default the driver enables Energy Efficient
Ethernet (EEE) and allows the PHY to stop the receive clock when the link
is idle. As a result, the RX clock might be stopped when attempting to
access these registers, leading to timeouts and other issues.
Commit dd557266cf5fb ("net: stmmac: block PHY RXC clock-stop")
addressed this issue for most register accesses by wrapping them in
phylink_rx_clk_stop_block()/phylink_rx_clk_stop_unblock() calls.
However, VLAN add/delete operations may be invoked with bottom halves
disabled, where sleeping is not allowed, so using these helpers is not
possible.
Therefore, to fix this, disable the RX clock stop feature in the phylink
configuration if VLAN features are set. This ensures the RX clock remains
active and register accesses succeed during VLAN operations.
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/20251113112721.70500-3-ovidiu.panait.rb@renesas.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit bb68e0183e0452d0a1f3af747ec33976a9335ee5
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Tue Nov 11 08:12:43 2025 +0000
net: stmmac: visconti: use PHY_INTF_SEL_x to select PHY interface
Convert dwmac-visconti to use the PHY_INTF_SEL_x definitions. The
original definitions used constant 0, BIT(0) (==1) and BIT(2) (==4)
to define these, but the values of the bits corresponds with the
PHY_INTF_SEL_x values, so it is highly likely that these are not
individual bits, but the PHY_INTF_SEL_x bitfield.
This removes this incorrect use of BIT().
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vIjUZ-0000000Dqu5-2sDI@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 45c5e24a53f10cabb4a311c915680624b832cc2b
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Tue Nov 11 08:12:38 2025 +0000
net: stmmac: stm32: use stmmac_get_phy_intf_sel()
Use stmmac_get_phy_intf_sel() to decode the PHY interface mode to the
phy_intf_sel value. As both configure functions would end up with the
same code, call this from stm32mp1_set_mode(), validate the result and
pass the resulting value into the stm32 configure function. Use this
value to set the operating mode for the DWMAC core.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vIjUU-0000000Dqtz-2PwT@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 73130c298fa0d30f5ead5d9aeb7edc813651a8b3
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Tue Nov 11 08:12:28 2025 +0000
net: stmmac: stm32: use PHY_INTF_SEL_x to select PHY interface
Convert dwmac-stm32 to use the PHY_INTF_SEL_x definitions.
For stm32mp1, the original definitions used constant 0 (GMII, 0 << 21),
BIT(21) (RGMII, 1 << 21) and BIT(23) (RMII, 4 << 21) to define these,
but from the values it can be clearly seen that these are the
PHY_INTF_SEL_x inputs to the dwmac.
For stm32mp2, the original definitions cover a bitfield 6:4 in the
SYSCFG Ethernet1 control register (according to documentation) and use
the PHY_INTF_SEL_x values.
Use the common dwmac definitions for the PHY interface selection field
by adding the bitfield mask, and using FIELD_PREP() for the bitfield
values.
This removes this incorrect use of BIT().
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vIjUK-0000000Dqtn-1AyK@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 7e975caa0f7bf2f83a5e18b4ae69c3d7fff4eafa
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Tue Nov 11 11:26:34 2025 +0000
net: stmmac: improve ndev->max_mtu setup readability
Improve the readibility of the code setting ndev->max_mtu. This depends
on the hardware specific maximum defined by the MAC core, and also a
platform provided maximum.
The code was originally checking that the platform specific maximum was
between ndev->min_mtu..MAC core maximum before reducing ndev->max_mtu,
otherwise if the platform specific maximum was less than ndev->min_mtu,
issuing a warning.
Re-order the code to handle the case where the platform specific max is
below ndev->min_mtu, which then means that the subsequent test is
simply reducing ndev->max_mtu.
Update the comment, and add a few blank lines to separate the blocks of
code.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vImWA-0000000DrIl-1HZY@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 608975d4d791644d15b286b2b7bfcd25359c979f
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Fri Nov 7 08:29:10 2025 +0000
net: stmmac: ingenic: simplify mac_set_mode() methods
x1000, x1600 and x1830 only accept RMII mode. PHY_INTF_SEL_RMII is only
selected with PHY_INTERFACE_MODE_RMII, and PHY_INTF_SEL_RMII has been
validated by the SoC's .valid_phy_intf_sel bitmask. Thus, checking the
interface mode in these functions becomes unnecessary. Remove these.
jz4775 is similar, except for a greater set of PHY_INTF_SEL_x valies.
Also remove the switch statement here.
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vHHqI-0000000DjrV-3ygL@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit ef5e870be90ffc390ae9afc0b50d411d3538126c
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Thu Nov 6 11:23:47 2025 +0000
net: stmmac: sti: use stmmac_get_phy_intf_sel()
Use stmmac_get_phy_intf_sel() to decode the PHY interface mode to the
phy_intf_sel value, validate the result and use that to set the
control register to select the operating mode for the DWMAC core.
Note that when an unsupported interface mode is used, the array would
decode this to PHY_INTF_SEL_GMII_MII, so preserve this behaviour.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vGy5j-0000000DhQh-2e0x@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit fd8c4f6454963aa7ea895657472aa57f33779d57
Author: Rohan G Thomas <rohan.g.thomas@altera.com>
Date: Sat Nov 1 01:27:10 2025 +0800
net: stmmac: socfpga: Add hardware supported cross-timestamp
Cross timestamping is supported on Agilex5 platform with Synchronized
Multidrop Timestamp Gathering(SMTG) IP. The hardware cross-timestamp
result is made available the applications through the ioctl call
PTP_SYS_OFFSET_PRECISE, which inturn calls stmmac_getcrosststamp().
Device time is stored in the MAC Auxiliary register. The 64-bit System
time (ARM_ARCH_COUNTER) is stored in SMTG IP. SMTG IP is an MDIO device
with 0xC - 0xF MDIO register space holds 64-bit system time.
This commit is similar to following commit for Intel platforms:
Commit 341f67e424 ("net: stmmac: Add hardware supported cross-timestamp")
Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
Link: https://patch.msgid.link/20251101-agilex5_ext-v2-4-a6b51b4dca4d@altera.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 93d46ea3e984323fae0e5d2919cf5817e1297d41
Author: Rohan G Thomas <rohan.g.thomas@altera.com>
Date: Sat Nov 1 01:27:07 2025 +0800
net: stmmac: socfpga: Agilex5 EMAC platform configuration
Agilex5 HPS EMAC uses the dwxgmac-3.10a IP, unlike previous socfpga
platforms which use dwmac1000 IP. Due to differences in platform
configuration, Agilex5 requires a distinct setup.
Introduce a setup_plat_dat() callback in socfpga_dwmac_ops to handle
platform-specific setup. This callback is invoked before
stmmac_dvr_probe() to ensure the platform data is correctly
configured. Also, implemented separate setup_plat_dat() callback for
current socfpga platforms and Agilex5.
Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20251101-agilex5_ext-v2-1-a6b51b4dca4d@altera.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit c012710c14a70dfa21691e2542d18dd4b621c518
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Mon Nov 3 11:50:31 2025 +0000
net: stmmac: imx: use stmmac_get_phy_intf_sel()
i.MX implementations other than IMX8DXL involve setting the dwmac core
phy_intf_sel input. Use stmmac_get_phy_intf_sel() to decode the PHY
interface mode to the phy_intf_sel value, validating the result, and
passing it into the implementation specific .set_intf_mode() method
rather than each .set_intf_mode() method doing this.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vFt4x-0000000ChpA-1Edr@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 1b6aa81c85621d6b55099906585ff09a477203b8
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Mon Nov 3 11:50:15 2025 +0000
net: stmmac: add support for configuring the phy_intf_sel inputs
When dwmac is synthesised with support for multiple PHY interfaces, the
core provides phy_intf_sel inputs, sampled on reset, to configure the
PHY facing interface. Use stmmac_get_phy_intf_sel() in core code to
determine the dwmac phy_intf_sel input value, and provide a new
platform method called with this value just before we issue a soft
reset to the dwmac core.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vFt4h-0000000Chos-3wxX@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit b459790d3fd6d7ead31182ae0cd8632fe79deed6
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Mon Nov 3 11:50:10 2025 +0000
net: stmmac: add stmmac_get_phy_intf_sel()
Provide a function to translate the PHY interface mode to the
phy_intf_sel pin configuration for dwmac1000 and dwmac4 cores that
support multiple interfaces. We currently handle MII, GMII, RGMII,
SGMII, RMII and REVMII, but not TBI, RTBI nor SMII as drivers do not
appear to use these three and the driver doesn't currently support
these.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vFt4c-0000000Choe-3SII@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 9b443e58a896fce4d377d83da8dfd083664d8739
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Thu Oct 30 10:20:32 2025 +0000
net: stmmac: qcom-ethqos: remove MAC_CTRL_REG modification
When operating in "SGMII" mode (Cisco SGMII or 2500BASE-X), qcom-ethqos
modifies the MAC control register in its ethqos_configure_sgmii()
function, which is only called from one path:
stmmac_mac_link_up()
+- reads MAC_CTRL_REG
+- masks out priv->hw->link.speed_mask
+- sets bits according to speed (2500, 1000, 100, 10) from priv->hw.link.speed*
+- ethqos_fix_mac_speed()
| +- qcom_ethqos_set_sgmii_loopback(false)
| +- ethqos_update_link_clk(speed)
| `- ethqos_configure(speed)
| `- ethqos_configure_sgmii(speed)
| +- reads MAC_CTRL_REG,
| +- configures PS/FES bits according to speed
| `- writes MAC_CTRL_REG as the last operation
+- sets duplex bit(s)
+- stmmac_mac_flow_ctrl()
+- writes MAC_CTRL_REG if changed from original read
...
As can be seen, the modification of the control register that
stmmac_mac_link_up() overwrites the changes that ethqos_fix_mac_speed()
does to the register. This makes ethqos_configure_sgmii()'s
modification questionable at best.
Analysing the values written, GMAC4 sets the speed bits as:
speed_mask = GMAC_CONFIG_FES | GMAC_CONFIG_PS
speed2500 = GMAC_CONFIG_FES B14=1 B15=0
speed1000 = 0 B14=0 B15=0
speed100 = GMAC_CONFIG_FES | GMAC_CONFIG_PS B14=1 B15=1
speed10 = GMAC_CONFIG_PS B14=0 B15=1
Whereas ethqos_configure_sgmii():
2500: clears ETHQOS_MAC_CTRL_PORT_SEL B14=X B15=0
1000: clears ETHQOS_MAC_CTRL_PORT_SEL B14=X B15=0
100: sets ETHQOS_MAC_CTRL_PORT_SEL | B14=1 B15=1
ETHQOS_MAC_CTRL_SPEED_MODE
10: sets ETHQOS_MAC_CTRL_PORT_SEL B14=0 B15=1
clears ETHQOS_MAC_CTRL_SPEED_MODE
Thus, they appear to be doing very similar, with the exception of the
FES bit (bit 14) for 1G and 2.5G speeds.
Given that stmmac_mac_link_up() will write the MAC_CTRL_REG after
ethqos_configure_sgmii(), remove the unnecessary update in the
glue driver's ethqos_configure_sgmii() method, simplifying the code.
Konrad states:
Without any additional knowledge, the register description says:
2500: B14=1 B15=0
1000: B14=0 B15=0
100: B14=1 B15=1
10: B14=0 B15=1
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vEPlg-0000000CFHY-282A@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit cf35f4347ddd42ceca156e57a87ec489788f1bd7
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat Oct 25 20:35:47 2025 +0200
net: stmmac: mdio: fix incorrect phy address check
max_addr is the max number of addresses, not the highest possible address,
therefore check phydev->mdio.addr > max_addr isn't correct.
To fix this change the semantics of max_addr, so that it represents
the highest possible address. IMO this is also a little bit more intuitive
wrt name max_addr.
Fixes: 4a107a0e8361 ("net: stmmac: mdio: use phy_find_first to simplify stmmac_mdio_register")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Reported-by: Simon Horman <horms@kernel.org>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/e869999b-2d4b-4dc1-9890-c2d3d1e8d0f8@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit ded9813d17d3dd50a08e7a2ca1495769ef9c6673
Author: Rohan G Thomas <rohan.g.thomas@altera.com>
Date: Tue Oct 28 11:18:44 2025 +0800
net: stmmac: Consider Tx VLAN offload tag length for maxSDU
Queue maxSDU requirement of 802.1 Qbv standard requires mac to drop
packets that exceeds maxSDU length and maxSDU doesn't include
preamble, destination and source address, or FCS but includes
ethernet type and VLAN header.
On hardware with Tx VLAN offload enabled, VLAN header length is not
included in the skb->len, when Tx VLAN offload is requested. This
leads to incorrect length checks and allows transmission of
oversized packets. Add the VLAN_HLEN to the skb->len before checking
the Qbv maxSDU if Tx VLAN offload is requested for the packet.
Fixes: c5c3e1bfc9 ("net: stmmac: Offload queueMaxSDU from tc-taprio")
Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
Reviewed-by: Matthew Gerlach <matthew.gerlach@altera.com>
Link: https://patch.msgid.link/20251028-qbv-fixes-v4-2-26481c7634e3@altera.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit c657f86106c8729240e1f50a62c6606b578ecf20
Author: Rohan G Thomas <rohan.g.thomas@altera.com>
Date: Tue Oct 28 11:18:43 2025 +0800
net: stmmac: vlan: Disable 802.1AD tag insertion offload
The DWMAC IP's VLAN tag insertion offload does not support inserting
STAG (802.1AD) and CTAG (802.1Q) types in bytes 13 and 14 using the
same MAC_VLAN_Incl and MAC_VLAN_Inner_Incl register configurations.
Currently, MAC_VLAN_Incl is configured to offload only STAG type
insertion. However, the DWMAC IP inserts a CTAG type when the inner
VLAN ID field of the descriptor is not configured, and a STAG type
when it is configured. This behavior is not documented and leads to
inconsistent double VLAN tagging.
Additionally, an unexpected CTAG with VLAN ID 0 is inserted, resulting
in frames like:
Frame 1: 110 bytes on wire (880 bits), 110 bytes captured (880 bits)
Ethernet II, Src: <src> (<src>), Dst: <dst> (<dst>)
IEEE 802.1ad, ID: 100
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 0 (unexpected)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 200
Internet Protocol Version 4, Src: 192.168.4.10, Dst: 192.168.4.11
Internet Control Message Protocol
To avoid this undocumented and incorrect behavior, disable 802.1AD tag
insertion offload. Also, don't set CSVL bit. As per the data book,
when this bit is set, S-VLAN type (0x88A8) is inserted in the 13th and
14th bytes of transmitted packets and when this bit is reset, C-VLAN
type (0x8100) is inserted in the 13th and 14th bytes of transmitted
packets.
Fixes: 30d932279d ("net: stmmac: Add support for VLAN Insertion Offload")
Fixes: e94e3f3b51 ("net: stmmac: Add support for VLAN Insertion Offload in GMAC4+")
Fixes: 1d2c7a5fee31 ("net: stmmac: Refactor VLAN implementation")
Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
Reviewed-by: Boon Khai Ng <boon.khai.ng@altera.com>
Link: https://patch.msgid.link/20251028-qbv-fixes-v4-1-26481c7634e3@altera.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 6911308d7d111a9c367293b52f2dc265819f2b60
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Thu Oct 23 10:16:50 2025 +0100
net: stmmac: convert to phylink-managed Wake-on-Lan
Convert stmmac to use phylink-managed Wake-on-Lan support. To achieve
this, we implement the .mac_wol_set() method, which simply configures
the driver model's struct device wakeup for stmmac, and sets the
priv->wolopts appropriately.
When STMMAC_FLAG_USE_PHY_WOL is set, in the stmmac world this means to
only use the PHY's WoL support and ignore the MAC's WoL capabilities.
To preserve this behaviour, we enable phylink's legacy mode, and avoid
telling phylink that the MAC has any WoL support. This achieves the
same functionality for this case.
When STMMAC_FLAG_USE_PHY_WOL is not set, we provide the MAC's WoL
capabilities to phylink, which then allows phylink to choose between
the PHY and MAC for WoL depending on their individual capabilities
as described in the phylink commit. This only augments the WoL
functionality with PHYs that declare to the driver model that they are
wake-up capable. Currently, very few PHY drivers support this.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://patch.msgid.link/E1vBrRC-0000000BLzg-2tA4@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 2c81f3357136a0ece9b36be991c78a384399eaac
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Thu Oct 16 15:37:52 2025 +0100
net: stmmac: convert to phylink PCS support
Now that stmmac's PCS support is much more simple - just a matter of
configuring the control register - the basic conversion to phylink PCS
support becomes straight forward.
Create the infrastructure to setup a phylink_pcs instance for the
integrated PCS:
- add a struct stmmac_pcs to encapsulate the phylink_pcs structure,
pointer to stmmac_priv, and the core-specific base address of the PCS
registers.
- modify stmmac_priv and stmmac_mac_select_pcs() to return the embedded
phylink_pcs structure when setup and STMMAC_PCS_SGMII is in use, and
move the comment from stmmac_hw_setup() to here.
- create stmmac_pcs.c, which contains the phylink_pcs_ops structure, a
dummy .pcs_get_state() method which always reports link-down, and
.pcs_config() method, moving the call to stmmac_pcs_ctrl_ane() here,
but without indirecting through the dwmac specific core code. The
link-down behaviour mentioned above maintains the current behaviour
when phylink is used with inband but without a PCS.
This will ensure that the PCS control register is configured to the
same settings as before, but will now happen when the netdev is opened
or reusmed rather than only during probe time. However, this will be
before the .fix_mac_speed() method is called, which is critical for the
behaviour in dwmac-qcom-ethqos's ethqos_configure_sgmii() function to
be maintained.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/E1v9P72-0000000AomR-3ro4@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 5c61db08d9aeb960691fae16cfdb23df1355987e
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Thu Oct 16 15:37:37 2025 +0100
net: stmmac: do not require snps,ps-speed for SGMII
SGMII mode does not require port-speed to be specified; this only
switches SGMII to use the MAC configuration register speed settings
and the actual value is irrelevant when the link comes up.
As it seems the intention was to support "reverse SGMII" with this
setting, but the code didn't actually configure that due to a typo,
the warning and bad DT binding documentation has led people to
specify snps,ps-speed in their DT files inappropriately.
If mac_port_sel_speed is zero, then don't complain that the speed
is invalid, as this means we're using "normal" SGMII.
This does _not_ obsolete snps,ps-speed, nor does it change the
behaviour of that property, with the exception of not making people
mistakenly believe that they need to specify this option to use
normal SGMII. There is no need to modify the binding.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/E1v9P6n-0000000Aom9-2LuZ@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit 5d1e7621f869a4d9d1da1652eb2e944784d868d8
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Thu Oct 16 15:37:32 2025 +0100
net: stmmac: hw->ps becomes hw->reverse_sgmii_enable
After a lot of digging, it seems that the oddly named hw->ps member
is all about setting the core into reverse SGMII speed. When set to
a non-zero value, it:
1. Configures the MAC at initialisation time to operate at a specific
speed.
2. It _incorrectly_ enables the transmitter (GMAC_CONFIG_TE) which
makes no sense, rather than enabling the "transmit configuration"
bit (GMAC_CONFIG_TC).
3. It configures the SGMII rate adapter layer to retrieve its speed
setting from the MAC configuration register rather than the PHY.
In the previous commit, we removed (1) and (2) as phylink overwrites
the configuration set at that step.
Thus, the only functional aspect is (3), which is a boolean operation.
This means there is no need to store the actual speed, and just have a
boolean flag.
Convert the priv->ps member to a boolean, and rename it to
priv->reverse_sgmii_enable to make it more understandable.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/E1v9P6i-0000000Aom3-1y2y@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-128151
commit aa1b6775aef74b2177aa72f912564cd064a83b70
Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Date: Thu Oct 16 15:37:11 2025 +0100
net: stmmac: remove hw->ps xxx_core_init() hardware setup
After a lot of digging, it seems that the oddly named hw->ps member is
all about configuring the core for reverse SGMII. This member is set to
one of 0, SPEED_10, SPEED_100 or SPEED_1000 depending on
priv->plat->mac_port_sel_speed. On DT systems, this comes from the
"snps,ps-speed" DT property.
When set to a non-zero value, it:
1. Configures the MAC at initialisation time to operate at a specific
speed. However, this will be overwritten by mac_link_up() when the
link comes up (e.g. with the fixed-link parameters.)
Note that dwxgmac2 wants to also support SPEED_2500 and SPEED_10000,
but both these values are impossible.
2. It _incorrectly_ enables the transmitter (GMAC_CONFIG_TE) which
makes no sense, rather than enabling the "transmit configuration"
bit (GMAC_CONFIG_TC). Likely a typo.
3. It configures the SGMII rate adapter layer to retrieve its speed
setting from the MAC configuration register rather than the PHY.
There are two ways forward here:
a) fixing (2) so that we set GMAC_CONFIG_TC. However, we have platform
that set the "snps,ps-speed" property and that work today. Fixing
this will cause the RGMII, SGMII or SMII inband configuration to be
transmitted, which will be a functional change which could cause a
regression.
b) ripping out (1) and (2) as they are ineffective. This also has the
possibility of regressions, but the patch author believes this risk
is much lower than (a).
Therefore, this commit takes the approach in (b).
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://patch.msgid.link/E1v9P6N-0000000Aolg-3y0a@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Izabela Bakollari <ibakolla@redhat.com>
Izabela Bakollari