[PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[Mohd Ayaan Anwar]

Hi,

This preliminary series adds the DTS changes required to enable
Ethernet on the Qualcomm Shikra CQM, CQS, and IQS EVKs.

It adds the two Shikra EMAC controller nodes, enables the first
Ethernet port on the CQM and CQS EVKs, enables both ports on the IQS
EVK, describes the DP83867 PHYs and their GPIO-controlled 2.5 V
supplies, and fixes an incorrect GPIO reservation on the IQS SoM.

This series is functionally dependent on the driver and binding changes
posted here:

https://lore.kernel.org/netdev/20260908-shikra_ethernet-v2-0-bbe3389d0652@oss.qualcomm.com/

I am hoping that a preliminary DTS series makes the review of the
driver, dt-bindings, and board-description changes easier.

Changes since RFC:
  - Model the PHY supplies as fixed regulators controlled by the PHY
    driver -- Konrad, Andrew.
  - Add the IQS GPIO reservation fix as the first patch -- Krzysztof.
  - Move the Ethernet pinctrl default states to shikra.dtsi -- Konrad.
  - Resolve property-ordering issues and add missing final newlines --
    Konrad.
  - Link to RFC: https://lore.kernel.org/netdev/20260612-shikra_ethernet-v1-0-f0f4a1d19929@oss.qualcomm.com/

Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
Mohd Ayaan Anwar (5):
      arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation
      arm64: dts: qcom: shikra: add ethernet nodes
      arm64: dts: qcom: shikra-cqm-evk: enable the first Ethernet port
      arm64: dts: qcom: shikra-cqs-evk: enable the first Ethernet port
      arm64: dts: qcom: shikra-iqs-evk: enable both Ethernet ports

 arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts  |  46 +++++
 arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts  |  46 +++++
 arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts  |  90 +++++++++
 arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi |   2 +-
 arch/arm64/boot/dts/qcom/shikra.dtsi         | 266 +++++++++++++++++++++++++++
 5 files changed, 449 insertions(+), 1 deletion(-)
---
base-commit: 7042c8c193e5d634198b7c766bb3a01c8e3ee0e2
change-id: 20260908-shikra_ethernet_dts-0077e847d990
prerequisite-change-id: 20260903-shikra_ethernet-ae7bee5e804e:v2
prerequisite-patch-id: 218773849d643c66166408f849566323f3d466c2
prerequisite-patch-id: 8973e6e7fa7b09e09705913a37035c1bff8ad385
prerequisite-patch-id: 6686a8aef5f4f729892d0b3ce2e75816fe874f82
prerequisite-patch-id: 2ba77f9b01c8bf2f22589361e005805c28353f6e
prerequisite-patch-id: bf25cc81677cccb0740f26a4fb3ed8fdd2e240d8
prerequisite-patch-id: 5333cc3ebc07361084298168344d230b234e8795
prerequisite-patch-id: c1ef6e429b44f3227554e8c50cc2dc9baaa54cb7
prerequisite-patch-id: 0b2817da8c502234bf2867f9985f488389c519fa
prerequisite-patch-id: f5716827eca798a78fea6a40b3097e52c14c1e81

Best regards,
-- 
Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>

[PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Mohd Ayaan Anwar]

The GPIO mappings on the IQS variant differ from the CQ variants.
GPIO138 is connected to the RGMII1_RX_CTL pin rather than the NFC ESE
Secure IO pin; the latter is connected to GPIO49. This incorrect
reservation causes the probe of the second Ethernet port to fail:

  shikra-tlmm 500000.pinctrl: error -EINVAL: pin-138 (5d20000.ethernet)
  shikra-tlmm 500000.pinctrl: error -EINVAL: could not request pin 138
  (GPIO_138) from group gpio138 on device 500000.pinctrl
  qcom-ethqos 5d20000.ethernet: Error applying setting, reverse things back

Replace gpio138 with gpio49 in the reserved list.

Fixes: 779aead2dace ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
index e119ace54e588dca38c7c12fc99cc41d6623f690..c3f5fb84a07c425aef5ae36fc6e2842d87f4cae9 100644
--- a/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
@@ -220,7 +220,7 @@ pm8150_l18: l18 {
 &tlmm {
 	 gpio-reserved-ranges = <6 4>, /* Fingerprint SPI */
 			       <30 2>, /* NFC SPI */
-			       <138 1>, /* NFC Secure IO */
+			       <49 1>, /* NFC Secure IO */
 			       <155 11>; /* eMMC Boot */
 
 	sw_ctrl_default: sw-ctrl-default-state {

-- 
2.34.1

Re: [PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Andrew Lunn]

On Tue, Sep 08, 2026 at 11:53:30AM +0530, Mohd Ayaan Anwar wrote:
> The GPIO mappings on the IQS variant differ from the CQ variants.
> GPIO138 is connected to the RGMII1_RX_CTL pin rather than the NFC ESE
> Secure IO pin; the latter is connected to GPIO49. This incorrect
> reservation causes the probe of the second Ethernet port to fail:
> 
>   shikra-tlmm 500000.pinctrl: error -EINVAL: pin-138 (5d20000.ethernet)
>   shikra-tlmm 500000.pinctrl: error -EINVAL: could not request pin 138
>   (GPIO_138) from group gpio138 on device 500000.pinctrl
>   qcom-ethqos 5d20000.ethernet: Error applying setting, reverse things back
> 
> Replace gpio138 with gpio49 in the reserved list.
> 
> Fixes: 779aead2dace ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>

If this is a fix, should it be posted for a different tree, so it
makes it way to stable?

You don't normally mix fixes and on going development work.

    Andrew

Re: [PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Mohd Ayaan Anwar]

On Tue, Sep 08, 2026 at 02:11:22PM +0200, Andrew Lunn wrote:
> On Tue, Sep 08, 2026 at 11:53:30AM +0530, Mohd Ayaan Anwar wrote:
> > The GPIO mappings on the IQS variant differ from the CQ variants.
> > GPIO138 is connected to the RGMII1_RX_CTL pin rather than the NFC ESE
> > Secure IO pin; the latter is connected to GPIO49. This incorrect
> > reservation causes the probe of the second Ethernet port to fail:
> > 
> >   shikra-tlmm 500000.pinctrl: error -EINVAL: pin-138 (5d20000.ethernet)
> >   shikra-tlmm 500000.pinctrl: error -EINVAL: could not request pin 138
> >   (GPIO_138) from group gpio138 on device 500000.pinctrl
> >   qcom-ethqos 5d20000.ethernet: Error applying setting, reverse things back
> > 
> > Replace gpio138 with gpio49 in the reserved list.
> > 
> > Fixes: 779aead2dace ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
> > Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> 
> If this is a fix, should it be posted for a different tree, so it
> makes it way to stable?
> 
> You don't normally mix fixes and on going development work.
> 

You're right that it reads like a standalone fix, and that's on me for
the commit message. There's no functional impact on current users: the
reserved GPIO (138) is unused today, so applying this on a released
kernel produces no error and there's nothing to backport to stable.

I'll reword the commit message so it reads as a prerequisite for
enabling Ethernet rather than implying a current break.

	Ayaan

Re: [PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Andrew Lunn]

> You're right that it reads like a standalone fix, and that's on me for
> the commit message. There's no functional impact on current users: the
> reserved GPIO (138) is unused today, so applying this on a released
> kernel produces no error and there's nothing to backport to stable.
> 
> I'll reword the commit message so it reads as a prerequisite for
> enabling Ethernet rather than implying a current break.

And drop the Fixes: tag. It is that which draws the eye and makes the
Reviewer ask the question.

    Andrew

Re: [PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Konrad Dybcio]

On 9/8/26 3:57 PM, Andrew Lunn wrote:
>> You're right that it reads like a standalone fix, and that's on me for
>> the commit message. There's no functional impact on current users: the
>> reserved GPIO (138) is unused today, so applying this on a released
>> kernel produces no error and there's nothing to backport to stable.
>>
>> I'll reword the commit message so it reads as a prerequisite for
>> enabling Ethernet rather than implying a current break.
> 
> And drop the Fixes: tag. It is that which draws the eye and makes the
> Reviewer ask the question.

I noticed this subthread only after leaving my tag, it's still fine
to keep

Konrad

Re: [PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Konrad Dybcio]

On 9/8/26 8:23 AM, Mohd Ayaan Anwar wrote:
> The GPIO mappings on the IQS variant differ from the CQ variants.
> GPIO138 is connected to the RGMII1_RX_CTL pin rather than the NFC ESE
> Secure IO pin; the latter is connected to GPIO49. This incorrect
> reservation causes the probe of the second Ethernet port to fail:
> 
>   shikra-tlmm 500000.pinctrl: error -EINVAL: pin-138 (5d20000.ethernet)
>   shikra-tlmm 500000.pinctrl: error -EINVAL: could not request pin 138
>   (GPIO_138) from group gpio138 on device 500000.pinctrl
>   qcom-ethqos 5d20000.ethernet: Error applying setting, reverse things back
> 
> Replace gpio138 with gpio49 in the reserved list.
> 
> Fixes: 779aead2dace ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Krzysztof Kozlowski]

On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
> The GPIO mappings on the IQS variant differ from the CQ variants.
> GPIO138 is connected to the RGMII1_RX_CTL pin rather than the NFC ESE
> Secure IO pin; the latter is connected to GPIO49. This incorrect
> reservation causes the probe of the second Ethernet port to fail:
> 
>   shikra-tlmm 500000.pinctrl: error -EINVAL: pin-138 (5d20000.ethernet)
>   shikra-tlmm 500000.pinctrl: error -EINVAL: could not request pin 138
>   (GPIO_138) from group gpio138 on device 500000.pinctrl
>   qcom-ethqos 5d20000.ethernet: Error applying setting, reverse things back
> 
> Replace gpio138 with gpio49 in the reserved list.
> 
> Fixes: 779aead2dace ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

This looks duplicating:
https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/

Best regards,
Krzysztof

Re: [PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Krzysztof Kozlowski]

On 09/09/2026 13:24, Krzysztof Kozlowski wrote:
> On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
>> The GPIO mappings on the IQS variant differ from the CQ variants.
>> GPIO138 is connected to the RGMII1_RX_CTL pin rather than the NFC ESE
>> Secure IO pin; the latter is connected to GPIO49. This incorrect
>> reservation causes the probe of the second Ethernet port to fail:
>>
>>   shikra-tlmm 500000.pinctrl: error -EINVAL: pin-138 (5d20000.ethernet)
>>   shikra-tlmm 500000.pinctrl: error -EINVAL: could not request pin 138
>>   (GPIO_138) from group gpio138 on device 500000.pinctrl
>>   qcom-ethqos 5d20000.ethernet: Error applying setting, reverse things back


Apply this patch and reproduce it. Is is possible? Didn't we talk about
this already?

>>
>> Replace gpio138 with gpio49 in the reserved list.
>>
>> Fixes: 779aead2dace ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
>> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
>> ---
>>  arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
> 
> This looks duplicating:
> https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
> 

Ah, no, mixed patches. Duplication is between other works:
https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
https://lore.kernel.org/all/20260826-shikra-dtpm-v4-1-8476223184de@oss.qualcomm.com/

But nevertheless I am sure we talked about this, that commit msg and is
not accurate... Cannot find the thread, though...

Best regards,
Krzysztof

Re: [PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Krzysztof Kozlowski]

On 09/09/2026 13:30, Krzysztof Kozlowski wrote:
> On 09/09/2026 13:24, Krzysztof Kozlowski wrote:
>> On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
>>> The GPIO mappings on the IQS variant differ from the CQ variants.
>>> GPIO138 is connected to the RGMII1_RX_CTL pin rather than the NFC ESE
>>> Secure IO pin; the latter is connected to GPIO49. This incorrect
>>> reservation causes the probe of the second Ethernet port to fail:
>>>
>>>   shikra-tlmm 500000.pinctrl: error -EINVAL: pin-138 (5d20000.ethernet)
>>>   shikra-tlmm 500000.pinctrl: error -EINVAL: could not request pin 138
>>>   (GPIO_138) from group gpio138 on device 500000.pinctrl
>>>   qcom-ethqos 5d20000.ethernet: Error applying setting, reverse things back
> 
> 
> Apply this patch and reproduce it. Is is possible? Didn't we talk about
> this already?
> 
>>>
>>> Replace gpio138 with gpio49 in the reserved list.
>>>
>>> Fixes: 779aead2dace ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
>>> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
>>> ---
>>>  arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>
>> This looks duplicating:
>> https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
>>
> 
> Ah, no, mixed patches. Duplication is between other works:
> https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
> https://lore.kernel.org/all/20260826-shikra-dtpm-v4-1-8476223184de@oss.qualcomm.com/
> 
> But nevertheless I am sure we talked about this, that commit msg and is
> not accurate... Cannot find the thread, though...

So here was v1:
https://lore.kernel.org/all/20260612-shikra_ethernet-v1-9-f0f4a1d19929@oss.qualcomm.com/
Where I commented that code needs changes and now we see again v1.

What is with this patch versioning? How is it supposed to work:

b4 diff '<20260908-shikra_ethernet_dts-v1-0-69c0c5c7c124@oss.qualcomm.com>'

???

Best regards,
Krzysztof

Re: [PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Mohd Ayaan Anwar]

On Wed, Sep 09, 2026 at 01:33:57PM +0200, Krzysztof Kozlowski wrote:
> On 09/09/2026 13:30, Krzysztof Kozlowski wrote:
> > On 09/09/2026 13:24, Krzysztof Kozlowski wrote:
> >> On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
> >>> The GPIO mappings on the IQS variant differ from the CQ variants.
> >>> GPIO138 is connected to the RGMII1_RX_CTL pin rather than the NFC ESE
> >>> Secure IO pin; the latter is connected to GPIO49. This incorrect
> >>> reservation causes the probe of the second Ethernet port to fail:
> >>>
> >>>   shikra-tlmm 500000.pinctrl: error -EINVAL: pin-138 (5d20000.ethernet)
> >>>   shikra-tlmm 500000.pinctrl: error -EINVAL: could not request pin 138
> >>>   (GPIO_138) from group gpio138 on device 500000.pinctrl
> >>>   qcom-ethqos 5d20000.ethernet: Error applying setting, reverse things back
> > 
> > 
> > Apply this patch and reproduce it. Is is possible? Didn't we talk about
> > this already?
> > 
> >>>
> >>> Replace gpio138 with gpio49 in the reserved list.
> >>>
> >>> Fixes: 779aead2dace ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
> >>> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> >>> ---
> >>>  arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>
> >> This looks duplicating:
> >> https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
> >>
> > 
> > Ah, no, mixed patches. Duplication is between other works:
> > https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
> > https://lore.kernel.org/all/20260826-shikra-dtpm-v4-1-8476223184de@oss.qualcomm.com/
> > 
> > But nevertheless I am sure we talked about this, that commit msg and is
> > not accurate... Cannot find the thread, though...
> 
> So here was v1:
> https://lore.kernel.org/all/20260612-shikra_ethernet-v1-9-f0f4a1d19929@oss.qualcomm.com/
> Where I commented that code needs changes and now we see again v1.
> 
> What is with this patch versioning? How is it supposed to work:
> 
> b4 diff '<20260908-shikra_ethernet_dts-v1-0-69c0c5c7c124@oss.qualcomm.com>'
> 
> ???
> 

During the RFC, I mentioned that I will split out the series after
initial feedback. So the RFC (after incorporating the feedback) was split
into:
1. This series (v1)
2. Changes for net-next (v1 and v2 have been sent out):
  https://lore.kernel.org/netdev/20260908-shikra_ethernet-v2-0-bbe3389d0652@oss.qualcomm.com/

This particular commit message needs to be rewritten as its not breaking
anything in the current tree. I will fix that and drop the Fixes: tag.

	Ayaan

Re: [PATCH PRELIMINARY 1/5] arm64: dts: qcom: shikra-iqs-som: fix GPIO138 reservation

[Mohd Ayaan Anwar]

On Wed, Sep 09, 2026 at 01:30:04PM +0200, Krzysztof Kozlowski wrote:
> On 09/09/2026 13:24, Krzysztof Kozlowski wrote:
> > On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
> >> The GPIO mappings on the IQS variant differ from the CQ variants.
> >> GPIO138 is connected to the RGMII1_RX_CTL pin rather than the NFC ESE
> >> Secure IO pin; the latter is connected to GPIO49. This incorrect
> >> reservation causes the probe of the second Ethernet port to fail:
> >>
> >>   shikra-tlmm 500000.pinctrl: error -EINVAL: pin-138 (5d20000.ethernet)
> >>   shikra-tlmm 500000.pinctrl: error -EINVAL: could not request pin 138
> >>   (GPIO_138) from group gpio138 on device 500000.pinctrl
> >>   qcom-ethqos 5d20000.ethernet: Error applying setting, reverse things back
> 
> 
> Apply this patch and reproduce it. Is is possible? Didn't we talk about
> this already?
> 
> >>
> >> Replace gpio138 with gpio49 in the reserved list.
> >>
> >> Fixes: 779aead2dace ("arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm")
> >> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> >> ---
> >>  arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> > 
> > This looks duplicating:
> > https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
> > 
> 
> Ah, no, mixed patches. Duplication is between other works:
> https://lore.kernel.org/all/20260820085347.822-1-xueyao.an@oss.qualcomm.com/
> https://lore.kernel.org/all/20260826-shikra-dtpm-v4-1-8476223184de@oss.qualcomm.com/
> 
> But nevertheless I am sure we talked about this, that commit msg and is
> not accurate... Cannot find the thread, though...
> 

Yes, I'll reword the commit message so it reads as a prerequisite for
enabling Ethernet rather than implying a current break. Also, the Fixes:
needs to be dropped as mentioned by Andrew.


	Ayaan

[PATCH PRELIMINARY 2/5] arm64: dts: qcom: shikra: add ethernet nodes

[Mohd Ayaan Anwar]

Add the two Gigabit Ethernet controllers present on Shikra (ethernet0
at 0x5d00000, ethernet1 at 0x5d20000).  Both nodes are left disabled;
board files supply the PHY details.

Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/shikra.dtsi | 266 +++++++++++++++++++++++++++++++++++
 1 file changed, 266 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index c1f06f692f66452c6ee1b10f3ef12c20e201b5ce..a55e20be83fe2d132eb91878e76b666b8694da55 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -631,6 +631,56 @@ tlmm: pinctrl@500000 {
 			gpio-ranges = <&tlmm 0 0 165>;
 			wakeup-parent = <&mpm>;
 
+			ethernet0_default: ethernet0-default-state {
+				rgmii-rx-pins {
+					pins = "gpio121", "gpio122", "gpio123",
+					       "gpio124", "gpio125", "gpio126";
+					function = "rgmii";
+					drive-strength = <16>;
+					bias-disable;
+				};
+
+				rgmii-tx-pins {
+					pins = "gpio127", "gpio128", "gpio129",
+					       "gpio130", "gpio131", "gpio132";
+					function = "rgmii";
+					drive-strength = <16>;
+					bias-pull-up;
+				};
+
+				rgmii-mdio-pins {
+					pins = "gpio133", "gpio134";
+					function = "rgmii";
+					drive-strength = <16>;
+					bias-pull-up;
+				};
+			};
+
+			ethernet1_default: ethernet1-default-state {
+				rgmii-rx-pins {
+					pins = "gpio137", "gpio138", "gpio139",
+					       "gpio140", "gpio141", "gpio142";
+					function = "rgmii";
+					drive-strength = <16>;
+					bias-disable;
+				};
+
+				rgmii-tx-pins {
+					pins = "gpio143", "gpio144", "gpio145",
+					       "gpio146", "gpio147", "gpio148";
+					function = "rgmii";
+					drive-strength = <16>;
+					bias-pull-up;
+				};
+
+				rgmii-mdio-pins {
+					pins = "gpio149", "gpio150";
+					function = "rgmii";
+					drive-strength = <16>;
+					bias-pull-up;
+				};
+			};
+
 			qup_i2c0_data_clk: qup-i2c0-data-clk-state {
 				/* SDA, SCL */
 				pins = "gpio2", "gpio3";
@@ -1977,6 +2027,222 @@ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
 			};
 		};
 
+		ethernet0: ethernet@5d00000 {
+			compatible = "qcom,shikra-ethqos";
+			reg = <0x0 0x05d00000 0x0 0x10000>,
+			      <0x0 0x05d16000 0x0 0x100>;
+			reg-names = "stmmaceth", "rgmii";
+
+			interrupts = <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH 0>;
+			interrupt-names = "macirq";
+
+			clocks = <&gcc GCC_EMAC0_AXI_CLK>,
+				 <&gcc GCC_EMAC0_AHB_CLK>,
+				 <&gcc GCC_EMAC0_PTP_CLK>,
+				 <&gcc GCC_EMAC0_RGMII_CLK>,
+				 <&gcc GCC_EMAC0_AXI_SYS_NOC_CLK>,
+				 <&gcc GCC_PCIE_TILE_AXI_SYS_NOC_CLK>;
+			clock-names = "stmmaceth", "pclk", "ptp_ref", "rgmii",
+				      "axi-noc", "pcie-tile-axi-noc";
+
+			power-domains = <&gcc GCC_EMAC0_GDSC>;
+			resets = <&gcc GCC_EMAC0_BCR>;
+			iommus = <&apps_smmu 0x0380 0x0007>;
+
+			interconnects = <&mem_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ALWAYS
+					 &config_noc SLAVE_EMAC0_CFG QCOM_ICC_TAG_ALWAYS>,
+					<&system_noc MASTER_EMAC_0 QCOM_ICC_TAG_ALWAYS
+					 &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>;
+			interconnect-names = "cpu-mac", "mac-mem";
+
+			operating-points-v2 = <&emac0_opp_table>;
+
+			snps,tso;
+			snps,pbl = <32>;
+			rx-fifo-depth = <16384>;
+			tx-fifo-depth = <16384>;
+
+			snps,mtl-rx-config = <&emac0_mtl_rx_setup>;
+			snps,mtl-tx-config = <&emac0_mtl_tx_setup>;
+
+			status = "disabled";
+
+			emac0_opp_table: opp-table {
+				compatible = "operating-points-v2";
+
+				opp-120000000 {
+					opp-hz = /bits/ 64 <120000000>;
+					required-opps = <&rpmpd_opp_svs>;
+				};
+			};
+
+			emac0_mtl_rx_setup: rx-queues-config {
+				snps,rx-queues-to-use = <4>;
+				snps,rx-sched-sp;
+
+				queue0 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x0>;
+					snps,route-up;
+					snps,priority = <0x1>;
+				};
+
+				queue1 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x1>;
+					snps,route-ptp;
+				};
+
+				queue2 {
+					snps,avb-algorithm;
+					snps,map-to-dma-channel = <0x2>;
+					snps,route-avcp;
+				};
+
+				queue3 {
+					snps,avb-algorithm;
+					snps,map-to-dma-channel = <0x3>;
+					snps,priority = <0xc>;
+				};
+			};
+
+			emac0_mtl_tx_setup: tx-queues-config {
+				snps,tx-queues-to-use = <4>;
+
+				queue0 {
+					snps,dcb-algorithm;
+				};
+
+				queue1 {
+					snps,dcb-algorithm;
+				};
+
+				queue2 {
+					snps,avb-algorithm;
+					snps,send_slope = <0x1000>;
+					snps,idle_slope = <0x1000>;
+					snps,high_credit = <0x3e800>;
+					snps,low_credit = <0xffc18000>;
+				};
+
+				queue3 {
+					snps,avb-algorithm;
+					snps,send_slope = <0x1000>;
+					snps,idle_slope = <0x1000>;
+					snps,high_credit = <0x3e800>;
+					snps,low_credit = <0xffc18000>;
+				};
+			};
+		};
+
+		ethernet1: ethernet@5d20000 {
+			compatible = "qcom,shikra-ethqos";
+			reg = <0x0 0x05d20000 0x0 0x10000>,
+			      <0x0 0x05d36000 0x0 0x100>;
+			reg-names = "stmmaceth", "rgmii";
+
+			interrupts = <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH 0>;
+			interrupt-names = "macirq";
+
+			clocks = <&gcc GCC_EMAC1_AXI_CLK>,
+				 <&gcc GCC_EMAC1_AHB_CLK>,
+				 <&gcc GCC_EMAC1_PTP_CLK>,
+				 <&gcc GCC_EMAC1_RGMII_CLK>,
+				 <&gcc GCC_EMAC1_AXI_SYS_NOC_CLK>,
+				 <&gcc GCC_PCIE_TILE_AXI_SYS_NOC_CLK>;
+			clock-names = "stmmaceth", "pclk", "ptp_ref", "rgmii",
+				      "axi-noc", "pcie-tile-axi-noc";
+
+			power-domains = <&gcc GCC_EMAC1_GDSC>;
+			resets = <&gcc GCC_EMAC1_BCR>;
+			iommus = <&apps_smmu 0x03a0 0x0007>;
+
+			interconnects = <&mem_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ALWAYS
+					 &config_noc SLAVE_EMAC1_CFG QCOM_ICC_TAG_ALWAYS>,
+					<&system_noc MASTER_EMAC_1 QCOM_ICC_TAG_ALWAYS
+					 &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>;
+			interconnect-names = "cpu-mac", "mac-mem";
+
+			operating-points-v2 = <&emac1_opp_table>;
+
+			snps,tso;
+			snps,pbl = <32>;
+			rx-fifo-depth = <16384>;
+			tx-fifo-depth = <16384>;
+
+			snps,mtl-rx-config = <&emac1_mtl_rx_setup>;
+			snps,mtl-tx-config = <&emac1_mtl_tx_setup>;
+
+			status = "disabled";
+
+			emac1_opp_table: opp-table {
+				compatible = "operating-points-v2";
+
+				opp-120000000 {
+					opp-hz = /bits/ 64 <120000000>;
+					required-opps = <&rpmpd_opp_svs>;
+				};
+			};
+
+			emac1_mtl_rx_setup: rx-queues-config {
+				snps,rx-queues-to-use = <4>;
+				snps,rx-sched-sp;
+
+				queue0 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x0>;
+					snps,route-up;
+					snps,priority = <0x1>;
+				};
+
+				queue1 {
+					snps,dcb-algorithm;
+					snps,map-to-dma-channel = <0x1>;
+					snps,route-ptp;
+				};
+
+				queue2 {
+					snps,avb-algorithm;
+					snps,map-to-dma-channel = <0x2>;
+					snps,route-avcp;
+				};
+
+				queue3 {
+					snps,avb-algorithm;
+					snps,map-to-dma-channel = <0x3>;
+					snps,priority = <0xc>;
+				};
+			};
+
+			emac1_mtl_tx_setup: tx-queues-config {
+				snps,tx-queues-to-use = <4>;
+
+				queue0 {
+					snps,dcb-algorithm;
+				};
+
+				queue1 {
+					snps,dcb-algorithm;
+				};
+
+				queue2 {
+					snps,avb-algorithm;
+					snps,send_slope = <0x1000>;
+					snps,idle_slope = <0x1000>;
+					snps,high_credit = <0x3e800>;
+					snps,low_credit = <0xffc18000>;
+				};
+
+				queue3 {
+					snps,avb-algorithm;
+					snps,send_slope = <0x1000>;
+					snps,idle_slope = <0x1000>;
+					snps,high_credit = <0x3e800>;
+					snps,low_credit = <0xffc18000>;
+				};
+			};
+		};
+
 		remoteproc_mpss: remoteproc@6080000 {
 			compatible = "qcom,shikra-mpss-pas";
 			reg = <0x0 0x06080000 0x0 0x100>;

-- 
2.34.1

[PATCH PRELIMINARY 3/5] arm64: dts: qcom: shikra-cqm-evk: enable the first Ethernet port

[Mohd Ayaan Anwar]

Enable ethernet0 for the Shikra CQM EVK board with its DP83867 RGMII
PHY. The PHY is powered on using a GPIO-controlled 2.5V regulator.

Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 46 +++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
index b112b21b1d79b73563d17ae68d7c51460ddb1b22..d093b80034823fbc41fb59366d22fc84fbe8bcb0 100644
--- a/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
+++ b/arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
@@ -21,6 +21,42 @@ aliases {
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
+
+	rgmii_phy_supply: regulator-rgmii-phy {
+		compatible = "regulator-fixed";
+		regulator-name = "rgmii-phy-pwr";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <2500000>;
+		gpio = <&tlmm 149 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		pinctrl-0 = <&rgmii_phy_pwr_default>;
+		pinctrl-names = "default";
+	};
+};
+
+&ethernet0 {
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-id";
+
+	pinctrl-0 = <&ethernet0_default>;
+	pinctrl-names = "default";
+
+	status = "okay";
+
+	mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		rgmii_phy: ethernet-phy@7 {
+			compatible = "ethernet-phy-id2000.a231";
+			reg = <0x7>;
+			reset-gpios = <&tlmm 135 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <50000>;
+			vdda-2p5-supply = <&rgmii_phy_supply>;
+		};
+	};
 };
 
 &remoteproc_cdsp {
@@ -57,3 +93,13 @@ &sdhc_1 {
 
 	status = "okay";
 };
+
+&tlmm {
+	rgmii_phy_pwr_default: rgmii-phy-pwr-default-state {
+		pins = "gpio149";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+		output-low;
+	};
+};

-- 
2.34.1

[PATCH PRELIMINARY 4/5] arm64: dts: qcom: shikra-cqs-evk: enable the first Ethernet port

[Mohd Ayaan Anwar]

Enable ethernet0 for the Shikra CQS EVK board with its DP83867 RGMII
PHY. The PHY is powered on using a GPIO-controlled 2.5V regulator.

Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 46 +++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
index e62ba5aef71ff5b15e55810ae3d80a81e15e44e8..7b30c67c68e8c7161bfdd25168fe882b394b5558 100644
--- a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
+++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
@@ -21,6 +21,42 @@ aliases {
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
+
+	rgmii_phy_supply: regulator-rgmii-phy {
+		compatible = "regulator-fixed";
+		regulator-name = "rgmii-phy-pwr";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <2500000>;
+		gpio = <&tlmm 149 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		pinctrl-0 = <&rgmii_phy_pwr_default>;
+		pinctrl-names = "default";
+	};
+};
+
+&ethernet0 {
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-id";
+
+	pinctrl-0 = <&ethernet0_default>;
+	pinctrl-names = "default";
+
+	status = "okay";
+
+	mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		rgmii_phy: ethernet-phy@7 {
+			compatible = "ethernet-phy-id2000.a231";
+			reg = <0x7>;
+			reset-gpios = <&tlmm 135 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <50000>;
+			vdda-2p5-supply = <&rgmii_phy_supply>;
+		};
+	};
 };
 
 &remoteproc_cdsp {
@@ -57,3 +93,13 @@ &sdhc_1 {
 
 	status = "okay";
 };
+
+&tlmm {
+	rgmii_phy_pwr_default: rgmii-phy-pwr-default-state {
+		pins = "gpio149";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+		output-low;
+	};
+};

-- 
2.34.1

[PATCH PRELIMINARY 5/5] arm64: dts: qcom: shikra-iqs-evk: enable both Ethernet ports

[Mohd Ayaan Anwar]

Enable ethernet0 and ethernet1 on the IQS EVK with their respective
TI DP83867 RGMII PHYs. Both PHYs are powered by GPIO-controlled 2.5V
regulators.

Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 90 +++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
index 727809430fd15fc45046daa2d1fbca110394c60d..049feb5b4d965177a67b7dbfb2d368ccfbdab7b9 100644
--- a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
+++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
@@ -21,6 +21,78 @@ aliases {
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
+
+	rgmii_phy0_supply: regulator-rgmii-phy0 {
+		compatible = "regulator-fixed";
+		regulator-name = "rgmii-phy0-pwr";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <2500000>;
+		gpio = <&tlmm 66 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		pinctrl-0 = <&rgmii_phy0_pwr_default>;
+		pinctrl-names = "default";
+	};
+
+	rgmii_phy1_supply: regulator-rgmii-phy1 {
+		compatible = "regulator-fixed";
+		regulator-name = "rgmii-phy1-pwr";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <2500000>;
+		gpio = <&tlmm 53 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		pinctrl-0 = <&rgmii_phy1_pwr_default>;
+		pinctrl-names = "default";
+	};
+};
+
+&ethernet0 {
+	phy-handle = <&rgmii_phy0>;
+	phy-mode = "rgmii-id";
+
+	pinctrl-0 = <&ethernet0_default>;
+	pinctrl-names = "default";
+
+	status = "okay";
+
+	mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		rgmii_phy0: ethernet-phy@7 {
+			compatible = "ethernet-phy-id2000.a231";
+			reg = <0x7>;
+			reset-gpios = <&tlmm 135 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <50000>;
+			vdda-2p5-supply = <&rgmii_phy0_supply>;
+		};
+	};
+};
+
+&ethernet1 {
+	phy-handle = <&rgmii_phy1>;
+	phy-mode = "rgmii-id";
+
+	pinctrl-0 = <&ethernet1_default>;
+	pinctrl-names = "default";
+
+	status = "okay";
+
+	mdio {
+		compatible = "snps,dwmac-mdio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		rgmii_phy1: ethernet-phy@7 {
+			compatible = "ethernet-phy-id2000.a231";
+			reg = <0x7>;
+			reset-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
+			reset-assert-us = <10000>;
+			reset-deassert-us = <50000>;
+			vdda-2p5-supply = <&rgmii_phy1_supply>;
+		};
+	};
 };
 
 &remoteproc_cdsp {
@@ -57,3 +129,21 @@ &sdhc_1 {
 
 	status = "okay";
 };
+
+&tlmm {
+	rgmii_phy0_pwr_default: rgmii-phy0-pwr-default-state {
+		pins = "gpio66";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+		output-low;
+	};
+
+	rgmii_phy1_pwr_default: rgmii-phy1-pwr-default-state {
+		pins = "gpio53";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+		output-low;
+	};
+};

-- 
2.34.1

Re: [PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[Krzysztof Kozlowski]

On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
> Hi,
> 
> This preliminary series adds the DTS changes required to enable
> Ethernet on the Qualcomm Shikra CQM, CQS, and IQS EVKs.

What is "PRELIMINARY" patch in upstream? Where is this process
documented or expressed?

Don't send us code which is not ready, we have other patches to review
which are not preliminary.

Best regards,
Krzysztof

Re: [PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[Mohd Ayaan Anwar]

On Tue, Sep 08, 2026 at 08:56:39AM +0200, Krzysztof Kozlowski wrote:
> On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
> > Hi,
> > 
> > This preliminary series adds the DTS changes required to enable
> > Ethernet on the Qualcomm Shikra CQM, CQS, and IQS EVKs.
> 
> What is "PRELIMINARY" patch in upstream? Where is this process
> documented or expressed?
> 

My apologies. The code is ready, and I was hoping that sharing the DTS
changes would make reviewing the driver and dt-bindings a bit easier.
The original RFC had them together, and I split it out for net-next
and linux-next.

The only reason I added a PRELIMINARY tag was because these DTS changes
should go in after the driver changes and dt-bindings.

	Ayaan

Re: [PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[Krzysztof Kozlowski]

On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
> On Tue, Sep 08, 2026 at 08:56:39AM +0200, Krzysztof Kozlowski wrote:
>> On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
>>> Hi,
>>>
>>> This preliminary series adds the DTS changes required to enable
>>> Ethernet on the Qualcomm Shikra CQM, CQS, and IQS EVKs.
>>
>> What is "PRELIMINARY" patch in upstream? Where is this process
>> documented or expressed?
>>
> 
> My apologies. The code is ready, and I was hoping that sharing the DTS
> changes would make reviewing the driver and dt-bindings a bit easier.
> The original RFC had them together, and I split it out for net-next
> and linux-next.

Yeah, but why calling it completely different than every other patchset?
Why coming with different style? Why this cannot be RFC?

> 
> The only reason I added a PRELIMINARY tag was because these DTS changes
> should go in after the driver changes and dt-bindings.
> 

DTS cannot go after the driver changes. If that is your requirement,
then original work is broken and needs to be fixed.

Best regards,
Krzysztof

Re: [PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[Mohd Ayaan Anwar]

On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
> On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
> > On Tue, Sep 08, 2026 at 08:56:39AM +0200, Krzysztof Kozlowski wrote:
> >> On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
> >>> Hi,
> >>>
> >>> This preliminary series adds the DTS changes required to enable
> >>> Ethernet on the Qualcomm Shikra CQM, CQS, and IQS EVKs.
> >>
> >> What is "PRELIMINARY" patch in upstream? Where is this process
> >> documented or expressed?
> >>
> > 
> > My apologies. The code is ready, and I was hoping that sharing the DTS
> > changes would make reviewing the driver and dt-bindings a bit easier.
> > The original RFC had them together, and I split it out for net-next
> > and linux-next.
> 
> Yeah, but why calling it completely different than every other patchset?
> Why coming with different style? Why this cannot be RFC?

Agreed. In hindsight, this should probably have been an RFC v2. I saw
some recent series using a PRELIMINARY tag, but I see that its
ultimately just an RFC.

> 
> > 
> > The only reason I added a PRELIMINARY tag was because these DTS changes
> > should go in after the driver changes and dt-bindings.
> > 
> 
> DTS cannot go after the driver changes. If that is your requirement,
> then original work is broken and needs to be fixed.
> 

I should have worded it better. I am only worried about the dt-bindings
going in before this DTS. The driver changes just add support for
whatever we are desribing in this series, they can go in after
dt-bindings and DTS without any issues.

	Ayaan

Re: [PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[Mohd Ayaan Anwar]

On Tue, Sep 08, 2026 at 12:53:46PM +0530, Mohd Ayaan Anwar wrote:
> On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
> > On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
> > > The only reason I added a PRELIMINARY tag was because these DTS changes
> > > should go in after the driver changes and dt-bindings.
> > > 
> > 
> > DTS cannot go after the driver changes. If that is your requirement,
> > then original work is broken and needs to be fixed.
> > 
> 
> I should have worded it better. I am only worried about the dt-bindings
> going in before this DTS. The driver changes just add support for
> whatever we are desribing in this series, they can go in after
> dt-bindings and DTS without any issues.
> 

...would it be preferable to instead have the split like this?

  - This series + dt-bindings (on top of linux-next)
  - Only driver changes from [1] (for net-next)

	Ayaan

[1] https://lore.kernel.org/netdev/20260908-shikra_ethernet-v2-0-bbe3389d0652@oss.qualcomm.com/

Re: [PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[Krzysztof Kozlowski]

On 08/09/2026 09:39, Mohd Ayaan Anwar wrote:
> On Tue, Sep 08, 2026 at 12:53:46PM +0530, Mohd Ayaan Anwar wrote:
>> On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
>>> On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
>>>> The only reason I added a PRELIMINARY tag was because these DTS changes
>>>> should go in after the driver changes and dt-bindings.
>>>>
>>>
>>> DTS cannot go after the driver changes. If that is your requirement,
>>> then original work is broken and needs to be fixed.
>>>
>>
>> I should have worded it better. I am only worried about the dt-bindings
>> going in before this DTS. The driver changes just add support for
>> whatever we are desribing in this series, they can go in after
>> dt-bindings and DTS without any issues.
>>
> 
> ...would it be preferable to instead have the split like this?
> 
>   - This series + dt-bindings (on top of linux-next)
>   - Only driver changes from [1] (for net-next)

No, because it would be against explicit documented rules in the kernel
and against clear guidelines and recent discussions within Qualcomm. I
wonder why did we have these long discussions about Shikra if only a few
people were listening and the rest will be repeating the same broken
process as before?

Best regards,
Krzysztof

Re: [PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[Mohd Ayaan Anwar]

On Tue, Sep 08, 2026 at 10:42:40AM +0200, Krzysztof Kozlowski wrote:
> On 08/09/2026 09:39, Mohd Ayaan Anwar wrote:
> > On Tue, Sep 08, 2026 at 12:53:46PM +0530, Mohd Ayaan Anwar wrote:
> >> On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
> >>> On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
> >>>> The only reason I added a PRELIMINARY tag was because these DTS changes
> >>>> should go in after the driver changes and dt-bindings.
> >>>>
> >>>
> >>> DTS cannot go after the driver changes. If that is your requirement,
> >>> then original work is broken and needs to be fixed.
> >>>
> >>
> >> I should have worded it better. I am only worried about the dt-bindings
> >> going in before this DTS. The driver changes just add support for
> >> whatever we are desribing in this series, they can go in after
> >> dt-bindings and DTS without any issues.
> >>
> > 
> > ...would it be preferable to instead have the split like this?
> > 
> >   - This series + dt-bindings (on top of linux-next)
> >   - Only driver changes from [1] (for net-next)
> 
> No, because it would be against explicit documented rules in the kernel
> and against clear guidelines and recent discussions within Qualcomm. I
> wonder why did we have these long discussions about Shikra if only a few
> people were listening and the rest will be repeating the same broken
> process as before?
> 

Understood, thanks. I'll keep the current split (bindings + driver to
net-next, DTS separate for the SoC tree).

	Ayaan

Re: [PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[Krzysztof Kozlowski]

On 08/09/2026 09:23, Mohd Ayaan Anwar wrote:
> On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
>> On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
>>> On Tue, Sep 08, 2026 at 08:56:39AM +0200, Krzysztof Kozlowski wrote:
>>>> On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
>>>>> Hi,
>>>>>
>>>>> This preliminary series adds the DTS changes required to enable
>>>>> Ethernet on the Qualcomm Shikra CQM, CQS, and IQS EVKs.
>>>>
>>>> What is "PRELIMINARY" patch in upstream? Where is this process
>>>> documented or expressed?
>>>>
>>>
>>> My apologies. The code is ready, and I was hoping that sharing the DTS
>>> changes would make reviewing the driver and dt-bindings a bit easier.
>>> The original RFC had them together, and I split it out for net-next
>>> and linux-next.
>>
>> Yeah, but why calling it completely different than every other patchset?
>> Why coming with different style? Why this cannot be RFC?
> 
> Agreed. In hindsight, this should probably have been an RFC v2. I saw
> some recent series using a PRELIMINARY tag, but I see that its

Where?
https://lore.kernel.org/all/?q=s%3APRELIMINARY


Best regards,
Krzysztof

Re: [PATCH PRELIMINARY 0/5] arm64: dts: qcom: shikra: add Ethernet support

[Mohd Ayaan Anwar]

On Tue, Sep 08, 2026 at 10:40:45AM +0200, Krzysztof Kozlowski wrote:
> On 08/09/2026 09:23, Mohd Ayaan Anwar wrote:
> > On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
> >> On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
> >>> On Tue, Sep 08, 2026 at 08:56:39AM +0200, Krzysztof Kozlowski wrote:
> >>>> On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
> >>>>> Hi,
> >>>>>
> >>>>> This preliminary series adds the DTS changes required to enable
> >>>>> Ethernet on the Qualcomm Shikra CQM, CQS, and IQS EVKs.
> >>>>
> >>>> What is "PRELIMINARY" patch in upstream? Where is this process
> >>>> documented or expressed?
> >>>>
> >>>
> >>> My apologies. The code is ready, and I was hoping that sharing the DTS
> >>> changes would make reviewing the driver and dt-bindings a bit easier.
> >>> The original RFC had them together, and I split it out for net-next
> >>> and linux-next.
> >>
> >> Yeah, but why calling it completely different than every other patchset?
> >> Why coming with different style? Why this cannot be RFC?
> > 
> > Agreed. In hindsight, this should probably have been an RFC v2. I saw
> > some recent series using a PRELIMINARY tag, but I see that its
> 
> Where?
> https://lore.kernel.org/all/?q=s%3APRELIMINARY
> 

Please ignore me, I should have labelled it as an RFC. I mixed up two
very different things (some off-list patch I was CC'd to and LKML
patches).

I should have waited for my morning cup of coffee before hitting send,
sorry for wasting your time.

	Ayaan