Hi,

This is an early RFC which adds the XPCS and ETHQOS plumbing required
to enable 10 Gigabit Ethernet on the Qualcomm Nord SoC. This is the
first time USXGMII together with an external PCS is being supported by
the dwmac-qcom-ethqos driver.

This platform was somewhat tricky to work on, with several new pieces
having to come together across the MAC, XPCS and SerDes layers. Any
feedback would be appreciated, particularly around the XPCS modelling
and the generic stmmac register-layout changes.

The overall hardware path looks like this:

  +------------------+      +------------------+      +------------------+      +------------------+
  |    DW25GMAC      | ---> |  Synopsys XPCS   | ---> | QCOM SGMII PHY   | ===> | Ext PHY / Switch |
  | + QCOM ETHQOS    |      | + QCOM wrapper   |      |    (SerDes)      |      | USX/10GBASE-R    |
  +------------------+      +------------------+      +------------------+      +------------------+

The series can be broadly divided into two areas:

1. Qualcomm XPCS support

Nord integrates a Synopsys DesignWare XPCS, but exposes the PCS,
PMA/PMD and MII MMD register regions through separate direct-MMIO
windows instead of the standard contiguous or indirect XPCS mappings.
Patches 1 through 5 add the binding, generic platform register-access
hooks, the Qualcomm MMD-to-MMIO translation, and the runtime-PM handling
needed for the CSR clock.

The XPCS also uses Clause 37 control and status for USXGMII, while the
generic XPCS support currently handles USXGMII using Clause 73. Patch 2
adds the required Clause 37 USXGMII configuration and link-state path.

Using a small Qualcomm-specific access layer around the existing XPCS
core was the most straightforward way I could find to model this IP.
The core already uses synthetic IDs for the NXP integrations and has
vendor-specific hooks for other XPCS implementations, so this series
follows a similar approach. I am very much open to suggestions if there
is a cleaner way to represent the non-standard register mapping.

2. DW25GMAC and Qualcomm ETHQOS support

Patches 6 through 9 add the Nord ETHQOS binding and driver support. The
Nord integration has sparse, platform-specific MTL queue and DMA channel
addresses, as well as a relocated timestamp register bank. The series
therefore adds optional XGMAC register-layout data while preserving the
standard layout for existing platforms.

The ETHQOS driver then selects the XPCS provided through pcs-handle and
adds the Nord wrapper programming required for USXGMII, including the
EEE clock vote needed for PCS link-up and the platform-specific SerDes
loopback control.

This series has an obvious dependency on Jitendra Vegiraju's DW25GMAC
work:
https://lore.kernel.org/netdev/20260402213629.1996133-1-jitendra.vegiraju@broadcom.com/

I understand that a v10 of that series is planned. While bringing up
Nord, I also needed a few fixes on top of the DW25GMAC series. Those are
not included here; I will share them separately with Jitendra in case
they are useful for the next revision.

Testing:
Initial testing was done on the Nord Ride SX platform, where both
Ethernet ports connect to the on-board MV-Q6223 switch using fixed-link
USXGMII at 10 Gbps. The testing tree included the DW25GMAC dependency
and the additional fixups mentioned above.

Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
---
Mohd Ayaan Anwar (9):
      dt-bindings: net: pcs: add Qualcomm Nord XPCS
      net: pcs: xpcs: add USXGMII Clause 37 autoneg support
      net: pcs: xpcs: add custom platform register accessors
      net: pcs: xpcs: add Qualcomm Nord platform support
      net: pcs: xpcs: initialize runtime PM as suspended
      dt-bindings: net: qcom,ethqos: add Qualcomm Nord
      net: stmmac: support custom XGMAC register layouts
      net: stmmac: qcom-ethqos: support external PCS
      net: stmmac: qcom-ethqos: add Qualcomm Nord support

 .../devicetree/bindings/net/pcs/snps,dw-xpcs.yaml  |  17 +++
 .../devicetree/bindings/net/qcom,ethqos.yaml       |  57 ++++++--
 .../devicetree/bindings/net/snps,dwmac.yaml        |   2 +
 drivers/net/ethernet/stmicro/stmmac/common.h       |   1 +
 .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    | 162 ++++++++++++++++++++-
 .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c    |   2 +-
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h     |  94 ++++++++----
 .../net/ethernet/stmicro/stmmac/dwxgmac2_core.c    |  34 +++--
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 128 +++++++++-------
 drivers/net/ethernet/stmicro/stmmac/hwif.c         |   5 +-
 .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c   |   5 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.c   |  15 +-
 drivers/net/pcs/Makefile                           |   3 +-
 drivers/net/pcs/pcs-xpcs-plat.c                    |  47 +++++-
 drivers/net/pcs/pcs-xpcs-qcom.c                    |  86 +++++++++++
 drivers/net/pcs/pcs-xpcs-qcom.h                    |  16 ++
 drivers/net/pcs/pcs-xpcs.c                         | 126 ++++++++++++++++
 drivers/net/pcs/pcs-xpcs.h                         |  15 ++
 include/linux/pcs/pcs-xpcs.h                       |   2 +
 include/linux/stmmac.h                             |  11 ++
 20 files changed, 707 insertions(+), 121 deletions(-)
---
base-commit: 6598456d72e48d779445bfec8f72114747f8b8d7
change-id: 20260923-qcom_xpcs_nord_emac-bf296eb48e4b

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

Hi,

On 9/23/26 03:07, Mohd Ayaan Anwar wrote:
> Hi,
> 
> This is an early RFC which adds the XPCS and ETHQOS plumbing required
> to enable 10 Gigabit Ethernet on the Qualcomm Nord SoC. This is the
> first time USXGMII together with an external PCS is being supported by
> the dwmac-qcom-ethqos driver.

There are currently 3 in-flight series that adds glues to DW XPCS and stmmac: 

This one,
The Rockchip one from Coia [1]
The S32 one from Jan [2]


[1] : https://lore.kernel.org/netdev/20260922200336.2201212-1-coiaprant@gmail.com/
[2] : https://lore.kernel.org/netdev/20260919-s32g_serdes-v3-0-9d68868c1e89@oss.nxp.com/

MAINTAINERS entry for XPCS says :

