[PATCH v4 0/6] Enable ethernet on qcs615

[PATCH v4 0/6] Enable ethernet on qcs615

[Yijie Yang]

Adds device tree nodes and EMAC driver data to enable Ethernet
functionality on the QCS615-RIDE platform, supporting all three
standard speeds.

Switches the semantic interpretation of 'rgmii' and 'rgmii-id' in the
driver code to match upstream Linux kernel definitions. Updates the
device tree files for affected boards—QCS404-EVB-400 and SA8155-ADP—
accordingly to ensure consistent behavior across platforms.

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
Integrates the thread:
https://lore.kernel.org/all/20241225-support_10m100m-v1-0-4b52ef48b488@quicinc.com/

Changes in v4:
- Change the phy-mode of QCS404-EVB-4000 and SA8155-ADP to rgmii-id.
- Remove the DT binding change related to the phy-mode definition.
- Update base commit.
- Drop ABI compatibility and update the driver code accordingly.
- Link to v3: https://lore.kernel.org/all/20250121-dts_qcs615-v3-0-fa4496950d8a@quicinc.com/

---
Yijie Yang (6):
      net: stmmac: Add support for 10 Mbps and 100 Mbps Ethernet speeds
      net: stmmac: Inverse the phy-mode definition
      arm64: dts: qcom: qcs615: add ethernet node
      arm64: dts: qcom: qcs615-ride: Enable ethernet node
      arm64: dts: qcom: qcs404: Inverse phy-mode for EVB-4000
      arm64: dts: qcom: sa8155p-adp: Inverse phy-mode

 arch/arm64/boot/dts/qcom/qcs404-evb-4000.dts       |   2 +-
 arch/arm64/boot/dts/qcom/qcs615-ride.dts           | 104 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sa8155p-adp.dts           |   2 +-
 arch/arm64/boot/dts/qcom/sm6150.dtsi               |  33 +++++++
 .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    |  28 +++++-
 5 files changed, 162 insertions(+), 7 deletions(-)
---
base-commit: eb91b04da2c3ac17e4e67079e455fba4bfd1b4f0
change-id: 20250813-qcs615_eth-9e294256f913

Best regards,
--  
Yijie Yang <yijie.yang@oss.qualcomm.com>

[PATCH v4 1/6] net: stmmac: Add support for 10 Mbps and 100 Mbps Ethernet speeds

[Yijie Yang]

The DLL is a Qualcomm-specific hardware component integrated within the
MAC and should be configured in bypass mode for 10 Mbps and 100 Mbps
speeds. If not bypassed, the timing delay will be incorrectly applied,
which will disrupt signal sampling.

Fixes: a7c30e62d4b8 ("net: stmmac: Add driver for Qualcomm ethqos")
Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index d8fd4d8f6ced..a4ea72f86ca8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -64,6 +64,9 @@
 #define SDCC_DLL_CONFIG2_DDR_TRAFFIC_INIT_SW	BIT(1)
 #define SDCC_DLL_CONFIG2_DDR_CAL_EN		BIT(0)
 
+/* SDCC_USR_CTL fields */
+#define SDCC_USR_CTL_DLL_BYPASS			BIT(30)
+
 /* SDC4_STATUS bits */
 #define SDC4_STATUS_DLL_LOCK			BIT(7)
 
@@ -609,6 +612,17 @@ static int ethqos_configure_rgmii(struct qcom_ethqos *ethqos, int speed)
 	if (speed == SPEED_1000)
 		ethqos_dll_configure(ethqos);
 
+	/* The DLL (Delay Locked Loop) aligns the clock and samples data
+	 * in RGMII interfaces. It should be bypassed for 10 Mbps and
+	 * 100 Mbps speeds.
+	 */
+	if (speed == SPEED_10 || speed == SPEED_100) {
+		rgmii_updatel(ethqos, SDCC_DLL_CONFIG_PDN, SDCC_DLL_CONFIG_PDN,
+			      SDCC_HC_REG_DLL_CONFIG);
+		rgmii_updatel(ethqos, SDCC_USR_CTL_DLL_BYPASS,
+			      SDCC_USR_CTL_DLL_BYPASS, SDCC_USR_CTL);
+	}
+
 	ethqos_rgmii_macro_init(ethqos, speed);
 
 	return 0;

