Sorry for the delayed reply. Some days off kept me away from keyboard

On Thu, 12 Feb 2026 at 11:28, Russell King (Oracle)
[off-list ref] wrote:

On Mon, Feb 09, 2026 at 06:40:11PM -0600, Rob Herring wrote:

quoted

On Tue, Feb 03, 2026 at 05:19:14PM +0100, Vincent Guittot wrote:

quoted

+description: |
+  The SerDes subsystem on S32G SoC Family includes two types of PHYs:
+    - One PCIe PHY: Supports various PCIe operation modes
+    - Two Ethernet Physical Coding Sublayer (XPCS) controllers
+
+  SerDes operation mode selects the enabled PHYs and speeds. Clock frequency
+  must be adapted accordingly. Below table describes all possible operation
+  modes.
+
+  Mode  PCIe       XPCS0           XPCS1           PHY clock       Description
+                SGMII              SGMII             (MHz)
+  -------------------------------------------------------------------------
+  0        Gen3    N/A             N/A             100             Single PCIe
+  1        Gen2    1.25Gbps        N/A             100             PCIe/SGMII
+  2        Gen2    N/A             1.25Gbps        100             PCIe/SGMII
+  3        N/A     1.25Gbps        1.25Gbps        100,125         SGMII
+  4        N/A     3.125/1.25Gbps  3.125/1.25Gbps  125             SGMII
+  5        Gen2    N/A             3.125Gbps       100             PCIe/SGMII

Mixed tabs and spaces. Drop the tabs.

What's not clear to me is do you have 2 or 4 lanes?

...

quoted

quoted

+  nxp,sys-mode:
+    $ref: /schemas/types.yaml#/definitions/uint32

       maximum: 5

Though isn't this redundant with the child nodes? You could use the
standard 'phy-mode' property in each child.

phy-mode is ethernet, but the above is more than just ethernet.

I've been wondering why a generic PHY driver needs to know this via DT
when the generic PHY API has:

phy_set_mode() / phy_set_mode_ext()
 - sets the type of the PHY and its submode (e.g. ethernet interface
    mode)
phy_set_speed()
phy_set_bus_width()

Surely these are sufficient to describe what mode is required from the
generic PHY, and the generic PHY driver can figure out whether the
mode is permitted from the above table, programming the PHY as
desired.

For the lanes that output SGMII, we don't register a generic phy
driver but we provide the pcs with

pcs-handle = <&phy_xpcs0_0>;

For Ethernet, we don't call the 3.125Gbps "SGMII" using that term. We
use SGMII strictly for Cisco SGMII, which runs at 1.25Gbps. 3.125Gbps
single-lane serdes ethernet is not able to use Cisco SGMII inband
signalling because running the underlying data rate with 10 or 100
symbol replications makes no sense. So we have decided to all this
2500BASE-X. If such a SerDes is connected to a SFP cage, then we
support switching between 1.25Gbps and 3.125Gbps mode depending on
the module inserted, which requires dynamic reconfiguration of the
SerDes.

yes, I still have to figure out how to handle 3.125Gbps and 2500BASE-X mode

What I'm saying is that describing a single mode covering several ports
could make things difficult in the future, so make sure you think
carefully.

The serdes mode (deciding wether to output pcie or ethernet for each
lane) has to be decided before de-asserting the reset of the HW IP so
we can't really make it dynamic

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!