SYNOPSYS DESIGNWARE ETHERNET XPCS DRIVER
L:      netdev@vger.kernel.org          
S:      Orphan                          
F:      drivers/net/pcs/pcs-xpcs.c      
F:      drivers/net/pcs/pcs-xpcs.h      
F:      include/linux/pcs/pcs-xpcs.h    

It would nice if some of you could help maintain the core XPCS driver, and make sure
these series aren't stepping on one another :( I personnaly don't have any XPCS HW
for tests.

You don't have to do it alone, multiple people can co-maintain that :) Maybe
Synopsys folks can also chime in ?

Maxime

Hi Maxime,

On Wed, Sep 23, 2026 at 11:41:14AM +0200, Maxime Chevallier wrote:
> Hi,
> 
> On 9/23/26 03:07, Mohd Ayaan Anwar wrote:
> > Hi,
> > 
> > This is an early RFC which adds the XPCS and ETHQOS plumbing required
> > to enable 10 Gigabit Ethernet on the Qualcomm Nord SoC. This is the
> > first time USXGMII together with an external PCS is being supported by
> > the dwmac-qcom-ethqos driver.
> 
> There are currently 3 in-flight series that adds glues to DW XPCS and stmmac: 
> 
> This one,
> The Rockchip one from Coia [1]
> The S32 one from Jan [2]
> 
> 
> [1] : https://lore.kernel.org/netdev/20260922200336.2201212-1-coiaprant@gmail.com/
> [2] : https://lore.kernel.org/netdev/20260919-s32g_serdes-v3-0-9d68868c1e89@oss.nxp.com/
> 
> MAINTAINERS entry for XPCS says :
> 
> SYNOPSYS DESIGNWARE ETHERNET XPCS DRIVER
> L:      netdev@vger.kernel.org          
> S:      Orphan                          
> F:      drivers/net/pcs/pcs-xpcs.c      
> F:      drivers/net/pcs/pcs-xpcs.h      
> F:      include/linux/pcs/pcs-xpcs.h    
> 
> It would nice if some of you could help maintain the core XPCS driver, and make sure
> these series aren't stepping on one another :( I personnaly don't have any XPCS HW
> for tests.
> 
> You don't have to do it alone, multiple people can co-maintain that :) Maybe
> Synopsys folks can also chime in ?
> 

Thank you for sharing these series, I can help review them based on my
understanding of this IP. Hope that helps.

	Ayaan

Hello,

Thanks for the RFC. A few comments.

XPCS_ID
-------
Is 0x00000030 documented for Qualcomm, or is it derived from
NXP_SJA1110_XPCS_ID + 0x10? If it's the latter, it's a magic value and
I'd rather see it confirmed against the Qualcomm documentation or a
register dump from real hardware before it's used for platform
identification.

Non-existent MMDs
-----------------
Returning 0xffff on reads and silently discarding writes is what a
floating bus / unimplemented feature looks like, so I agree with that
direction. My pcs-xpcs-rk does the same.

Structure
---------
pcs-xpcs-plat is itself a platform glue driver, for SoCs that don't
need any platform-specific handling. Adding another abstraction layer
on top of it to cover Qualcomm would be glue on glue. Generic, Qualcomm
and Rockchip differ in power management, address window size (2M vs 8M,
...) and MMD redirection, so they don't share a probe path.

Pushing that into pcs-xpcs-plat would also drag every existing user of
the generic glue along: they would suddenly depend on GENERIC_PHY,
PM_GENERIC_DOMAINS and whatever else the Qualcomm path needs, or they
would have to carry per-platform branches in a driver that is supposed
to be platform-agnostic. A per-SoC-family glue driver, the same way
dwmac-intel, dwmac-rk, dwmac-renesas-gbeth and dwmac-rzn1 are
separate, keeps each integration self-contained and leaves the generic
glue alone.

Would it make sense to take that route here? My pcs-xpcs-rk does the
MMD redirection through a custom MDIO bus; maybe the Qualcomm glue can
reuse that idea directly instead of extending pcs-xpcs-plat. Happy to
help with the generic parts if that's useful.

Best,
Coia

> Would it make sense to take that route here? My pcs-xpcs-rk does the
> MMD redirection through a custom MDIO bus; maybe the Qualcomm glue can
> reuse that idea directly instead of extending pcs-xpcs-plat. Happy to
> help with the generic parts if that's useful.

I would be happy with a custom MDIO bus as well.

  Andrew

> Non-existent MMDs
> -----------------
> Returning 0xffff on reads and silently discarding writes is what a
> floating bus / unimplemented feature looks like, so I agree with that
> direction. My pcs-xpcs-rk does the same.

Did you read 802.3?

  45.2:

  If a device supports the MDIO interface it shall respond to all
  possible register addresses for the device and return a value of
  zero for undefined and unsupported registers. Writes to undefined
  registers and read-only registers shall have no effect. The
  operation of an MMD shall not be affected by writes to reserved and
  unsupported register bits, and such register bits shall return a
  value of zero when read.

This is what i was commenting about in my review, returning EOPNOTSUPP
is not correct according to the standard.

	Andrew

Andrew Lunn <andrew@lunn.ch> 于2026年9月24日周四 02:35写道：
>
> > Non-existent MMDs
> > -----------------
> > Returning 0xffff on reads and silently discarding writes is what a
> > floating bus / unimplemented feature looks like, so I agree with that
> > direction. My pcs-xpcs-rk does the same.
>
> Did you read 802.3?
>
>   45.2:
>
>   If a device supports the MDIO interface it shall respond to all
>   possible register addresses for the device and return a value of
>   zero for undefined and unsupported registers. Writes to undefined
>   registers and read-only registers shall have no effect. The
>   operation of an MMD shall not be affected by writes to reserved and
>   unsupported register bits, and such register bits shall return a
>   value of zero when read.
>
> This is what i was commenting about in my review, returning EOPNOTSUPP
> is not correct according to the standard.
>
>         Andrew

I hadn't gone back to 45.2 when I wrote that, so fair enough on the
standard. For what it's worth, pcs-xpcs already treats 0 and 0xff as
the "no device" values in the identity path, so the glue follows that
convention rather than inventing a new one.

Sorry for that.
Coia

On Wed, Sep 23, 2026 at 09:17:44PM +0800, Coia Prant wrote:
> Hello,
> 
> Thanks for the RFC. A few comments.
> 
> XPCS_ID
> -------
> Is 0x00000030 documented for Qualcomm, or is it derived from
> NXP_SJA1110_XPCS_ID + 0x10? If it's the latter, it's a magic value and
> I'd rather see it confirmed against the Qualcomm documentation or a
> register dump from real hardware before it's used for platform
> identification.
> 