-- 
2.34.1

[PATCH v4 2/6] net: stmmac: Inverse the phy-mode definition

[Yijie Yang]

In the initial device tree submission, the definitions of rgmii and
rgmii-id in the phy-mode property were inverted compared to the
conventions used by the upstream Linux kernel community.

Only QCS-EVB-400 and SA8155-ADP platforms are affected due to the
incorrect PHY mode configuration: 'rgmii' was used instead of the
correct 'rgmii-id'. This change results in an ABI compatibility break,
but it is acceptable as these platforms are not actively used by any
customers, based on current observations.

Qualcomm expects the MAC, not the PHY, to introduce the timing delay,
and the driver is designed accordingly. This is due to specific SoC
hardware that handles delay and sampling internally.

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index a4ea72f86ca8..a3e595e3b1e4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -390,14 +390,11 @@ static int ethqos_dll_configure(struct qcom_ethqos *ethqos)
 static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
 {
 	struct device *dev = &ethqos->pdev->dev;
-	int phase_shift;
+	int phase_shift = 0;
 	int loopback;
 
 	/* Determine if the PHY adds a 2 ns TX delay or the MAC handles it */
-	if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID ||
-	    ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_TXID)
-		phase_shift = 0;
-	else
+	if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID)
 		phase_shift = RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN;
 
 	/* Disable loopback mode */
@@ -803,7 +800,14 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
 	if (!ethqos)
 		return -ENOMEM;
 
+	/* Qualcomm configures the MAC to introduce delay; instruct the
+	 * PHY not to add additional delay.
+	 */
+	if (plat_dat->phy_interface == PHY_INTERFACE_MODE_RGMII_ID)
+		plat_dat->phy_interface = PHY_INTERFACE_MODE_RGMII;
+
 	ethqos->phy_mode = plat_dat->phy_interface;
+
 	switch (ethqos->phy_mode) {
 	case PHY_INTERFACE_MODE_RGMII:
 	case PHY_INTERFACE_MODE_RGMII_ID:

-- 
2.34.1

Re: [PATCH v4 2/6] net: stmmac: Inverse the phy-mode definition

[Andrew Lunn]

>  static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
>  {
>  	struct device *dev = &ethqos->pdev->dev;
> -	int phase_shift;
> +	int phase_shift = 0;
>  	int loopback;
>  
>  	/* Determine if the PHY adds a 2 ns TX delay or the MAC handles it */
> -	if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID ||
> -	    ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_TXID)
> -		phase_shift = 0;
> -	else
> +	if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID)
>  		phase_shift = RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN;

Does this one setting control both RX and TX delays? The hardware
cannot support 2ns delay on TX, but 0ns on RX? Or 2ns on RX but 0ns on
TX?

	Andrew

Re: [PATCH v4 2/6] net: stmmac: Inverse the phy-mode definition

[Yijie Yang]

On 2025-08-20 00:20, Andrew Lunn wrote:
>>   static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
>>   {
>>   	struct device *dev = &ethqos->pdev->dev;
>> -	int phase_shift;
>> +	int phase_shift = 0;
>>   	int loopback;
>>   
>>   	/* Determine if the PHY adds a 2 ns TX delay or the MAC handles it */
>> -	if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID ||
>> -	    ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_TXID)
>> -		phase_shift = 0;
>> -	else
>> +	if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID)
>>   		phase_shift = RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN;
> 
> Does this one setting control both RX and TX delays? The hardware
> cannot support 2ns delay on TX, but 0ns on RX? Or 2ns on RX but 0ns on
> TX?
> 

This setting is only for Tx delay. Rx delays are taken care separately 
with DLL delays.

> 	Andrew

-- 
Best Regards,
Yijie

Re: [PATCH v4 2/6] net: stmmac: Inverse the phy-mode definition

[Andrew Lunn]

