[PATCH v2 0/3] Add support for dual port USXGMII+SGMII

[PATCH v2 0/3] Add support for dual port USXGMII+SGMII

[Gokul Praveen]

This patch series enables dual port USXGMII and SGMII Ethernet mode
support on the TI J784S4 EVM platform using the CPSW9G Ethernet switch.

The CPSW9G instance supports both SGMII and USXGMII modes simultaneously
on MAC Ports 1 and 2, which connect to ENET Expansion 1 and ENET
Expansion 2 slots through the SERDES2 instance. The series includes:

1. A fix to the SERDES2 node to add the missing PLL1 refclk, which is
   required for multilink SERDES configuration to function properly.

2. A driver fix for the am65-cpsw Ethernet driver to properly configure
   the MAC in SGMII mode according to the CPSGMII Module specification,
   including correct advertisement ability register settings and master
   mode configuration.

3. Device tree overlay support for two board configurations:
   - Board 1: Port 1 in SGMII mode (1Gbps) + Port 2 in USXGMII mode (5Gbps)
   - Board 2: Port 1 in USXGMII mode (5Gbps) + Port 2 in SGMII mode (1Gbps)

Both configurations use fixed-link mode and provide flexible multi-speed
networking options for the J784S4 platform.

Boot logs:

https://gist.github.com/GokulPraveen2001/7a09cc5ed0151d264f32cbbc31896605

Gokul Praveen (3):
  arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
  net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode
  arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII
    mode

 .../bindings/phy/phy-cadence-torrent.yaml     |  4 +-
 arch/arm64/boot/dts/ti/Makefile               | 11 ++-
 ...s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso | 92 ++++++++++++++++++
 ...s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso | 95 +++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi    |  3 +-
 drivers/net/ethernet/ti/am65-cpsw-nuss.c      |  9 +-
 6 files changed, 205 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
 create mode 100644 arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso

-- 
2.34.1

[PATCH v2 1/3] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node

[Gokul Praveen]

Add PLL1 refclk to "clocks" and "clock-names" parameter of SERDES2 node
as "assigned clocks" parameter has PLL1 and serdes multilink configuration
fails without PLL1.

Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
 .../devicetree/bindings/phy/phy-cadence-torrent.yaml          | 4 ++--
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi                    | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
index 9af39b33646a..54fe78da297a 100644
--- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
@@ -34,7 +34,7 @@ properties:
 
   clocks:
     minItems: 1
-    maxItems: 2
+    maxItems: 3
     description:
       PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
       pll1_refclk is optional and used for multi-protocol configurations requiring
@@ -47,7 +47,7 @@ properties:
     minItems: 1
     items:
       - const: refclk
