From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 06:23:45
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 [off-list ref]
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 06:23:50
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(-)
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 06:23:56
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(+)
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 06:24:01
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(+)
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 06:24:08
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(+)
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 06:24:13
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(+)
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-08 06:56:48
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
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 07:04:33
On Tue, Sep 08, 2026 at 08:56:39AM +0200, Krzysztof Kozlowski wrote:
On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
quoted
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
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-08 07:14:54
On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
On Tue, Sep 08, 2026 at 08:56:39AM +0200, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
quoted
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
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 07:23:48
On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
quoted
On Tue, Sep 08, 2026 at 08:56:39AM +0200, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
quoted
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.
quoted
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
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 07:39:24
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:
quoted
On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
quoted
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.
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-08 08:40:54
On 08/09/2026 09:23, Mohd Ayaan Anwar wrote:
On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
quoted
On Tue, Sep 08, 2026 at 08:56:39AM +0200, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
quoted
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
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-08 08:42:50
On 08/09/2026 09:39, Mohd Ayaan Anwar wrote:
On Tue, Sep 08, 2026 at 12:53:46PM +0530, Mohd Ayaan Anwar wrote:
quoted
On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
quoted
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
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 09:31:45
On Tue, Sep 08, 2026 at 10:40:45AM +0200, Krzysztof Kozlowski wrote:
On 08/09/2026 09:23, Mohd Ayaan Anwar wrote:
quoted
On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
quoted
On Tue, Sep 08, 2026 at 08:56:39AM +0200, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
quoted
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
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
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 10:02:57
On Tue, Sep 08, 2026 at 10:42:40AM +0200, Krzysztof Kozlowski wrote:
On 08/09/2026 09:39, Mohd Ayaan Anwar wrote:
quoted
On Tue, Sep 08, 2026 at 12:53:46PM +0530, Mohd Ayaan Anwar wrote:
quoted
On Tue, Sep 08, 2026 at 09:14:45AM +0200, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 09:04, Mohd Ayaan Anwar wrote:
quoted
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
From: Andrew Lunn <andrew@lunn.ch> Date: 2026-09-08 12:11:33
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
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-08 13:43:33
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:
quoted
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
From: Andrew Lunn <andrew@lunn.ch> Date: 2026-09-08 13:57:30
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
From: Konrad Dybcio <hidden> Date: 2026-09-09 11:19:41
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>
---
From: Konrad Dybcio <hidden> Date: 2026-09-09 11:20:22
On 9/8/26 3:57 PM, Andrew Lunn wrote:
quoted
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
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-09 11:24:10
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(-)
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-09 11:30:13
On 09/09/2026 13:24, Krzysztof Kozlowski wrote:
On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
quoted
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?
quoted
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(-)
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-09-09 11:34:06
On 09/09/2026 13:30, Krzysztof Kozlowski wrote:
On 09/09/2026 13:24, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
quoted
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?
quoted
quoted
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(-)
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-09 11:34:19
On Wed, Sep 09, 2026 at 01:30:04PM +0200, Krzysztof Kozlowski wrote:
On 09/09/2026 13:24, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
quoted
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?
quoted
quoted
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(-)
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
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> Date: 2026-09-09 11:39:53
On Wed, Sep 09, 2026 at 01:33:57PM +0200, Krzysztof Kozlowski wrote:
On 09/09/2026 13:30, Krzysztof Kozlowski wrote:
quoted
On 09/09/2026 13:24, Krzysztof Kozlowski wrote:
quoted
On 08/09/2026 08:23, Mohd Ayaan Anwar wrote:
quoted
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?
quoted
quoted
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(-)
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
From: Konrad Dybcio <hidden> Date: 2026-09-23 13:01:23
On 9/8/26 8:23 AM, Mohd Ayaan Anwar wrote:
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>
---
From: Konrad Dybcio <hidden> Date: 2026-09-23 13:01:50
On 9/8/26 8:23 AM, Mohd Ayaan Anwar wrote:
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>
---
From: Konrad Dybcio <hidden> Date: 2026-09-23 13:02:00
On 9/8/26 8:23 AM, Mohd Ayaan Anwar wrote:
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>
---
From: Konrad Dybcio <hidden> Date: 2026-09-23 13:02:37
On 9/8/26 8:23 AM, Mohd Ayaan Anwar wrote:
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>
---