On Thu, Aug 21, 2025 at 10:22:05AM +0800, Yijie Yang wrote:
> 
> 
> On 2025-08-20 00:20, Andrew Lunn wrote:
> > >   static int ethqos_rgmii_macro_init(struct qcom_ethqos *ethqos, int speed)
> > >   {
> > >   	struct device *dev = &ethqos->pdev->dev;
> > > -	int phase_shift;
> > > +	int phase_shift = 0;
> > >   	int loopback;
> > >   	/* Determine if the PHY adds a 2 ns TX delay or the MAC handles it */
> > > -	if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID ||
> > > -	    ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_TXID)
> > > -		phase_shift = 0;
> > > -	else
> > > +	if (ethqos->phy_mode == PHY_INTERFACE_MODE_RGMII_ID)
> > >   		phase_shift = RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN;
> > 
> > Does this one setting control both RX and TX delays? The hardware
> > cannot support 2ns delay on TX, but 0ns on RX? Or 2ns on RX but 0ns on
> > TX?
> > 
> 
> This setting is only for Tx delay. Rx delays are taken care separately with
> DLL delays.

If this is only for Tx delays, why is it also not used for
PHY_INTERFACE_MODE_RGMII_TXID?

It is simpler to just let the PHY add the delays, the PHY drivers get
this right, are well tested, and just work. MAC drivers often get
delays wrong.

	Andrew

[PATCH v4 3/6] arm64: dts: qcom: qcs615: add ethernet node

[YijieYang]

From: Yijie Yang <quic_yijiyang@quicinc.com>

Add an ethernet controller node for QCS615 SoC to enable ethernet
functionality.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com>
---
 arch/arm64/boot/dts/qcom/sm6150.dtsi | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6150.dtsi b/arch/arm64/boot/dts/qcom/sm6150.dtsi
