| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aXNX1oi7nWLcPK28@shell.armlinux.org.uk> Date: Fri, 23 Jan 2026 11:13:26 +0000 From: "Russell King (Oracle)" <linux@...linux.org.uk> To: Andrew Lunn <andrew@...n.ch> Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>, Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Konrad Dybcio <konrad.dybcio@....qualcomm.com>, linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org, linux-stm32@...md-mailman.stormreply.com, Mohd Ayaan Anwar <mohd.anwar@....qualcomm.com>, Neil Armstrong <neil.armstrong@...aro.org>, netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>, Vinod Koul <vkoul@...nel.org> Subject: Re: [PATCH net-next v2 00/14] net: stmmac: SerDes, PCS, BASE-X, and inband goodies 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!
Powered by blists - more mailing lists