-      - enum: [ pll1_refclk, phy_en_refclk ]
+      - enum: [refclk, pll1_refclk, phy_en_refclk ]
 
   reg:
     minItems: 1
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index 78fcd0c40abc..da8d582574d0 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -122,8 +122,9 @@ serdes2: serdes@5020000 {
 			resets = <&serdes_wiz2 0>;
 			reset-names = "torrent_reset";
 			clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
+				 <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
 				 <&serdes_wiz2 TI_WIZ_PHY_EN_REFCLK>;
-			clock-names = "refclk", "phy_en_refclk";
+			clock-names = "refclk","pll1_refclk", "phy_en_refclk";
 			assigned-clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
 					  <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
 					  <&serdes_wiz2 TI_WIZ_REFCLK_DIG>;
-- 
2.34.1

Re: [PATCH v2 1/3] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Device Tree Binding Schema validation failure due to missing schema item for the third clock name.
--

commit c724dfc4b95310a6b37f143a703b52391002ee90
Author: Gokul Praveen <g-praveen@ti.com>

arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node

This commit adds the PLL1 refclk to the clocks and clock-names parameters
of the SERDES2 node. It updates both the devicetree binding schema and the
k3-j784s4-main.dtsi file to reflect the new clock.

> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
[ ... ]
> @@ -47,7 +47,7 @@ properties:
>      minItems: 1
>      items:
>        - const: refclk
> -      - enum: [ pll1_refclk, phy_en_refclk ]
> +      - enum: [refclk, pll1_refclk, phy_en_refclk ]

[Severity: Low]
Does this schema correctly allow a third clock name?

The items list here only defines two elements (the const and the enum). Under 
dt-schema rules, any device tree node specifying a third element will fail 
validation because there is no corresponding schema item defined for it in the 
items array.

> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> @@ -122,8 +122,9 @@ serdes2: serdes@5020000 {
>  			resets = <&serdes_wiz2 0>;
>  			reset-names = "torrent_reset";
>  			clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
> +				 <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
>  				 <&serdes_wiz2 TI_WIZ_PHY_EN_REFCLK>;
> -			clock-names = "refclk", "phy_en_refclk";
> +			clock-names = "refclk","pll1_refclk", "phy_en_refclk";

[Severity: Low]
Will this trigger a dtbs_check warning?

Since the device tree node is updated to supply 3 clock-names, but the
YAML schema items list above is still implicitly limited to 2 definitions,
this will likely cause a build-time validation failure.

Should a third item be added to the YAML items array to match this 3-clock
configuration?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629102308.56616-1-g-praveen@ti.com?part=1

Re: [PATCH v2 1/3] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node

[Gokul Praveen]

Hi ,

On 29/06/26 16:01, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Device Tree Binding Schema validation failure due to missing schema item for the third clock name.
> --
>
> commit c724dfc4b95310a6b37f143a703b52391002ee90
> Author: Gokul Praveen <g-praveen@ti.com>
>
> arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
>
> This commit adds the PLL1 refclk to the clocks and clock-names parameters
> of the SERDES2 node. It updates both the devicetree binding schema and the
> k3-j784s4-main.dtsi file to reflect the new clock.
>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
>> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> [ ... ]
>> @@ -47,7 +47,7 @@ properties:
>>       minItems: 1
>>       items:
>>         - const: refclk
>> -      - enum: [ pll1_refclk, phy_en_refclk ]
>> +      - enum: [refclk, pll1_refclk, phy_en_refclk ]
> [Severity: Low]
> Does this schema correctly allow a third clock name?
>
> The items list here only defines two elements (the const and the enum). Under
> dt-schema rules, any device tree node specifying a third element will fail
> validation because there is no corresponding schema item defined for it in the
> items array.
>
Yes, because the description of the "clocks" paremeter in the YAML 
mentions the following:

"PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
       pll1_refclk is optional and used for multi-protocol 
configurations requiring
       separate reference clock for each protocol.
       Same refclk is used for both PLL0 and PLL1 if no separate 
pll1_refclk is used.
       Optional parent clock (phy_en_refclk) to enable a reference clock 
output feature
       on some platforms to output either derived or received reference 
clock.
"

which means that a maximum of 3 clocks can be used (refclk for PLL0, 
pll1_refclk for PLL1, phy_en_refclk for PHY_EN_REFCLK)

>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> @@ -122,8 +122,9 @@ serdes2: serdes@5020000 {
>>   			resets = <&serdes_wiz2 0>;
>>   			reset-names = "torrent_reset";
>>   			clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
>> +				 <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
>>   				 <&serdes_wiz2 TI_WIZ_PHY_EN_REFCLK>;
>> -			clock-names = "refclk", "phy_en_refclk";
>> +			clock-names = "refclk","pll1_refclk", "phy_en_refclk";
> [Severity: Low]
> Will this trigger a dtbs_check warning?
>
> Since the device tree node is updated to supply 3 clock-names, but the
> YAML schema items list above is still implicitly limited to 2 definitions,
> this will likely cause a build-time validation failure.
>
> Should a third item be added to the YAML items array to match this 3-clock
> configuration?
The YAML has already been updated in this patch with a 3-clock 
configuration.
>

Re: [PATCH v2 1/3] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node

[Krzysztof Kozlowski]

On Mon, Jun 29, 2026 at 03:53:06PM +0530, Gokul Praveen wrote:
> Add PLL1 refclk to "clocks" and "clock-names" parameter of SERDES2 node
> as "assigned clocks" parameter has PLL1 and serdes multilink configuration
> fails without PLL1.
> 
> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
> ---

Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.

Best regards,
Krzysztof

Re: [PATCH v2 1/3] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node

[Gokul Praveen]

Hi krzysztof,

On 30/06/26 12:43, Krzysztof Kozlowski wrote:
> On Mon, Jun 29, 2026 at 03:53:06PM +0530, Gokul Praveen wrote:
>> Add PLL1 refclk to "clocks" and "clock-names" parameter of SERDES2 node
>> as "assigned clocks" parameter has PLL1 and serdes multilink configuration
>> fails without PLL1.
>>
>> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
>> ---
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.

Sure, I will fix the warnings. Thank you for the prompt feedback, Krzysztof.

Best Regards

Gokul Praveen

> Best regards,
> Krzysztof
>

[PATCH v2 2/3] net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode

[Gokul Praveen]

Fix MAC configuration of CPSW Ethernet Switch in SGMII mode by
modifying the CPSW_SGMII_MR_ADV_ABILITY_REG and configuring MAC
in master mode as per CPSGMII Module specification.

Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
 drivers/net/ethernet/ti/am65-cpsw-nuss.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 434a31080855..71555d04eb8d 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -84,6 +84,7 @@
 #define AM65_CPSW_SGMII_CONTROL_REG		0x010
 #define AM65_CPSW_SGMII_MR_ADV_ABILITY_REG	0x018
 #define AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE	BIT(0)
+#define AM65_CPSW_SGMII_CONTROL_MASTER          BIT(5)
 
 #define AM65_CPSW_CTL_VLAN_AWARE		BIT(1)
 #define AM65_CPSW_CTL_P0_ENABLE			BIT(2)
@@ -2061,8 +2062,10 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
 
 	if (common->pdata.extra_modes & BIT(state->interface)) {
 		if (state->interface == PHY_INTERFACE_MODE_SGMII) {
-			writel(ADVERTISE_SGMII,
-			       port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
+			writel(ADVERTISE_SGMII | LPA_SGMII_1000FULL | LPA_SGMII_LINK,
+				port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
+			writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE|AM65_CPSW_SGMII_CONTROL_MASTER,
+				port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
 			cpsw_sl_ctl_set(port->slave.mac_sl, CPSW_SL_CTL_EXT_EN);
 		} else {
 			cpsw_sl_ctl_clr(port->slave.mac_sl, CPSW_SL_CTL_EXT_EN);
@@ -2076,8 +2079,6 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
 					CPSW_SL_CTL_XGIG | CPSW_SL_CTL_XGMII_EN);
 		}
 
-		writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
-		       port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
 	}
 }
 
-- 
2.34.1

Re: [PATCH v2 2/3] net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The MAC is unconditionally forced into SGMII MASTER mode and hardcoded to advertise a 1000 Mbps Full-Duplex link, breaking 10/100 Mbps support and standard MAC-to-PHY connections.
- [High] Moving the write to `AM65_CPSW_SGMII_CONTROL_REG` inside the SGMII-only block inadvertently disables auto-negotiation for USXGMII and QSGMII modes.
--

commit f84ed4938492bf35df72f44323de46f0c35177e0
Author: Gokul Praveen <g-praveen@ti.com>

net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode

This modifies the CPSW_SGMII_MR_ADV_ABILITY_REG to update the MAC
configuration of the CPSW Ethernet Switch in SGMII mode. It configures
the MAC in master mode as per the CPSGMII Module specification.

> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> index 7ac75fc8cdcf4..df99a80dbfe1e 100644
> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c

[ ... ]

> @@ -2063,8 +2064,10 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
>  
>  	if (common->pdata.extra_modes & BIT(state->interface)) {
>  		if (state->interface == PHY_INTERFACE_MODE_SGMII) {
> -			writel(ADVERTISE_SGMII,
> -			       port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
> +			writel(ADVERTISE_SGMII | LPA_SGMII_1000FULL | LPA_SGMII_LINK,
> +				port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
> +			writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE|AM65_CPSW_SGMII_CONTROL_MASTER,
> +				port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);

[Severity: High]
Does am65_cpsw_nuss_mac_config() now hardcode the SGMII advertisement to
1000 Mbps Full-Duplex while ignoring the dynamic link parameters in
state->speed and state->duplex?

If the MAC is unconditionally forced into SGMII MASTER mode and forced to
advertise a 1000 Mbps full-duplex link, could this break 10 Mbps and 100 Mbps
connections, as well as standard MAC-to-PHY connections where the PHY expects
to be the SGMII Master?

>  			cpsw_sl_ctl_set(port->slave.mac_sl, CPSW_SL_CTL_EXT_EN);
>  		} else {
>  			cpsw_sl_ctl_clr(port->slave.mac_sl, CPSW_SL_CTL_EXT_EN);
> @@ -2078,8 +2081,6 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
>  					CPSW_SL_CTL_XGIG | CPSW_SL_CTL_XGMII_EN);
>  		}
>  
> -		writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
> -		       port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);

[Severity: High]
Will removing this write and moving it inside the SGMII-only block disable
auto-negotiation for USXGMII and QSGMII modes?

Since this unconditional write enabled auto-negotiation for all extra modes,
moving it to the PHY_INTERFACE_MODE_SGMII branch means it is never configured
when state->interface is USXGMII or QSGMII, which might prevent link
establishment.

>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629102308.56616-1-g-praveen@ti.com?part=2

Re: [PATCH v2 2/3] net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode

[Jakub Kicinski]

On Mon, 29 Jun 2026 15:53:07 +0530 Gokul Praveen wrote:
>  drivers/net/ethernet/ti/am65-cpsw-nuss.c | 9 +++++----

you need to cc netdev@

Re: [PATCH v2 2/3] net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode

[Gokul Praveen]

HI Jakub,

On 30/06/26 03:42, Jakub Kicinski wrote:
> On Mon, 29 Jun 2026 15:53:07 +0530 Gokul Praveen wrote:
>>   drivers/net/ethernet/ti/am65-cpsw-nuss.c | 9 +++++----
> you need to cc netdev@

Thank you for the feedback.

I will cc them surely.

Best Regards

Gokul Praveen

[PATCH v2 3/3] arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII mode

[Gokul Praveen]

The CPSW9G instance of the CPSW Ethernet Switch supports SGMII and
USXGMII mode with MAC Ports 1 and 2 of the instance, which are
connected to ENET Expansion 1 and ENET Expansion 2 slots on
the EVM respectively, through the Serdes2 instance of the SERDES.

Enable CPSW9G MAC Ports 1 and 2 in fixed-link configuration
SGMII and USXGMII mode at 1Gbps and 5 Gbps each.

Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
 arch/arm64/boot/dts/ti/Makefile               | 11 ++-
 ...s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso | 92 ++++++++++++++++++
 ...s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso | 95 +++++++++++++++++++
 3 files changed, 196 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
 create mode 100644 arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso

diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 371f9a043fe5..253706415833 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -199,6 +199,8 @@ dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm-pcie0-pcie1-ep.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm-quad-port-eth-exp1.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm-usxgmii-exp1-exp2.dtbo
 dtb-$(CONFIG_ARCH_K3) += k3-j784s4-j742s2-evm-usb0-type-a.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtbo
 
 # Boards with J742S2 SoC
 dtb-$(CONFIG_ARCH_K3) += k3-j742s2-evm.dtb
@@ -338,6 +340,10 @@ k3-j784s4-evm-usb0-type-a-dtbs := k3-j784s4-evm.dtb \
 	k3-j784s4-j742s2-evm-usb0-type-a.dtbo
 k3-j784s4-evm-usxgmii-exp1-exp2-dtbs := k3-j784s4-evm.dtb \
 	k3-j784s4-evm-usxgmii-exp1-exp2.dtbo
+k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1-dtbs := k3-j784s4-evm.dtb \
+       k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtbo
+k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2-dtbs := k3-j784s4-evm.dtb \
+       k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtbo
 dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
 	k3-am625-beagleplay-csi2-tevi-ov5640.dtb \
 	k3-am625-phyboard-lyra-disable-eth-phy.dtb \
@@ -404,7 +410,8 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
 	k3-j784s4-evm-pcie0-pcie1-ep.dtb \
 	k3-j784s4-evm-quad-port-eth-exp1.dtb \
 	k3-j784s4-evm-usb0-type-a.dtb \
-	k3-j784s4-evm-usxgmii-exp1-exp2.dtb
-
+	k3-j784s4-evm-usxgmii-exp1-exp2.dtb \
+	k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtb \
+	k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtb \
 # Enable support for device-tree overlays
 DTC_FLAGS := -@
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
new file mode 100644
index 000000000000..4ceb99c5c808
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
@@ -0,0 +1,92 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
+/**
+ * DT Overlay for CPSW9G in dual port fixed-link USXGMII mode using ENET-1
+ * and ENET-2 Expansion slots of J784S4 EVM.
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/phy/phy-cadence.h>
+#include <dt-bindings/phy/phy.h>
+
+#include "k3-serdes.h"
+
+&{/} {
+	aliases {
+		ethernet1 = "/bus@100000/ethernet@c000000/ethernet-ports/port@1";
+		ethernet2 = "/bus@100000/ethernet@c000000/ethernet-ports/port@2";
+		ethernet3 = "/bus@100000/ethernet@c200000/ethernet-ports/port@1";
+	};
+};
+
+&main_cpsw0 {
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&main_cpsw0_port1 {
+	phy-mode = "sgmii";
+	mac-address = [00 00 00 00 00 00];
+	phys = <&cpsw0_phy_gmii_sel 1>, <&serdes2_sgmii2_link>;
+	phy-names = "mac", "serdes";
+	status = "okay";
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+&main_cpsw0_port2 {
+	phy-mode = "usxgmii";
+	mac-address = [00 00 00 00 00 00];
+	phys = <&cpsw0_phy_gmii_sel 2>, <&serdes2_usxgmii_link>;
+	phy-names = "mac", "serdes";
+	status = "okay";
+	fixed-link {
+		speed = <5000>;
+		full-duplex;
+	};
+};
+
+&serdes_wiz2 {
+	assigned-clocks = <&k3_clks 406 6>,  <&k3_clks 406 5>;
+	status = "okay";
+};
+
+&serdes2 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	assigned-clock-parents = <&k3_clks 406 5>,
+						 <&k3_clks 406 6>,
+						 <&k3_clks 406 5>;
+
+	serdes2_sgmii2_link: phy@1 {
+		reg = <2>;
+		cdns,num-lanes = <1>;
+		#phy-cells = <0>;
+		cdns,phy-type = <PHY_TYPE_SGMII>;
+		resets = <&serdes_wiz2 3>;
+	};
+	serdes2_usxgmii_link: phy@0 {
+		reg = <3>;
+		cdns,num-lanes = <1>;
+		#phy-cells = <0>;
+		cdns,phy-type = <PHY_TYPE_USXGMII>;
+		resets = <&serdes_wiz2 4>;
+	};
+};
+
+&serdes_ln_ctrl {
+	idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, <J784S4_SERDES0_LANE1_PCIE1_LANE1>,
+		      <J784S4_SERDES0_LANE2_IP3_UNUSED>, <J784S4_SERDES0_LANE3_USB>,
+		      <J784S4_SERDES1_LANE0_PCIE0_LANE0>, <J784S4_SERDES1_LANE1_PCIE0_LANE1>,
+		      <J784S4_SERDES1_LANE2_PCIE0_LANE2>, <J784S4_SERDES1_LANE3_PCIE0_LANE3>,
+		      <J784S4_SERDES2_LANE0_IP2_UNUSED>, <J784S4_SERDES2_LANE1_IP2_UNUSED>,
+		      <J784S4_SERDES2_LANE2_QSGMII_LANE1>, <J784S4_SERDES2_LANE3_QSGMII_LANE2>;
+};
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
new file mode 100644
index 000000000000..ef4ebb551546
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
@@ -0,0 +1,95 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
+/**
+ * DT Overlay for CPSW9G in dual port fixed-link USXGMII mode using ENET-1
+ * and ENET-2 Expansion slots of J784S4 EVM.
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/phy/phy-cadence.h>
+#include <dt-bindings/phy/phy.h>
+
+#include "k3-serdes.h"
+
+&{/} {
+	aliases {
+		ethernet1 = "/bus@100000/ethernet@c000000/ethernet-ports/port@1";
+		ethernet2 = "/bus@100000/ethernet@c000000/ethernet-ports/port@2";
+		ethernet3 = "/bus@100000/ethernet@c200000/ethernet-ports/port@1";
+	};
+};
+
+&main_cpsw0 {
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&main_cpsw0_port1 {
+	phy-mode = "usxgmii";
+	mac-address = [00 00 00 00 00 00];
+	phys = <&cpsw0_phy_gmii_sel 1>, <&serdes2_usxgmii_link>;
+	phy-names = "mac", "serdes";
+	status = "okay";
+	fixed-link {
+		speed = <5000>;
+		full-duplex;
+	};
+};
+
+&main_cpsw0_port2 {
+	phy-mode = "sgmii";
+	mac-address = [00 00 00 00 00 00];
+	phys = <&cpsw0_phy_gmii_sel 2>, <&serdes2_sgmii2_link>;
+	phy-names = "mac", "serdes";
+	status = "okay";
+	fixed-link {
+		speed = <1000>;
+		full-duplex;
+	};
+};
+
+&serdes_wiz2 {
+	assigned-clocks = <&k3_clks 406 6>,  <&k3_clks 406 5>;
+	status = "okay";
+};
+
+&serdes2 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	assigned-clock-parents = <&k3_clks 406 5>,
+						 <&k3_clks 406 6>,
+						 <&k3_clks 406 5>;
+
+
+
+	serdes2_sgmii2_link: phy@1 {
+		reg = <3>;
+		cdns,num-lanes = <1>;
+		#phy-cells = <0>;
+		cdns,phy-type = <PHY_TYPE_SGMII>;
+		resets = <&serdes_wiz2 4>;
+	};
+	serdes2_usxgmii_link: phy@0 {
+		reg = <2>;
+		cdns,num-lanes = <1>;
+		#phy-cells = <0>;
+		cdns,phy-type = <PHY_TYPE_USXGMII>;
+		resets = <&serdes_wiz2 3>;
+	};
+
+};
+
+&serdes_ln_ctrl {
+	idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, <J784S4_SERDES0_LANE1_PCIE1_LANE1>,
+		      <J784S4_SERDES0_LANE2_IP3_UNUSED>, <J784S4_SERDES0_LANE3_USB>,
+		      <J784S4_SERDES1_LANE0_PCIE0_LANE0>, <J784S4_SERDES1_LANE1_PCIE0_LANE1>,
+		      <J784S4_SERDES1_LANE2_PCIE0_LANE2>, <J784S4_SERDES1_LANE3_PCIE0_LANE3>,
+		      <J784S4_SERDES2_LANE0_IP2_UNUSED>, <J784S4_SERDES2_LANE1_IP2_UNUSED>,
+		      <J784S4_SERDES2_LANE2_QSGMII_LANE1>, <J784S4_SERDES2_LANE3_QSGMII_LANE2>;
+};
-- 
2.34.1

Re: [PATCH v2 3/3] arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII mode

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Array length mismatch between `assigned-clocks` and `assigned-clock-parents` in `&serdes_wiz2`.
- [Low] Mismatch between node unit-address and 'reg' property in SerDes PHY links.
- [Low] Dangling continuation backslash on the last item of a Makefile list immediately preceding a comment.
--

commit bc5648306dcc07a1bc8095cecaf3da3724e52d5d
Author: Gokul Praveen <g-praveen@ti.com>

arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII mode

The CPSW9G instance of the CPSW Ethernet Switch supports SGMII and
USXGMII mode with MAC Ports 1 and 2 of the instance, which are
connected to ENET Expansion 1 and ENET Expansion 2 slots on
the EVM respectively, through the Serdes2 instance of the SERDES.
Enable CPSW9G MAC Ports 1 and 2 in fixed-link configuration
SGMII and USXGMII mode at 1Gbps and 5 Gbps each.

> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 5269c9619b65c..72c91f8f7814d 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
[ ... ]
> @@ -337,7 +343,8 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
>  	k3-j784s4-evm-pcie0-pcie1-ep.dtb \
>  	k3-j784s4-evm-quad-port-eth-exp1.dtb \
>  	k3-j784s4-evm-usb0-type-a.dtb \
> -	k3-j784s4-evm-usxgmii-exp1-exp2.dtb
> -
> +	k3-j784s4-evm-usxgmii-exp1-exp2.dtb \
> +	k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtb \
> +	k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtb \
>  # Enable support for device-tree overlays
>  DTC_FLAGS := -@

[Severity: Low]
Does this trailing backslash escape the newline before the comment? Since
Make processes continuations before comments, this merges the comment onto
the dtb- line. If the comment is ever removed, DTC_FLAGS := -@ would be
mistakenly pulled into the dtb- variable.

> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
> new file mode 100644
> index 0000000000000..4ceb99c5c8088
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
[ ... ]
> +&serdes_wiz2 {
> +	assigned-clocks = <&k3_clks 406 6>,  <&k3_clks 406 5>;
> +	status = "okay";
> +};

[Severity: Medium]
Will this 2-element assigned-clocks array work correctly without overriding
the assigned-clock-parents array as well? Since assigned-clock-parents has
only 1 element in the base device tree, the clock framework evaluates
num_parents based on that length and ignores the second clock here, leaving
it unparented.

[ ... ]
> +&serdes2 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	status = "okay";
> +
> +	assigned-clock-parents = <&k3_clks 406 5>,
> +						 <&k3_clks 406 6>,
> +						 <&k3_clks 406 5>;
> +
> +	serdes2_sgmii2_link: phy@1 {
> +		reg = <2>;
> +		cdns,num-lanes = <1>;
> +		#phy-cells = <0>;
> +		cdns,phy-type = <PHY_TYPE_SGMII>;
> +		resets = <&serdes_wiz2 3>;
> +	};

[Severity: Low]
Does this node name phy@1 violate the standard device tree schema when the
reg property is set to 2? This mismatch will trigger a unit_address_vs_reg
dtc compiler warning.

> +	serdes2_usxgmii_link: phy@0 {
> +		reg = <3>;
> +		cdns,num-lanes = <1>;
> +		#phy-cells = <0>;
> +		cdns,phy-type = <PHY_TYPE_USXGMII>;
> +		resets = <&serdes_wiz2 4>;
> +	};

[Severity: Low]
Similarly here, shouldn't the unit-address in phy@0 match the reg property
of 3?

> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
> new file mode 100644
> index 0000000000000..ef4ebb5515469
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
[ ... ]
> +&serdes_wiz2 {
> +	assigned-clocks = <&k3_clks 406 6>,  <&k3_clks 406 5>;
> +	status = "okay";
> +};

[Severity: Medium]
Like in board1, will this assigned-clocks override fail to assign the second
clock because it doesn't also update assigned-clock-parents to be a
2-element array?

[ ... ]
> +	serdes2_sgmii2_link: phy@1 {
> +		reg = <3>;
> +		cdns,num-lanes = <1>;
> +		#phy-cells = <0>;
> +		cdns,phy-type = <PHY_TYPE_SGMII>;
> +		resets = <&serdes_wiz2 4>;
> +	};

[Severity: Low]
Does this unit-address phy@1 need to be updated to phy@3 to match the reg
property?

> +	serdes2_usxgmii_link: phy@0 {
> +		reg = <2>;
> +		cdns,num-lanes = <1>;
> +		#phy-cells = <0>;
> +		cdns,phy-type = <PHY_TYPE_USXGMII>;
> +		resets = <&serdes_wiz2 3>;
> +	};

[Severity: Low]
Does this unit-address phy@0 need to be updated to phy@2 to match the reg
property?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629102308.56616-1-g-praveen@ti.com?part=3

Re: [PATCH v2 3/3] arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII mode

[Gokul Praveen]

Hi,

On 29/06/26 16:04, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Medium] Array length mismatch between `assigned-clocks` and `assigned-clock-parents` in `&serdes_wiz2`.
> - [Low] Mismatch between node unit-address and 'reg' property in SerDes PHY links.
> - [Low] Dangling continuation backslash on the last item of a Makefile list immediately preceding a comment.
> --
>
> commit bc5648306dcc07a1bc8095cecaf3da3724e52d5d
> Author: Gokul Praveen <g-praveen@ti.com>
>
> arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII mode
>
> The CPSW9G instance of the CPSW Ethernet Switch supports SGMII and
> USXGMII mode with MAC Ports 1 and 2 of the instance, which are
> connected to ENET Expansion 1 and ENET Expansion 2 slots on
> the EVM respectively, through the Serdes2 instance of the SERDES.
> Enable CPSW9G MAC Ports 1 and 2 in fixed-link configuration
> SGMII and USXGMII mode at 1Gbps and 5 Gbps each.
>
>> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
>> index 5269c9619b65c..72c91f8f7814d 100644
>> --- a/arch/arm64/boot/dts/ti/Makefile
>> +++ b/arch/arm64/boot/dts/ti/Makefile
> [ ... ]
>> @@ -337,7 +343,8 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
>>   	k3-j784s4-evm-pcie0-pcie1-ep.dtb \
>>   	k3-j784s4-evm-quad-port-eth-exp1.dtb \
>>   	k3-j784s4-evm-usb0-type-a.dtb \
>> -	k3-j784s4-evm-usxgmii-exp1-exp2.dtb
>> -
>> +	k3-j784s4-evm-usxgmii-exp1-exp2.dtb \
>> +	k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtb \
>> +	k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtb \
>>   # Enable support for device-tree overlays
>>   DTC_FLAGS := -@
> [Severity: Low]
> Does this trailing backslash escape the newline before the comment? Since
> Make processes continuations before comments, this merges the comment onto
> the dtb- line. If the comment is ever removed, DTC_FLAGS := -@ would be
> mistakenly pulled into the dtb- variable.
>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
>> new file mode 100644
>> index 0000000000000..4ceb99c5c8088
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
> [ ... ]
>> +&serdes_wiz2 {
>> +	assigned-clocks = <&k3_clks 406 6>,  <&k3_clks 406 5>;
>> +	status = "okay";
>> +};
> [Severity: Medium]
> Will this 2-element assigned-clocks array work correctly without overriding
> the assigned-clock-parents array as well? Since assigned-clock-parents has
> only 1 element in the base device tree, the clock framework evaluates
> num_parents based on that length and ignores the second clock here, leaving
> it unparented.
>
> [ ... ]

The clk 5 does not have a parent and only clk 6 does.

Hence, only one assigned-clock-parents is needed.

Also both clk 5 and clk 6 works considere which has been working

and tested.

>> +&serdes2 {
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +	status = "okay";
>> +
>> +	assigned-clock-parents = <&k3_clks 406 5>,
>> +						 <&k3_clks 406 6>,
>> +						 <&k3_clks 406 5>;
>> +
>> +	serdes2_sgmii2_link: phy@1 {
>> +		reg = <2>;
>> +		cdns,num-lanes = <1>;
>> +		#phy-cells = <0>;
>> +		cdns,phy-type = <PHY_TYPE_SGMII>;
>> +		resets = <&serdes_wiz2 3>;
>> +	};
> [Severity: Low]
> Does this node name phy@1 violate the standard device tree schema when the
> reg property is set to 2? This mismatch will trigger a unit_address_vs_reg
> dtc compiler warning.

No , I dont think that matters at all, as the the cpsw driver does not 
relate the

reg property with the unit address.

>> +	serdes2_usxgmii_link: phy@0 {
>> +		reg = <3>;
>> +		cdns,num-lanes = <1>;
>> +		#phy-cells = <0>;
>> +		cdns,phy-type = <PHY_TYPE_USXGMII>;
>> +		resets = <&serdes_wiz2 4>;
>> +	};
> [Severity: Low]
> Similarly here, shouldn't the unit-address in phy@0 match the reg property
> of 3?

No , I dont think that matters at all, as the the cpsw driver does not 
relate the

reg property with the unit address.

>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
>> new file mode 100644
>> index 0000000000000..ef4ebb5515469
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
> [ ... ]
>> +&serdes_wiz2 {
>> +	assigned-clocks = <&k3_clks 406 6>,  <&k3_clks 406 5>;
>> +	status = "okay";
>> +};
> [Severity: Medium]
> Like in board1, will this assigned-clocks override fail to assign the second
> clock because it doesn't also update assigned-clock-parents to be a
> 2-element array?
>
> [ ... ]

The clk 5 does not have a parent and only clk 6 does.

Hence, only one assigned-clock-parents is needed.

Also both clk 5 and clk 6 works considere which has been working

and tested.

>> +	serdes2_sgmii2_link: phy@1 {
>> +		reg = <3>;
>> +		cdns,num-lanes = <1>;
>> +		#phy-cells = <0>;
>> +		cdns,phy-type = <PHY_TYPE_SGMII>;
>> +		resets = <&serdes_wiz2 4>;
>> +	};
> [Severity: Low]
> Does this unit-address phy@1 need to be updated to phy@3 to match the reg
> property?

No , I dont think that matters at all, as the the cpsw driver does not 
relate the

reg property with the unit address.

>> +	serdes2_usxgmii_link: phy@0 {
>> +		reg = <2>;
>> +		cdns,num-lanes = <1>;
>> +		#phy-cells = <0>;
>> +		cdns,phy-type = <PHY_TYPE_USXGMII>;
>> +		resets = <&serdes_wiz2 3>;
>> +	};
> [Severity: Low]
> Does this unit-address phy@0 need to be updated to phy@2 to match the reg
> property?
>
No , I dont think that matters at all, as the the cpsw driver does not 
relate the

reg property with the unit address.

Regards

Gokul Praveen

Re: [PATCH v2 0/3] Add support for dual port USXGMII+SGMII

[Siddharth Vadapalli]

On 29/06/26 15:53, Gokul Praveen wrote:
> This patch series enables dual port USXGMII and SGMII Ethernet mode
> support on the TI J784S4 EVM platform using the CPSW9G Ethernet switch.

Patch 1 => For Bindings
Patch 2 => For Driver
Patch 3 => For Device-tree overlay

Please split patch 1 and patch 2 into a different patch series and post 
patch 3 only after patches 1 and 2 are merged. Also, the patch series 
containing patches 1 and 2 should have the 'net-next' suffix in the patch 
subject:
	[PATCH net-next ...]

Additionally, the subject for Patch 1 looks incorrect as it doesn't follow 
the format expected for Bindings patches.

> 
> The CPSW9G instance supports both SGMII and USXGMII modes simultaneously
> on MAC Ports 1 and 2, which connect to ENET Expansion 1 and ENET
> Expansion 2 slots through the SERDES2 instance. The series includes:
> 
> 1. A fix to the SERDES2 node to add the missing PLL1 refclk, which is
>     required for multilink SERDES configuration to function properly.

Is it a 'fix' or a 'feature'? Please don't use them interchangeably. If it 
is a 'fix', which commit is it fixing? Specifically, which commit 'claimed' 
to enable the configuration that you seem to be fixing?

> 
> 2. A driver fix for the am65-cpsw Ethernet driver to properly configure
>     the MAC in SGMII mode according to the CPSGMII Module specification,
>     including correct advertisement ability register settings and master
>     mode configuration.

Although you have called it a 'fix' again, the CPSW is a MAC and not an 
Ethernet PHY. Therefore, the existing configuration is intended to 
advertise CPSW as an SGMII capable MAC (SGMII Slave Mode Configuration).

For more details, please refer:
https://lore.kernel.org/all/20220914095053.189851-6-s-vadapalli@ti.com/

[TRIMMED]

Regards,
Siddharth.

Re: [PATCH v2 0/3] Add support for dual port USXGMII+SGMII

[Gokul Praveen]

Hi Siddharth,

Thank your for the prompt feedback.

On 29/06/26 16:16, Siddharth Vadapalli wrote:
> On 29/06/26 15:53, Gokul Praveen wrote:
>> This patch series enables dual port USXGMII and SGMII Ethernet mode
>> support on the TI J784S4 EVM platform using the CPSW9G Ethernet switch.
>
> Patch 1 => For Bindings
> Patch 2 => For Driver
> Patch 3 => For Device-tree overlay
>
> Please split patch 1 and patch 2 into a different patch series and 
> post patch 3 only after patches 1 and 2 are merged. Also, the patch 
> series containing patches 1 and 2 should have the 'net-next' suffix in 
> the patch subject:
>     [PATCH net-next ...]

Sure, I will add the 'net-next' suffix ,siddharth.

>
> Additionally, the subject for Patch 1 looks incorrect as it doesn't 
> follow the format expected for Bindings patches.
>
Sure, I will follow the format.
>>
>> The CPSW9G instance supports both SGMII and USXGMII modes simultaneously
>> on MAC Ports 1 and 2, which connect to ENET Expansion 1 and ENET
>> Expansion 2 slots through the SERDES2 instance. The series includes:
>>
>> 1. A fix to the SERDES2 node to add the missing PLL1 refclk, which is
>>     required for multilink SERDES configuration to function properly.
>
> Is it a 'fix' or a 'feature'? Please don't use them interchangeably. 
> If it is a 'fix', which commit is it fixing? Specifically, which 
> commit 'claimed' to enable the configuration that you seem to be fixing?
Yes, it is a feature, siddharth. I will change the commit description.
>
>>
>> 2. A driver fix for the am65-cpsw Ethernet driver to properly configure
>>     the MAC in SGMII mode according to the CPSGMII Module specification,
>>     including correct advertisement ability register settings and master
>>     mode configuration.
>
> Although you have called it a 'fix' again, the CPSW is a MAC and not 
> an Ethernet PHY. Therefore, the existing configuration is intended to 
> advertise CPSW as an SGMII capable MAC (SGMII Slave Mode Configuration).
>
> For more details, please refer:
> https://lore.kernel.org/all/20220914095053.189851-6-s-vadapalli@ti.com/
>
> [TRIMMED]


Actually, this patch which you have mentioned 
"https://lore.kernel.org/all/20220914095053.189851-6-s-vadapalli@ti.com/" 
is no longer present in the latest kernel driver , siddharth.

Regards

Gokul Praveen

>
> Regards,
> Siddharth.

Re: [PATCH v2 0/3] Add support for dual port USXGMII+SGMII

[Siddharth Vadapalli]

On 29/06/26 4:40 PM, Gokul Praveen wrote:
> Hi Siddharth,
> 
> Thank your for the prompt feedback.
> 
> On 29/06/26 16:16, Siddharth Vadapalli wrote:
>> On 29/06/26 15:53, Gokul Praveen wrote:
>>> This patch series enables dual port USXGMII and SGMII Ethernet mode
>>> support on the TI J784S4 EVM platform using the CPSW9G Ethernet switch.
>>
>> Patch 1 => For Bindings
>> Patch 2 => For Driver
>> Patch 3 => For Device-tree overlay
>>
>> Please split patch 1 and patch 2 into a different patch series and 
>> post patch 3 only after patches 1 and 2 are merged. Also, the patch 
>> series containing patches 1 and 2 should have the 'net-next' suffix in 
>> the patch subject:
>>     [PATCH net-next ...]
> 
> Sure, I will add the 'net-next' suffix ,siddharth.
> 
>>
>> Additionally, the subject for Patch 1 looks incorrect as it doesn't 
>> follow the format expected for Bindings patches.
>>
> Sure, I will follow the format.
>>>
>>> The CPSW9G instance supports both SGMII and USXGMII modes simultaneously
>>> on MAC Ports 1 and 2, which connect to ENET Expansion 1 and ENET
>>> Expansion 2 slots through the SERDES2 instance. The series includes:
>>>
>>> 1. A fix to the SERDES2 node to add the missing PLL1 refclk, which is
>>>     required for multilink SERDES configuration to function properly.
>>
>> Is it a 'fix' or a 'feature'? Please don't use them interchangeably. 
>> If it is a 'fix', which commit is it fixing? Specifically, which 
>> commit 'claimed' to enable the configuration that you seem to be fixing?
> Yes, it is a feature, siddharth. I will change the commit description.
>>
>>>
>>> 2. A driver fix for the am65-cpsw Ethernet driver to properly configure
>>>     the MAC in SGMII mode according to the CPSGMII Module specification,
>>>     including correct advertisement ability register settings and master
>>>     mode configuration.
>>
>> Although you have called it a 'fix' again, the CPSW is a MAC and not 
>> an Ethernet PHY. Therefore, the existing configuration is intended to 
>> advertise CPSW as an SGMII capable MAC (SGMII Slave Mode Configuration).
>>
>> For more details, please refer:
>> https://lore.kernel.org/all/20220914095053.189851-6-s-vadapalli@ti.com/
>>
>> [TRIMMED]
> 
> 
> Actually, this patch which you have mentioned "https://lore.kernel.org/ 
> all/20220914095053.189851-6-s-vadapalli@ti.com/" is no longer present in 
> the latest kernel driver , siddharth.
That was exactly my point. Please go through the conversation on my 
patch to understand why the patch isn't correct.

Regards,
Siddharth.