index 591fcb740259..8ec97532911c 100644
--- a/arch/arm64/boot/dts/qcom/sm6150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6150.dtsi
@@ -491,6 +491,39 @@ soc: soc@0 {
 		dma-ranges = <0 0 0 0 0x10 0>;
 		#address-cells = <2>;
 		#size-cells = <2>;
+		ethernet: ethernet@20000 {
+			compatible = "qcom,qcs615-ethqos", "qcom,qcs404-ethqos";
+			reg = <0x0 0x00020000 0x0 0x10000>,
+			      <0x0 0x00036000 0x0 0x100>;
+			reg-names = "stmmaceth",
+				    "rgmii";
+
+			clocks = <&gcc GCC_EMAC_AXI_CLK>,
+				 <&gcc GCC_EMAC_SLV_AHB_CLK>,
+				 <&gcc GCC_EMAC_PTP_CLK>,
+				 <&gcc GCC_EMAC_RGMII_CLK>;
+			clock-names = "stmmaceth",
+				      "pclk",
+				      "ptp_ref",
+				      "rgmii";
+
+			interrupts = <GIC_SPI 660 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 661 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "macirq",
+					  "eth_lpi";
+
+			power-domains = <&gcc EMAC_GDSC>;
+			resets = <&gcc GCC_EMAC_BCR>;
+
+			iommus = <&apps_smmu 0x1c0 0x0>;
+
+			snps,tso;
+			snps,pbl = <32>;
+			rx-fifo-depth = <16384>;
+			tx-fifo-depth = <20480>;
+
+			status = "disabled";
+		};
 
 		gcc: clock-controller@100000 {
 			compatible = "qcom,qcs615-gcc";

-- 
2.34.1

Re: [PATCH v4 3/6] arm64: dts: qcom: qcs615: add ethernet node

[Krzysztof Kozlowski]

On 19/08/2025 08:35, YijieYang wrote:
> From: Yijie Yang <quic_yijiyang@quicinc.com>
> 
> Add an ethernet controller node for QCS615 SoC to enable ethernet
> functionality.
> 
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com>
> ---


Why do you mix up DTS and net-next patches? This only makes difficult to
apply it, for no benefits.

Best regards,
Krzysztof

Re: [PATCH v4 3/6] arm64: dts: qcom: qcs615: add ethernet node

[Yijie Yang]

On 2025-08-19 14:44, Krzysztof Kozlowski wrote:
> On 19/08/2025 08:35, YijieYang wrote:
>> From: Yijie Yang <quic_yijiyang@quicinc.com>
>>
>> Add an ethernet controller node for QCS615 SoC to enable ethernet
>> functionality.
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com>
>> ---
> 
> 
> Why do you mix up DTS and net-next patches? This only makes difficult to
> apply it, for no benefits.

The DTS changes and driver code modifications work together to achieve a 
single purpose, so I included them in one patch series. Should I 
consider splitting them into two separate series?

> 
> Best regards,
> Krzysztof

-- 
Best Regards,
Yijie

Re: [PATCH v4 3/6] arm64: dts: qcom: qcs615: add ethernet node

[Krzysztof Kozlowski]

On 19/08/2025 08:51, Yijie Yang wrote:
> 
> 
> On 2025-08-19 14:44, Krzysztof Kozlowski wrote:
>> On 19/08/2025 08:35, YijieYang wrote:
>>> From: Yijie Yang <quic_yijiyang@quicinc.com>
>>>
>>> Add an ethernet controller node for QCS615 SoC to enable ethernet
>>> functionality.
>>>
>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>> Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com>
>>> ---
>>
>>
>> Why do you mix up DTS and net-next patches? This only makes difficult to
>> apply it, for no benefits.
> 
> The DTS changes and driver code modifications work together to achieve a 
> single purpose, so I included them in one patch series. Should I 
> consider splitting them into two separate series?
Of course yes. You are just making difficult to apply this. Patches are
completely independent and even your internal guideline asks to NOT
combine independent patches.

Best regards,
Krzysztof

Re: [PATCH v4 3/6] arm64: dts: qcom: qcs615: add ethernet node

[Yijie Yang]

On 2025-08-19 15:15, Krzysztof Kozlowski wrote:
> On 19/08/2025 08:51, Yijie Yang wrote:
>>
>>
>> On 2025-08-19 14:44, Krzysztof Kozlowski wrote:
>>> On 19/08/2025 08:35, YijieYang wrote:
>>>> From: Yijie Yang <quic_yijiyang@quicinc.com>
>>>>
>>>> Add an ethernet controller node for QCS615 SoC to enable ethernet
>>>> functionality.
>>>>
>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>> Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com>
>>>> ---
>>>
>>>
>>> Why do you mix up DTS and net-next patches? This only makes difficult to
>>> apply it, for no benefits.
>>
>> The DTS changes and driver code modifications work together to achieve a
>> single purpose, so I included them in one patch series. Should I
>> consider splitting them into two separate series?
> Of course yes. You are just making difficult to apply this. Patches are
> completely independent and even your internal guideline asks to NOT
> combine independent patches.

The challenge with splitting this series lies in the fact that it 
attempts to reverse the incorrect semantics of phy-mode in both the 
driver code and the device tree. Selecting only part of the series would 
break Ethernet functionality on both boards.

As you can see, I’ve CC’d noautosel to prevent this issue. Given the 
circumstances, I’m wondering if it would be acceptable to leave the 
series as-is?

> 
> Best regards,
> Krzysztof

-- 
Best Regards,
Yijie

Re: [PATCH v4 3/6] arm64: dts: qcom: qcs615: add ethernet node

[Krzysztof Kozlowski]

On 19/08/2025 11:04, Yijie Yang wrote:
> 
> 
> On 2025-08-19 15:15, Krzysztof Kozlowski wrote:
>> On 19/08/2025 08:51, Yijie Yang wrote:
>>>
>>>
>>> On 2025-08-19 14:44, Krzysztof Kozlowski wrote:
>>>> On 19/08/2025 08:35, YijieYang wrote:
>>>>> From: Yijie Yang <quic_yijiyang@quicinc.com>
>>>>>
>>>>> Add an ethernet controller node for QCS615 SoC to enable ethernet
>>>>> functionality.
>>>>>
>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>> Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com>
>>>>> ---
>>>>
>>>>
>>>> Why do you mix up DTS and net-next patches? This only makes difficult to
>>>> apply it, for no benefits.
>>>
>>> The DTS changes and driver code modifications work together to achieve a
>>> single purpose, so I included them in one patch series. Should I
>>> consider splitting them into two separate series?
>> Of course yes. You are just making difficult to apply this. Patches are
>> completely independent and even your internal guideline asks to NOT
>> combine independent patches.
> 
> The challenge with splitting this series lies in the fact that it 
> attempts to reverse the incorrect semantics of phy-mode in both the 
> driver code and the device tree. Selecting only part of the series would 
> break Ethernet functionality on both boards.

And where did you explain that? Anyway, you did not achieve your goal,
because you broke the boards still.

Your patchset is not bisectable and does not follow standard submission
guidelines. DTS is always independent, please read carefully the docs.

> 
> As you can see, I’ve CC’d noautosel to prevent this issue. Given the 
> circumstances, I’m wondering if it would be acceptable to leave the 
> series as-is?

NAK. Sneaking DTS into net-next is not acceptable.


Best regards,
Krzysztof

Re: [PATCH v4 3/6] arm64: dts: qcom: qcs615: add ethernet node

[Yijie Yang]

On 2025-08-19 17:08, Krzysztof Kozlowski wrote:
> On 19/08/2025 11:04, Yijie Yang wrote:
>>
>>
>> On 2025-08-19 15:15, Krzysztof Kozlowski wrote:
>>> On 19/08/2025 08:51, Yijie Yang wrote:
>>>>
>>>>
>>>> On 2025-08-19 14:44, Krzysztof Kozlowski wrote:
>>>>> On 19/08/2025 08:35, YijieYang wrote:
>>>>>> From: Yijie Yang <quic_yijiyang@quicinc.com>
>>>>>>
>>>>>> Add an ethernet controller node for QCS615 SoC to enable ethernet
>>>>>> functionality.
>>>>>>
>>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>> Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com>
>>>>>> ---
>>>>>
>>>>>
>>>>> Why do you mix up DTS and net-next patches? This only makes difficult to
>>>>> apply it, for no benefits.
>>>>
>>>> The DTS changes and driver code modifications work together to achieve a
>>>> single purpose, so I included them in one patch series. Should I
>>>> consider splitting them into two separate series?
>>> Of course yes. You are just making difficult to apply this. Patches are
>>> completely independent and even your internal guideline asks to NOT
>>> combine independent patches.
>>
>> The challenge with splitting this series lies in the fact that it
>> attempts to reverse the incorrect semantics of phy-mode in both the
>> driver code and the device tree. Selecting only part of the series would
>> break Ethernet functionality on both boards.
> 
> And where did you explain that? Anyway, you did not achieve your goal,
> because you broke the boards still.
> 
> Your patchset is not bisectable and does not follow standard submission
> guidelines. DTS is always independent, please read carefully the docs.

The approach I'm taking will inevitably make the series non-bisectable, 
but I'll clearly note this in the cover letter in the next revision.

> 
>>
>> As you can see, I’ve CC’d noautosel to prevent this issue. Given the
>> circumstances, I’m wondering if it would be acceptable to leave the
>> series as-is?
> 
> NAK. Sneaking DTS into net-next is not acceptable.

Okay, I’ll split this series in the next revision.

> 
> 
> Best regards,
> Krzysztof

-- 
Best Regards,
Yijie

Re: [PATCH v4 3/6] arm64: dts: qcom: qcs615: add ethernet node

[Krzysztof Kozlowski]

On 20/08/2025 10:57, Yijie Yang wrote:
> 
> 
> On 2025-08-19 17:08, Krzysztof Kozlowski wrote:
>> On 19/08/2025 11:04, Yijie Yang wrote:
>>>
>>>
>>> On 2025-08-19 15:15, Krzysztof Kozlowski wrote:
>>>> On 19/08/2025 08:51, Yijie Yang wrote:
>>>>>
>>>>>
>>>>> On 2025-08-19 14:44, Krzysztof Kozlowski wrote:
>>>>>> On 19/08/2025 08:35, YijieYang wrote:
>>>>>>> From: Yijie Yang <quic_yijiyang@quicinc.com>
>>>>>>>
>>>>>>> Add an ethernet controller node for QCS615 SoC to enable ethernet
>>>>>>> functionality.
>>>>>>>
>>>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>>>>> Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com>
>>>>>>> ---
>>>>>>
>>>>>>
>>>>>> Why do you mix up DTS and net-next patches? This only makes difficult to
>>>>>> apply it, for no benefits.
>>>>>
>>>>> The DTS changes and driver code modifications work together to achieve a
>>>>> single purpose, so I included them in one patch series. Should I
>>>>> consider splitting them into two separate series?
>>>> Of course yes. You are just making difficult to apply this. Patches are
>>>> completely independent and even your internal guideline asks to NOT
>>>> combine independent patches.
>>>
>>> The challenge with splitting this series lies in the fact that it
>>> attempts to reverse the incorrect semantics of phy-mode in both the
>>> driver code and the device tree. Selecting only part of the series would
>>> break Ethernet functionality on both boards.
>>
>> And where did you explain that? Anyway, you did not achieve your goal,
>> because you broke the boards still.
>>
>> Your patchset is not bisectable and does not follow standard submission
>> guidelines. DTS is always independent, please read carefully the docs.
> 
> The approach I'm taking will inevitably make the series non-bisectable, 

The series are non-bisectable now!

Do you understand the concept of commit and how patch is applied? How
splitting this patchset per two changes ANYTHING in bisectability?

And you keep arguing on this...

Best regards,
Krzysztof

[PATCH v4 4/6] arm64: dts: qcom: qcs615-ride: Enable ethernet node

[YijieYang]

From: Yijie Yang <quic_yijiyang@quicinc.com>

Enable the ethernet node, add the phy node and pinctrl for ethernet.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com>
---
 arch/arm64/boot/dts/qcom/qcs615-ride.dts | 104 +++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs615-ride.dts b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
index 59582d3dc4c4..05d8609c0483 100644
--- a/arch/arm64/boot/dts/qcom/qcs615-ride.dts
+++ b/arch/arm64/boot/dts/qcom/qcs615-ride.dts
@@ -288,6 +288,59 @@ vreg_l17a: ldo17 {
 	};
 };
 
+&ethernet {
+	pinctrl-0 = <&ethernet_defaults>;
+	pinctrl-names = "default";
+
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-id";
+
+	snps,mtl-rx-config = <&mtl_rx_setup>;
+	snps,mtl-tx-config = <&mtl_tx_setup>;
+
+	status = "okay";
+
+	mdio: mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		rgmii_phy: phy@7 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0x7>;
+
+			interrupts-extended = <&tlmm 121 IRQ_TYPE_EDGE_FALLING>;
+			device_type = "ethernet-phy";
+			reset-gpios = <&tlmm 104 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <11000>;
+			reset-deassert-us = <70000>;
+		};
+	};
+
+	mtl_rx_setup: rx-queues-config {
+		snps,rx-queues-to-use = <1>;
+		snps,rx-sched-sp;
+
+		queue0 {
+			snps,dcb-algorithm;
+			snps,map-to-dma-channel = <0x0>;
+			snps,route-up;
+			snps,priority = <0x1>;
+		};
+	};
+
+	mtl_tx_setup: tx-queues-config {
+		snps,tx-queues-to-use = <1>;
+		snps,tx-sched-wrr;
+
+		queue0 {
+			snps,weight = <0x10>;
+			snps,dcb-algorithm;
+			snps,priority = <0x0>;
+		};
+	};
+};
+
 &gcc {
 	clocks = <&rpmhcc RPMH_CXO_CLK>,
 		 <&rpmhcc RPMH_CXO_CLK_A>,
@@ -446,6 +499,57 @@ &sdhc_2 {
 	status = "okay";
 };
 
+&tlmm {
+	ethernet_defaults: ethernet-defaults-state {
+		mdc-pins {
+			pins = "gpio113";
+			function = "rgmii";
+			bias-pull-up;
+		};
+
+		mdio-pins {
+			pins = "gpio114";
+			function = "rgmii";
+			bias-pull-up;
+		};
+
+		rgmii-rx-pins {
+			pins = "gpio81", "gpio82", "gpio83", "gpio102", "gpio103", "gpio112";
+			function = "rgmii";
+			bias-disable;
+			drive-strength = <2>;
+		};
+
+		rgmii-tx-pins {
+			pins = "gpio92", "gpio93", "gpio94", "gpio95", "gpio96", "gpio97";
+			function = "rgmii";
+			bias-pull-up;
+			drive-strength = <16>;
+		};
+
+		phy-intr-pins {
+			pins = "gpio121";
+			function = "gpio";
+			bias-disable;
+			drive-strength = <8>;
+		};
+
+		pps-pins {
+			pins = "gpio91";
+			function = "rgmii";
+			bias-disable;
+			drive-strength = <8>;
+		};
+
+		phy-reset-pins {
+			pins = "gpio104";
+			function = "gpio";
+			bias-pull-up;
+			drive-strength = <16>;
+		};
+	};
+};
+
 &uart0 {
 	status = "okay";
 };

-- 
2.34.1

Re: [PATCH v4 4/6] arm64: dts: qcom: qcs615-ride: Enable ethernet node

[Andrew Lunn]

> +	mdio: mdio {
> +		compatible = "snps,dwmac-mdio";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		rgmii_phy: phy@7 {
> +			compatible = "ethernet-phy-ieee802.3-c22";
> +			reg = <0x7>;
> +
> +			interrupts-extended = <&tlmm 121 IRQ_TYPE_EDGE_FALLING>;

PHY interrupt are always level, never edge.

    Andrew

---
pw-bot: cr

Re: [PATCH v4 4/6] arm64: dts: qcom: qcs615-ride: Enable ethernet node

[Yijie Yang]

On 2025-08-20 00:24, Andrew Lunn wrote:
>> +	mdio: mdio {
>> +		compatible = "snps,dwmac-mdio";
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		rgmii_phy: phy@7 {
>> +			compatible = "ethernet-phy-ieee802.3-c22";
>> +			reg = <0x7>;
>> +
>> +			interrupts-extended = <&tlmm 121 IRQ_TYPE_EDGE_FALLING>;
> 
> PHY interrupt are always level, never edge.

Thanks for pointing that out — I’ll get it fixed.

> 
>      Andrew
> 
> ---
> pw-bot: cr
> 

-- 
Best Regards,
Yijie

[PATCH v4 5/6] arm64: dts: qcom: qcs404: Inverse phy-mode for EVB-4000

[Yijie Yang]

This board expects the MAC to add the delay. Set `phy-mode = "rgmii-id"`
in DTS to match upstream definition and work correctly with the updated
driver, which switches the semantic handling of 'rgmii' and 'rgmii-id'.

Breaking ABI compatibility is acceptable for this board, as it has no
known users or interest from any users.

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/qcs404-evb-4000.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb-4000.dts b/arch/arm64/boot/dts/qcom/qcs404-evb-4000.dts
index 358827c2fbd3..a3e67e83f69f 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb-4000.dts
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb-4000.dts
@@ -25,7 +25,7 @@ &ethernet {
 	pinctrl-0 = <&ethernet_defaults>;
 
 	phy-handle = <&phy1>;
-	phy-mode = "rgmii";
+	phy-mode = "rgmii-id";
 	mdio {
 		#address-cells = <1>;
 		#size-cells = <0>;

-- 
2.34.1

[PATCH v4 6/6] arm64: dts: qcom: sa8155p-adp: Inverse phy-mode

[Yijie Yang]

This board expects the MAC to add the delay. Set `phy-mode = "rgmii-id"`
in DTS to match upstream definition and work correctly with the updated
driver, which switches the semantic handling of 'rgmii' and 'rgmii-id'.

Breaking ABI compatibility is acceptable for this board, as it has no
known users or interest from any users.

Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sa8155p-adp.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sa8155p-adp.dts b/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
index 388d5ecee949..4ac1a5b09e30 100644
--- a/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
+++ b/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
@@ -325,7 +325,7 @@ &ethernet {
 	pinctrl-0 = <&ethernet_defaults>;
 
 	phy-handle = <&rgmii_phy>;
-	phy-mode = "rgmii";
+	phy-mode = "rgmii-id";
 
 	mdio {
 		compatible = "snps,dwmac-mdio";

-- 
2.34.1