It's the latter (NXP XPCS ID + 0x10). The Qualcomm hardware returns the
standard XPCS identifier (0x7996ced0) upon reading the 3.2, 3.3
PCS_DEV_ID registers. I tried following a similar approach to the NXP
DSA driver of reporting a synthetic value to bind to the Qualcomm part. 

All this was just to make it work with pcs-xpcs-plat without introducing
a ton of code.

> Structure
> ---------
> pcs-xpcs-plat is itself a platform glue driver, for SoCs that don't
> need any platform-specific handling. Adding another abstraction layer
> on top of it to cover Qualcomm would be glue on glue. Generic, Qualcomm
> and Rockchip differ in power management, address window size (2M vs 8M,
> ...) and MMD redirection, so they don't share a probe path.
> 
> Pushing that into pcs-xpcs-plat would also drag every existing user of
> the generic glue along: they would suddenly depend on GENERIC_PHY,
> PM_GENERIC_DOMAINS and whatever else the Qualcomm path needs, or they
> would have to carry per-platform branches in a driver that is supposed
> to be platform-agnostic. A per-SoC-family glue driver, the same way
> dwmac-intel, dwmac-rk, dwmac-renesas-gbeth and dwmac-rzn1 are
> separate, keeps each integration self-contained and leaves the generic
> glue alone.
> 
> Would it make sense to take that route here? My pcs-xpcs-rk does the
> MMD redirection through a custom MDIO bus; maybe the Qualcomm glue can
> reuse that idea directly instead of extending pcs-xpcs-plat. Happy to
> help with the generic parts if that's useful.
> 

I agree with your concerns regarding the glue on glue architecture. I
also don't know if each platform glue should define a custom MDIO bus
with similar logic. Maybe we can have a generic abstraction for it?

I know that Alex had a patch introducing pcs-xpcs-regmap.c [1]. My
original code for this platform actually built on top of it before I
moved to the current implementation.

At least I now know that multiple vendors have an MMIO based XPCS,
albeit with differing MMD redirection mechanisms.

I am going through the pcs-xpcs-rk patch and the eee_clk already stood
out to me. On my board, the PCS link does not come up if the EEE clock
is stopped. Going through the databook, I did find a barebones
explanation of why that might be happening for USXGMII, but I need to
dig more into it.

Thank you for the review.

	Ayaan

[1] https://lore.kernel.org/netdev/20260501155421.3329862-2-elder@riscstar.com/

Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com> 于2026年9月23日周三 22:03写道：
>
> On Wed, Sep 23, 2026 at 09:17:44PM +0800, Coia Prant wrote:
> > Hello,
> >
> > Thanks for the RFC. A few comments.
> >
> > XPCS_ID
> > -------
> > Is 0x00000030 documented for Qualcomm, or is it derived from
> > NXP_SJA1110_XPCS_ID + 0x10? If it's the latter, it's a magic value and
> > I'd rather see it confirmed against the Qualcomm documentation or a
> > register dump from real hardware before it's used for platform
> > identification.
> >
>
> It's the latter (NXP XPCS ID + 0x10). The Qualcomm hardware returns the
> standard XPCS identifier (0x7996ced0) upon reading the 3.2, 3.3
> PCS_DEV_ID registers. I tried following a similar approach to the NXP
> DSA driver of reporting a synthetic value to bind to the Qualcomm part.
>
> All this was just to make it work with pcs-xpcs-plat without introducing
> a ton of code.

OK, so it's a deliberate workaround, not a hardware value. I see the
NXP precedent, but I'm not sure it's a good one to extend: the ID space
is global and finite, so a synthetic 0x30 could collide with a future
real part and bind the wrong glue. NXP at least needs its synthetic ID
to select a platform-specific PMA config; if the Qualcomm part is
otherwise standard XPCS, matching on a fabricated ID just to bind the
same generic code seems like the wrong place to solve the problem.

Leaving the final call to the maintainers, I just wanted to make sure
we weren't matching on something made up.

> > Structure
> > ---------
> > pcs-xpcs-plat is itself a platform glue driver, for SoCs that don't
> > need any platform-specific handling. Adding another abstraction layer
> > on top of it to cover Qualcomm would be glue on glue. Generic, Qualcomm
> > and Rockchip differ in power management, address window size (2M vs 8M,
> > ...) and MMD redirection, so they don't share a probe path.
> >
> > Pushing that into pcs-xpcs-plat would also drag every existing user of
> > the generic glue along: they would suddenly depend on GENERIC_PHY,
> > PM_GENERIC_DOMAINS and whatever else the Qualcomm path needs, or they
> > would have to carry per-platform branches in a driver that is supposed
> > to be platform-agnostic. A per-SoC-family glue driver, the same way
> > dwmac-intel, dwmac-rk, dwmac-renesas-gbeth and dwmac-rzn1 are
> > separate, keeps each integration self-contained and leaves the generic
> > glue alone.
> >
> > Would it make sense to take that route here? My pcs-xpcs-rk does the
> > MMD redirection through a custom MDIO bus; maybe the Qualcomm glue can
> > reuse that idea directly instead of extending pcs-xpcs-plat. Happy to
> > help with the generic parts if that's useful.
> >
>
> I agree with your concerns regarding the glue on glue architecture. I
> also don't know if each platform glue should define a custom MDIO bus
> with similar logic. Maybe we can have a generic abstraction for it?
>
> I know that Alex had a patch introducing pcs-xpcs-regmap.c [1]. My
> original code for this platform actually built on top of it before I
> moved to the current implementation.
>
> At least I now know that multiple vendors have an MMIO based XPCS,
> albeit with differing MMD redirection mechanisms.

I looked at both pcs-xpcs-regmap and pcs-xpcs-plat. Neither fits.

The regmap helper targets a window that doesn't align to a page
boundary, but still assumes a single contiguous region. pcs-xpcs-plat's
indirect mode uses only 8 lower address bits for the register and a
viewport CSR for the upper bits. Your own patch describes the Nord
layout as "separate direct-MMIO windows" with MMD 3 at 0x0000, MMD 1 at
0x3000, MMD 31 at 0x4000 and so on. That is not a contiguous Clause 45
space, and it is not the indirect paged layout either.

