Re: [PATCH net-next v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies

["Russell King (Oracle)" <linux@armlinux.org.uk>]

According to patchwork, this doesn't apply to net-next. That's odd,
it was generated on last night's net next, and although there has been
further work, it rebases cleanly on top of this morning's. How can
these changes:

 drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c   |  6 +++++-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 20 ++++++++++++++++----
 2 files changed, 21 insertions(+), 5 deletions(-)

which happened in net-next overnight result in this change in patch 1:

 drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 3 ---
 1 file changed, 3 deletions(-)

failing to apply?

No, patchwork is clearly wrong.

On Fri, Jan 23, 2026 at 09:52:00AM +0000, Russell King (Oracle) wrote:
> This is the v1 submission: if it doesn't get tested but review goes
> well, it'll end up in net-next and mainline without testing on the
> affected hardware!
> 
> Mentioned previously, I've been trying to sort out the PCS support in
> stmmac, and this series represents the current state of play.
> 
> Previous posted patches centred around merely getting autonegotiation
> to be configured correctly, to a point where the manual configuration
> can be removed from the qcom-ethqos driver. The qcom-ethqos driver
> uses both SGMII and 2500BASE-X, manually configuring the dwmac's
> integrated PCS appropriately.
> 
> This *untested* series attempts to take this further. The patches:
> 
> - clean up qcom-ethqos only-written mac_base member.
> - convert qcom-ethqos to use the set_clk_tx_rate() method for setting
>   the link clock rate.
> - add support for phy_set_mode_ext() to the qcom "SGMII" ethernet
>   SerDes driver (which is really only what it needs. Note that
>   phy_set_mode_ext() is an expected call to be made, where as
>   phy_set_speed() is optional and not. See PHY documentation.)
> - add platform-glue independent SerDes support to the stmmac core
>   driver. Currently, only qcom-ethqos will make use of this, and
>   I suspect as we haven't had this, it's going to be difficult to
>   convert other platform glue to use this - but had this existed
>   earlier, we could've pushed people to use PHY to abstract some
>   of the platform glue differences. Adding it now makes it available
>   for future platform glue.
> - convert qcom-ethqos to use this core SerDes support.
> - arrange for stmmac_pcs.c to supply the phy_intf_sel field value
>   if the integrated PCS will be used. (PHY_INTF_SEL_SGMII requires
>   the integrated PCS rather than an external PCS.)
> - add BASE-X support to the integrated PCS driver, and use it for
>   BASE-X modes. This fully supports in-band mode, including reading
>   the link partner advertisement.
> - add in-band support for SGMII, reading the state from the RGSMII
>   status field.
> 
> As we leave qcom-ethqos' manual configuration of the PCS in place at
> the moment, the last patch adds reporting of any changes in its
> configuration that the qcom-ethqos driver does beyond what phylink
> requested, thus providing a path to debug and eventually remove
> qcom-ethqos' manual configuration.
> 
> One patch is not included in this set - which adds a phy_intf_sel
> value for external PCS (using PHY_INTF_SEL_GMII_MII). I believe all
> external PCS use this mode when connected to a MAC capable of up to
> 2.5G. However, no platform glue that provides the mac_select_pcs()
> method also provide the set_phy_intf_sel() method, so we can safely
> ignore this for now.
> 
> I would like to get this into net-next before the next merge window,
> so testing would be appreciated. If there are issues with these patches
> applied, please check whether the issue exists without these patches
> and only report regressions caused by this patch set. For example,
> I'm aware that qcom-ethqos has issues with 10Mbps mode due to an AQR
> PHY being insanely provisioned to use SGMII in 1000M mode but with
> rate matching with 10M media. This is not an issue that is relevant
> to this patch series, but a problem with the PHY provisioning.
> 
> rfc->v1:
>  - fix SGMII link status
>  - avoid calling phy_get_mode() if PHY is null
> v2:
>  - fix further AI review bot dribble that could've been raised on
>    the rfc version but wasn't.
>  
>  drivers/net/ethernet/stmicro/stmmac/Makefile       |   2 +-
>  drivers/net/ethernet/stmicro/stmmac/common.h       |   1 -
>  .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    |  74 ++-----
>  drivers/net/ethernet/stmicro/stmmac/dwmac1000.h    |  12 +-
>  .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  11 +-
>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h       |  10 +-
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  |  10 +-
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  69 +++++--
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c   | 222 +++++++++++++++++++--
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h   |  53 ++---
>  .../net/ethernet/stmicro/stmmac/stmmac_serdes.c    | 111 +++++++++++
>  .../net/ethernet/stmicro/stmmac/stmmac_serdes.h    |  16 ++
>  drivers/phy/qualcomm/phy-qcom-sgmii-eth.c          |  43 ++++
>  include/linux/stmmac.h                             |   2 +
>  14 files changed, 491 insertions(+), 145 deletions(-)
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!