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>

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

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

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

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

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

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

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/

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

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