Mapping the Nord registers onto pcs-xpcs-plat's indirect mode would
mean claiming the memory is something it isn't: the hardware exposes
direct windows, but the driver would have to lie about the access
model. It also doesn't match the DT binding, which describes a single
reg-names = "indirect" region. A platform with separate direct windows
should describe those windows, not pretend they are paged.

The Rockchip glue differs from pcs-xpcs-plat in more than just address
translation:

- it marks PD_PIPE as part of the wakeup path so genpd keeps the
  power domain on during system suspend, which is required for MAC WoL
- it keeps PD_PIPE on at runtime via dev_pm_genpd_rpm_always_on()
- it adds a separate "eee" clock on top of the csr/core/pad clocks that
  the generic driver knows about, and derives the
  DW_VR_MII_EEE_MULT_FACT_100NS value from the EEE clock rate at runtime
- the read and write remapping paths differ

None of that is address translation. Folding it into a generic glue
means either per-platform conditionals or an ops layer where each
platform stubs half the callbacks. I'd rather keep them separate, the
same way dwmac-intel, dwmac-rk, dwmac-renesas-gbeth and dwmac-rzn1 are
separate.

If the common parts can be factored out cleanly later, I'm happy to
rebase onto that. But the platform glue is where the platform
differences live, and right now those differences are substantial.

> I am going through the pcs-xpcs-rk patch and the eee_clk already stood
> out to me. On my board, the PCS link does not come up if the EEE clock
> is stopped. Going through the databook, I did find a barebones
> explanation of why that might be happening for USXGMII, but I need to
> dig more into it.

Same on RK3568. Without clk_xpcs_eee the SGMII link is unstable, which
is how the Rockchip glue ended up enabling it unconditionally in
xpcs_rk_init_clk(). Downstream carried a fix for the same problem:

  https://github.com/immortalwrt/immortalwrt/commit/2ff0f9435f688b1d9ae275710e13ecd0c54e9724

The databook calls it clk_xpcs_eee, but the generic XPCS driver only
knows about the core/pad clocks, so the Rockchip glue adds a separate
"eee" clock for it.

Looking forward to seeing where the Qualcomm glue lands.

Best regards,
Coia

On Wed, Sep 23, 2026 at 9:08 AM Mohd Ayaan Anwar
<mohd.anwar@oss.qualcomm.com> wrote:
>
> Hi,
>
> This is an early RFC which adds the XPCS and ETHQOS plumbing required
> to enable 10 Gigabit Ethernet on the Qualcomm Nord SoC. This is the
> first time USXGMII together with an external PCS is being supported by
> the dwmac-qcom-ethqos driver.
>
> This platform was somewhat tricky to work on, with several new pieces
> having to come together across the MAC, XPCS and SerDes layers. Any
> feedback would be appreciated, particularly around the XPCS modelling
> and the generic stmmac register-layout changes.
>
> The overall hardware path looks like this:
>
>   +------------------+      +------------------+      +------------------+      +------------------+
>   |    DW25GMAC      | ---> |  Synopsys XPCS   | ---> | QCOM SGMII PHY   | ===> | Ext PHY / Switch |
>   | + QCOM ETHQOS    |      | + QCOM wrapper   |      |    (SerDes)      |      | USX/10GBASE-R    |
>   +------------------+      +------------------+      +------------------+      +------------------+
>
> The series can be broadly divided into two areas:
>
> 1. Qualcomm XPCS support
>
> Nord integrates a Synopsys DesignWare XPCS, but exposes the PCS,
> PMA/PMD and MII MMD register regions through separate direct-MMIO
> windows instead of the standard contiguous or indirect XPCS mappings.
> Patches 1 through 5 add the binding, generic platform register-access
> hooks, the Qualcomm MMD-to-MMIO translation, and the runtime-PM handling
> needed for the CSR clock.
>
> The XPCS also uses Clause 37 control and status for USXGMII, while the
> generic XPCS support currently handles USXGMII using Clause 73. Patch 2
> adds the required Clause 37 USXGMII configuration and link-state path.
>
> Using a small Qualcomm-specific access layer around the existing XPCS
> core was the most straightforward way I could find to model this IP.
> The core already uses synthetic IDs for the NXP integrations and has
> vendor-specific hooks for other XPCS implementations, so this series
> follows a similar approach. I am very much open to suggestions if there
> is a cleaner way to represent the non-standard register mapping.
>
> 2. DW25GMAC and Qualcomm ETHQOS support
>
> Patches 6 through 9 add the Nord ETHQOS binding and driver support. The
> Nord integration has sparse, platform-specific MTL queue and DMA channel
> addresses, as well as a relocated timestamp register bank. The series
> therefore adds optional XGMAC register-layout data while preserving the
> standard layout for existing platforms.
>
> The ETHQOS driver then selects the XPCS provided through pcs-handle and
> adds the Nord wrapper programming required for USXGMII, including the
> EEE clock vote needed for PCS link-up and the platform-specific SerDes
> loopback control.
>
> This series has an obvious dependency on Jitendra Vegiraju's DW25GMAC
> work:
> https://lore.kernel.org/netdev/20260402213629.1996133-1-jitendra.vegiraju@broadcom.com/
>
> I understand that a v10 of that series is planned. While bringing up
> Nord, I also needed a few fixes on top of the DW25GMAC series. Those are
> not included here; I will share them separately with Jitendra in case
> they are useful for the next revision.
>
> Testing:
> Initial testing was done on the Nord Ride SX platform, where both
> Ethernet ports connect to the on-board MV-Q6223 switch using fixed-link
> USXGMII at 10 Gbps. The testing tree included the DW25GMAC dependency
> and the additional fixups mentioned above.
>
> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> ---
> Mohd Ayaan Anwar (9):
>       dt-bindings: net: pcs: add Qualcomm Nord XPCS
>       net: pcs: xpcs: add USXGMII Clause 37 autoneg support
>       net: pcs: xpcs: add custom platform register accessors
>       net: pcs: xpcs: add Qualcomm Nord platform support
>       net: pcs: xpcs: initialize runtime PM as suspended
>       dt-bindings: net: qcom,ethqos: add Qualcomm Nord
>       net: stmmac: support custom XGMAC register layouts
>       net: stmmac: qcom-ethqos: support external PCS
>       net: stmmac: qcom-ethqos: add Qualcomm Nord support
>
>  .../devicetree/bindings/net/pcs/snps,dw-xpcs.yaml  |  17 +++
>  .../devicetree/bindings/net/qcom,ethqos.yaml       |  57 ++++++--
>  .../devicetree/bindings/net/snps,dwmac.yaml        |   2 +
>  drivers/net/ethernet/stmicro/stmmac/common.h       |   1 +
>  .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    | 162 ++++++++++++++++++++-
>  .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c    |   2 +-
>  drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h     |  94 ++++++++----
>  .../net/ethernet/stmicro/stmmac/dwxgmac2_core.c    |  34 +++--
>  drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 128 +++++++++-------
>  drivers/net/ethernet/stmicro/stmmac/hwif.c         |   5 +-
>  .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c   |   5 +-
>  drivers/net/ethernet/stmicro/stmmac/stmmac_fpe.c   |  15 +-
>  drivers/net/pcs/Makefile                           |   3 +-
>  drivers/net/pcs/pcs-xpcs-plat.c                    |  47 +++++-
>  drivers/net/pcs/pcs-xpcs-qcom.c                    |  86 +++++++++++
>  drivers/net/pcs/pcs-xpcs-qcom.h                    |  16 ++
>  drivers/net/pcs/pcs-xpcs.c                         | 126 ++++++++++++++++
>  drivers/net/pcs/pcs-xpcs.h                         |  15 ++
>  include/linux/pcs/pcs-xpcs.h                       |   2 +
>  include/linux/stmmac.h                             |  11 ++
>  20 files changed, 707 insertions(+), 121 deletions(-)
> ---
> base-commit: 6598456d72e48d779445bfec8f72114747f8b8d7
> change-id: 20260923-qcom_xpcs_nord_emac-bf296eb48e4b
>
> Best regards,
> --
> Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
>

Good Job, Mohd

Tested-by: Zhangfei Gao <zhangfei.gao@oss.qualcomm.com>

Tested on both IQ10 RRD and Ride

Full test patch is in the git
https://github.com/zhangfei-gao/kernel-topics/tree/next-9.23

> Good Job, Mohd
> 
> Tested-by: Zhangfei Gao <zhangfei.gao@oss.qualcomm.com>
> 
> Tested on both IQ10 RRD and Ride

Thanks for testing, but its a bit early yet. You might want to wait
until we get to version 5 or more, and it is no longer RFC, code the
author no longer is requesting comments on but is Mainline Linux
production quality. And after the AI reviews have stopped pointing out
issues.  Only then does a tested-by: make any real sense.

Reporting your test results internally is probably appreciated as the
patchset goes through revisions.

	 Andrew

This series verifies Mohd Ayaan Anwar's patch set:

  net: introduce Qualcomm XPCS support and add Nord Ethernet plumbing [1]

Tested on both IQ10 RRD and Ride

The full test branch is available at:

  https://github.com/zhangfei-gao/kernel-topics/tree/next-9.23


[1] https://lore.kernel.org/linux-arm-msm/?q=qcom_xpcs_nord_emac


Zhangfei Gao (3):
  net: stmmac: support low-speed USXGMII validation
  net: stmmac: qcom-ethqos: configure USXGMII rates
  net: stmmac: fix 10/100 support and MDIO for DW25GMAC

 .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 65 ++++++++++++++++++-
 .../ethernet/stmicro/stmmac/dwxgmac2_core.c   |  6 +-
 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  2 +
 .../net/ethernet/stmicro/stmmac/stmmac_mdio.c |  9 ++-
 drivers/net/pcs/pcs-xpcs.c                    |  9 ++-
 5 files changed, 82 insertions(+), 9 deletions(-)

-- 
2.43.0

On Wed, Sep 23, 2026 at 04:49:18PM +0800, Zhangfei Gao wrote:
> This series verifies Mohd Ayaan Anwar's patch set:
> 
>   net: introduce Qualcomm XPCS support and add Nord Ethernet plumbing [1]
> 
> Tested on both IQ10 RRD and Ride
> 
> The full test branch is available at:
> 
>   https://github.com/zhangfei-gao/kernel-topics/tree/next-9.23
> 
> 
> [1] https://lore.kernel.org/linux-arm-msm/?q=qcom_xpcs_nord_emac

Please don't submit two overlapping patches for the same driver. Wait
for the first patchset to get merged, and then submit a follow up
series.

Qualcomm has a number of Mainline Linux mentors. Please talk with
them, because these two patch series are not great.

    Andrew

---
pw-bot: cr

On Wed, Sep 23, 2026 at 8:50 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Wed, Sep 23, 2026 at 04:49:18PM +0800, Zhangfei Gao wrote:
> > This series verifies Mohd Ayaan Anwar's patch set:
> >
> >   net: introduce Qualcomm XPCS support and add Nord Ethernet plumbing [1]
> >
> > Tested on both IQ10 RRD and Ride
> >
> > The full test branch is available at:
> >
> >   https://github.com/zhangfei-gao/kernel-topics/tree/next-9.23
> >
> >
> > [1] https://lore.kernel.org/linux-arm-msm/?q=qcom_xpcs_nord_emac
>
> Please don't submit two overlapping patches for the same driver. Wait
> for the first patchset to get merged, and then submit a follow up
> series.

Thanks Andrew

Understood, my apologies.

  I will not submit an overlapping series. Hopefully, some of the fixes
  identified while reviewing and testing the RFC can be incorporated
  into the existing series.

>
> Qualcomm has a number of Mainline Linux mentors. Please talk with
> them, because these two patch series are not great.

OK, Thanks

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

USXGMII transports the negotiated copper media rate over a fixed-rate
serial link. The PCS and MAC must retain the corresponding
10/100/1000/2500/5000/10000M full-duplex capabilities.

Advertise the media-rate link modes from the XPCS and allow the stmmac
MAC to validate 10M and 100M USXGMII links. This keeps phylink from
rejecting an AQR113C PHY whose advertisement contains base-T modes.

The XPCS also consumes the PHY-generated Clause 37 in-band link and
speed status, so USXGMII must use in-band signalling.

Signed-off-by: Zhangfei Gao <zhangfei.gao@oss.qualcomm.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 ++
 drivers/net/pcs/pcs-xpcs.c                        | 9 ++++++++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2dc0cb2916daf..5954048a9f7fc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1045,6 +1045,8 @@ static unsigned long stmmac_mac_get_caps(struct phylink_config *config,
 		priv->hw->link.caps &= ~(MAC_1000HD | MAC_100HD | MAC_10HD);
 
 	config->mac_capabilities = priv->hw->link.caps;
+	if (interface == PHY_INTERFACE_MODE_USXGMII)
+		config->mac_capabilities |= MAC_10FD | MAC_100FD;
 
 	if (priv->plat->max_speed)
 		phylink_limit_mac_speed(config, priv->plat->max_speed);
diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index 091c9b57388fa..58ca296fc4420 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -23,6 +23,12 @@ static const int xpcs_usxgmii_features[] = {
 	ETHTOOL_LINK_MODE_Pause_BIT,
 	ETHTOOL_LINK_MODE_Asym_Pause_BIT,
 	ETHTOOL_LINK_MODE_Autoneg_BIT,
+	ETHTOOL_LINK_MODE_10baseT_Full_BIT,
+	ETHTOOL_LINK_MODE_100baseT_Full_BIT,
+	ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
+	ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+	ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+	ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
 	ETHTOOL_LINK_MODE_1000baseKX_Full_BIT,
 	ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT,
 	ETHTOOL_LINK_MODE_10000baseKR_Full_BIT,
@@ -737,7 +743,8 @@ static unsigned int xpcs_inband_caps(struct phylink_pcs *pcs,
 	case DW_10GBASER:
 	case DW_2500BASEX:
 	case DW_AN_C37_USXGMII:
-		return LINK_INBAND_DISABLE;
+		/* The PCS consumes the PHY's CL37 in-band link and speed status. */
+		return LINK_INBAND_ENABLE;
 
 	default:
 		return 0;
-- 
2.43.0

> The XPCS also consumes the PHY-generated Clause 37 in-band link and
> speed status, so USXGMII must use in-band signalling.

Is this a qualcomm specific feature, or defined in the databook of the
licensed IP.

>  	case DW_AN_C37_USXGMII:
> -		return LINK_INBAND_DISABLE;
> +		/* The PCS consumes the PHY's CL37 in-band link and speed status. */
> +		return LINK_INBAND_ENABLE;

I ask, because when i look at this, i immediately think is this a
behaviour change? Is it going to break existing systems? Or was the
old code broken?

The commit message is where you try to guess what reviewers are going
to ask, and answer the question before they ask. Seeing such answers
in the commit message gives me a good idea you have done your due
diligence, and the patch is probably O.K. Without such comments, i
have to assume this is poor quality code and really exam it in detail.

     Andrew

On Wed, Sep 23, 2026 at 9:09 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > The XPCS also consumes the PHY-generated Clause 37 in-band link and
> > speed status, so USXGMII must use in-band signalling.
>
> Is this a qualcomm specific feature, or defined in the databook of the
> licensed IP.

This is defined by the Synopsys DWC XPCS databook, rather than being
  Qualcomm-specific. The Clause 37 USXGMII implementation added by this
  series uses PHY-generated in-band status containing link, speed and
  duplex information.

>
> >       case DW_AN_C37_USXGMII:
> > -             return LINK_INBAND_DISABLE;
> > +             /* The PCS consumes the PHY's CL37 in-band link and speed status. */
> > +             return LINK_INBAND_ENABLE;
>
> I ask, because when i look at this, i immediately think is this a
> behaviour change? Is it going to break existing systems? Or was the
> old code broken?

 DW_AN_C37_USXGMII is newly introduced by this series. This change adds
  a separate case for that new mode and leaves the existing DW_10GBASER
  and DW_2500BASEX cases returning LINK_INBAND_DISABLE. Therefore, it
  does not change the behaviour of any existing XPCS mode or system. It
  also matches the implementation added by this series, which enables
  Clause 37 AN and reads the received USXGMII status in
  xpcs_get_state_c37_usxgmii().

        case DW_10GBASER:
        case DW_2500BASEX:
                return LINK_INBAND_DISABLE;

+       case DW_AN_C37_USXGMII:
+               /* The PCS consumes the PHY's CL37 in-band link and
speed status. */
+               return LINK_INBAND_ENABLE;
+

>
> The commit message is where you try to guess what reviewers are going
> to ask, and answer the question before they ask. Seeing such answers
> in the commit message gives me a good idea you have done your due
> diligence, and the patch is probably O.K. Without such comments, i
> have to assume this is poor quality code and really exam it in detail.

Thanks for the guidance.

Thanks

> diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
> index 091c9b57388fa..58ca296fc4420 100644
> --- a/drivers/net/pcs/pcs-xpcs.c
> +++ b/drivers/net/pcs/pcs-xpcs.c
> @@ -23,6 +23,12 @@ static const int xpcs_usxgmii_features[] = {
>  	ETHTOOL_LINK_MODE_Pause_BIT,
>  	ETHTOOL_LINK_MODE_Asym_Pause_BIT,
>  	ETHTOOL_LINK_MODE_Autoneg_BIT,
> +	ETHTOOL_LINK_MODE_10baseT_Full_BIT,
> +	ETHTOOL_LINK_MODE_100baseT_Full_BIT,
> +	ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
> +	ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
> +	ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
> +	ETHTOOL_LINK_MODE_10000baseT_Full_BIT,

What does T in 10000baseT mean?

>  	ETHTOOL_LINK_MODE_1000baseKX_Full_BIT,
>  	ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT,
>  	ETHTOOL_LINK_MODE_10000baseKR_Full_BIT,

Compare and contract with KX.

	Andrew

Hi, Andrew

On Wed, Sep 23, 2026 at 8:58 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
> > index 091c9b57388fa..58ca296fc4420 100644
> > --- a/drivers/net/pcs/pcs-xpcs.c
> > +++ b/drivers/net/pcs/pcs-xpcs.c
> > @@ -23,6 +23,12 @@ static const int xpcs_usxgmii_features[] = {
> >       ETHTOOL_LINK_MODE_Pause_BIT,
> >       ETHTOOL_LINK_MODE_Asym_Pause_BIT,
> >       ETHTOOL_LINK_MODE_Autoneg_BIT,
> > +     ETHTOOL_LINK_MODE_10baseT_Full_BIT,
> > +     ETHTOOL_LINK_MODE_100baseT_Full_BIT,
> > +     ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
> > +     ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
> > +     ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
> > +     ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
>
> What does T in 10000baseT mean?
>
> >       ETHTOOL_LINK_MODE_1000baseKX_Full_BIT,
> >       ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT,
> >       ETHTOOL_LINK_MODE_10000baseKR_Full_BIT,
>
> Compare and contract with KX.

 T denotes twisted-pair copper media, whereas KX/KR denote backplane
  Ethernet modes. USXGMII is the host-side interface between the MAC/PCS
  and the external PHY; it is not itself a media type.

  The BASE-T modes are needed here because the attached PHY reports its
  line-side capabilities as BASE-T modes, which must pass XPCS
  validation.

  How about using a separate feature table for Clause 37 USXGMII, while
  leaving the existing table unchanged?

  +static const int xpcs_c37_usxgmii_features[] = {
  +     ETHTOOL_LINK_MODE_Pause_BIT,
  +     ETHTOOL_LINK_MODE_Asym_Pause_BIT,
  +     ETHTOOL_LINK_MODE_Autoneg_BIT,
  +     ETHTOOL_LINK_MODE_10baseT_Full_BIT,
  +     ETHTOOL_LINK_MODE_100baseT_Full_BIT,
  +     ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
  +     ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
  +     ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
  +     ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
  +     __ETHTOOL_LINK_MODE_MASK_NBITS,
  +};

  -     .supported = xpcs_usxgmii_features,
  +     .supported = xpcs_c37_usxgmii_features,

  This keeps the capabilities of existing Clause 73 users unchanged.

Thanks

Program the Qualcomm EMAC wrapper for the negotiated USXGMII media
rate. The serial SerDes lane remains at the USXGMII rate, while the
wrapper clock and IO macro settings follow the
10/100/1000/2500/5000/10000M MAC rate.

Without the low-speed settings, a 100M link is reported by the PHY but
the wrapper rejects it as an unsupported USXGMII speed.

USXGMII also defaults to phylink in-band mode because the QCOM host
requires the PHY-generated in-band link status.

Signed-off-by: Zhangfei Gao <zhangfei.gao@oss.qualcomm.com>
---
 .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 65 ++++++++++++++++++-
 1 file changed, 62 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index 280f9289753da..54a6c98e42057 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -38,6 +38,7 @@
 #define RGMII_CONFIG_GPIO_CFG_TX_INT		GENMASK(19, 17)
 #define RGMII_CONFIG_MAX_SPD_PRG_9		GENMASK(16, 8)
 #define RGMII_CONFIG_MAX_SPD_PRG_2		GENMASK(7, 6)
+#define RGMII_CONFIG_MAX_SPD_PRG_2_V4		GENMASK(9, 6)
 #define RGMII_CONFIG_INTF_SEL			GENMASK(5, 4)
 #define RGMII_CONFIG_BYPASS_TX_ID_EN		BIT(3)
 #define RGMII_CONFIG_LOOPBACK_EN		BIT(2)
@@ -84,6 +85,12 @@
 #define RGMII_CONFIG2_DATA_DIVIDE_CLK_SEL	BIT(6)
 #define RGMII_CONFIG2_TX_CLK_PHASE_SHIFT_EN	BIT(5)
 #define RGMII_CONFIG2_MODE_EN_VIA_GMII		BIT(21)
+#define RGMII_CONFIG2_MAX_SPD_PRG_3		GENMASK(20, 17)
+
+/* RGMII_IO_MACRO_SCRATCH_2 fields */
+#define RGMII_SCRATCH2_MAX_SPD_PRG_4		GENMASK(5, 2)
+#define RGMII_SCRATCH2_MAX_SPD_PRG_5		GENMASK(9, 6)
+#define RGMII_SCRATCH2_MAX_SPD_PRG_6		GENMASK(13, 10)
 
 /* EMAC_WRAPPER_SGMII_PHY_CNTRL0 fields */
 #define SGMII_PHY_CNTRL0_2P5G_1G_CLK_SEL	GENMASK(6, 5)
@@ -135,6 +142,7 @@ struct qcom_ethqos {
 	struct clk *eee_clk;
 	struct phy *serdes_phy;
 	phy_interface_t phy_mode;
+	int speed;
 
 	const struct ethqos_emac_por *rgmii_por;
 	unsigned int num_rgmii_por;
@@ -557,9 +565,56 @@ static void ethqos_configure_usxgmii(struct qcom_ethqos *ethqos)
 	rgmii_updatel(ethqos, USXGMII_CLK_BLK_CLK_EN, 0,
 		      EMAC_WRAPPER_USXGMII_MUX_SEL);
 
-	rgmii_updatel(ethqos, USXGMII_CLK_BLK_GMII_CLK_BLK_SEL,
-		      USXGMII_CLK_BLK_GMII_CLK_BLK_SEL,
-		      EMAC_WRAPPER_USXGMII_MUX_SEL);
+	switch (ethqos->speed) {
+	case SPEED_10000:
+		rgmii_updatel(ethqos, USXGMII_CLK_BLK_GMII_CLK_BLK_SEL,
+			      USXGMII_CLK_BLK_GMII_CLK_BLK_SEL,
+			      EMAC_WRAPPER_USXGMII_MUX_SEL);
+		break;
+	case SPEED_5000:
+		rgmii_updatel(ethqos, SGMII_PHY_CNTRL0_2P5G_1G_CLK_SEL, 0,
+			      EMAC_WRAPPER_SGMII_PHY_CNTRL0);
+		rgmii_updatel(ethqos, RGMII_CONFIG_MAX_SPD_PRG_2_V4,
+			      BIT(6) | BIT(7), RGMII_IO_MACRO_CONFIG);
+		rgmii_updatel(ethqos, RGMII_CONFIG2_MAX_SPD_PRG_3,
+			      BIT(17) | BIT(18), RGMII_IO_MACRO_CONFIG2);
+		break;
+	case SPEED_2500:
+		rgmii_updatel(ethqos, SGMII_PHY_CNTRL0_2P5G_1G_CLK_SEL, 0,
+			      EMAC_WRAPPER_SGMII_PHY_CNTRL0);
+		rgmii_updatel(ethqos, RGMII_CONFIG_SGMII_CLK_DVDR,
+			      BIT(10) | BIT(11), RGMII_IO_MACRO_CONFIG);
+		rgmii_updatel(ethqos, RGMII_SCRATCH2_MAX_SPD_PRG_4,
+			      BIT(2) | BIT(3), RGMII_IO_MACRO_SCRATCH_2);
+		rgmii_updatel(ethqos, RGMII_SCRATCH2_MAX_SPD_PRG_5, 0,
+			      RGMII_IO_MACRO_SCRATCH_2);
+		break;
+	case SPEED_1000:
+	case SPEED_100:
+		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
+			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
+			      RGMII_IO_MACRO_CONFIG2);
+		if (ethqos->speed == SPEED_100) {
+			rgmii_updatel(ethqos, RGMII_CONFIG_MAX_SPD_PRG_2_V4,
+				      BIT(9), RGMII_IO_MACRO_CONFIG);
+			rgmii_updatel(ethqos, RGMII_CONFIG2_MAX_SPD_PRG_3,
+				      BIT(20), RGMII_IO_MACRO_CONFIG2);
+			rgmii_updatel(ethqos, RGMII_SCRATCH2_MAX_SPD_PRG_6,
+				      BIT(10), RGMII_IO_MACRO_SCRATCH_2);
+		}
+		break;
+	case SPEED_10:
+		rgmii_updatel(ethqos, RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
+			      RGMII_CONFIG2_RGMII_CLK_SEL_CFG,
+			      RGMII_IO_MACRO_CONFIG2);
+		break;
+	default:
+		dev_err(&ethqos->pdev->dev,
+			"unsupported USXGMII speed %d\n", ethqos->speed);
+		return;
+	}
+
+	return;
 }
 
 static void
@@ -568,6 +623,7 @@ ethqos_fix_mac_speed_usxgmii(void *bsp_priv, phy_interface_t interface,
 {
 	struct qcom_ethqos *ethqos = bsp_priv;
 
+	ethqos->speed = speed;
 	ethqos_configure_usxgmii(ethqos);
 }
 
@@ -836,6 +892,9 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
 		plat_dat->mac_finish = ethqos_mac_finish_serdes;
 		break;
 	case PHY_INTERFACE_MODE_USXGMII:
+		plat_dat->default_an_inband = true;
+		fallthrough;
+	case PHY_INTERFACE_MODE_10GBASER:
 		plat_dat->fix_mac_speed = ethqos_fix_mac_speed_usxgmii;
 		plat_dat->mac_finish = ethqos_mac_finish_serdes;
 		break;
-- 
2.43.0

DW25GMAC currently advertises link modes starting at 1Gbps and does not
provide the MAC speed encodings for 10Mbps and 100Mbps. This leaves the
MAC speed field incorrectly configured when a USXGMII PHY negotiates a
legacy speed.

The MDIO setup also selects the XGMAC clock divider table and MDIO
accessors only for DWMAC_CORE_XGMAC. DW25GMAC uses the same MDIO
interface, so falling back to the generic path can cause PHY register
accesses to time out and prevent the PHY from probing.

Add the missing 10/100 capabilities and speed encodings, and handle
DWMAC_CORE_25GMAC through the XGMAC MDIO paths.

Fixes: 4975cb3b1b66 ("net: stmmac: Add DW25GMAC support in stmmac core driver")
Signed-off-by: Zhangfei Gao <zhangfei.gao@oss.qualcomm.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 6 ++++--
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c   | 9 ++++++---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 0b00d880fd305..65221b4becf51 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -1563,9 +1563,11 @@ int dw25gmac_setup(struct stmmac_priv *priv)
 	dwxgmac2_common_setup(priv, "DW25GMAC");
 
 	mac->link.caps = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
-			 MAC_1000FD | MAC_2500FD | MAC_5000FD |
-			 MAC_10000FD | MAC_25000FD;
+				 MAC_10 | MAC_100 | MAC_1000FD | MAC_2500FD | MAC_5000FD |
+				 MAC_10000FD | MAC_25000FD;
 	mac->link.duplex = 0;
+	mac->link.speed10 = XGMAC_CONFIG_SS_10_MII;
+	mac->link.speed100 = XGMAC_CONFIG_SS_100_MII;
 	mac->link.speed1000 = XGMAC_CONFIG_SS_1000_GMII;
 	mac->link.speed2500 = XGMAC_CONFIG_SS_2500_GMII;
 	mac->link.xgmii.speed2500 = XGMAC_CONFIG_SS_2500;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index afe98ff5bdcb0..f20a6e056781f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -552,7 +552,8 @@ static u32 stmmac_clk_csr_set(struct stmmac_priv *priv)
 	rates = stmmac_std_csr_to_mdc;
 	if (priv->plat->flags & STMMAC_FLAG_HAS_SUN8I)
 		rates = stmmac_sun8i_csr_to_mdc;
-	if (priv->plat->core_type == DWMAC_CORE_XGMAC)
+	if (priv->plat->core_type == DWMAC_CORE_XGMAC ||
+	    priv->plat->core_type == DWMAC_CORE_25GMAC)
 		rates = stmmac_xgmac_csr_to_mdc;
 
 	for (i = 0; rates[i].rate; i++)
@@ -619,7 +620,8 @@ int stmmac_mdio_register(struct net_device *ndev)
 
 	new_bus->name = "stmmac";
 
-	if (priv->plat->core_type == DWMAC_CORE_XGMAC) {
+	if (priv->plat->core_type == DWMAC_CORE_XGMAC ||
+	    priv->plat->core_type == DWMAC_CORE_25GMAC) {
 		new_bus->read = &stmmac_xgmac2_mdio_read_c22;
 		new_bus->write = &stmmac_xgmac2_mdio_write_c22;
 		new_bus->read_c45 = &stmmac_xgmac2_mdio_read_c45;
@@ -663,7 +665,8 @@ int stmmac_mdio_register(struct net_device *ndev)
 	}
 
 	/* Looks like we need a dummy read for XGMAC only and C45 PHYs */
-	if (priv->plat->core_type == DWMAC_CORE_XGMAC)
+	if (priv->plat->core_type == DWMAC_CORE_XGMAC ||
+	    priv->plat->core_type == DWMAC_CORE_25GMAC)
 		stmmac_xgmac2_mdio_read_c45(new_bus, 0, 0, 0);
 
 	/* If fixed-link is set, skip PHY scanning */
-- 
2.43.0