kernel.git/drivers/net/ethernet/stmicro, branch linux-5.14.y

net: stmmac: allow a tc-taprio base-time of zero

2021-11-17T10:04:44Z

[ Upstream commit f64ab8e4f368f48afb08ae91928e103d17b235e9 ] Commit fe28c53ed71d ("net: stmmac: fix taprio configuration when base_time is in the past") allowed some base time values in the past, but apparently not all, the base-time value of 0 (Jan 1st 1970) is still explicitly denied by the driver. Remove the bogus check. Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") Signed-off-by: Vladimir Oltean Reviewed-by: Kurt Kanzenbach Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: stmmac: add support for dwmac 3.40a

2021-10-27T07:59:51Z

[ Upstream commit 9cb1d19f47fafad7dcf7c8564e633440c946cfd7 ] dwmac 3.40a is an old ip version that can be found on SPEAr3xx soc. Signed-off-by: Herve Codina Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: stmmac: Fix E2E delay mechanism

2021-10-27T07:59:38Z

[ Upstream commit 3cb958027cb8b78d3ee639ce9af54c2ef1bf964f ] When utilizing End to End delay mechanism, the following error messages show up: |root@ehl1:~# ptp4l --tx_timestamp_timeout=50 -H -i eno2 -E -m |ptp4l[950.573]: selected /dev/ptp3 as PTP clock |ptp4l[950.586]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE |ptp4l[950.586]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE |ptp4l[952.879]: port 1: new foreign master 001395.fffe.4897b4-1 |ptp4l[956.879]: selected best master clock 001395.fffe.4897b4 |ptp4l[956.879]: port 1: assuming the grand master role |ptp4l[956.879]: port 1: LISTENING to GRAND_MASTER on RS_GRAND_MASTER |ptp4l[962.017]: port 1: received DELAY_REQ without timestamp |ptp4l[962.273]: port 1: received DELAY_REQ without timestamp |ptp4l[963.090]: port 1: received DELAY_REQ without timestamp Commit f2fb6b6275eb ("net: stmmac: enable timestamp snapshot for required PTP packets in dwmac v5.10a") already addresses this problem for the dwmac v5.10. However, same holds true for all dwmacs above version v4.10. Correct the check accordingly. Afterwards everything works as expected. Tested on Intel Atom(R) x6414RE Processor. Fixes: 14f347334bf2 ("net: stmmac: Correctly take timestamp for PTPv2") Fixes: f2fb6b6275eb ("net: stmmac: enable timestamp snapshot for required PTP packets in dwmac v5.10a") Suggested-by: Ong Boon Leong Signed-off-by: Kurt Kanzenbach Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: stmmac: fix get_hw_feature() on old hardware

2021-10-20T09:57:55Z

commit 075da584bae2da6a37428d59a477b6bdad430ac3 upstream. Some old IPs do not provide the hardware feature register. On these IPs, this register is read 0x00000000. In old driver version, this feature was handled but a regression came with the commit f10a6a3541b4 ("stmmac: rework get_hw_feature function"). Indeed, this commit removes the return value in dma->get_hw_feature(). This return value was used to indicate the validity of retrieved information and used later on in stmmac_hw_init() to override priv->plat data if this hardware feature were valid. This patch restores the return code in ->get_hw_feature() in order to indicate the hardware feature validity and override priv->plat data only if this hardware feature is valid. Fixes: f10a6a3541b4 ("stmmac: rework get_hw_feature function") Signed-off-by: Herve Codina Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: stmmac: trigger PCS EEE to turn off on link down

2021-10-13T07:41:59Z

[ Upstream commit d4aeaed80b0ebb020fadf2073b23462928dbdc17 ] The current implementation enable PCS EEE feature in the event of link up, but PCS EEE feature is not disabled on link down. This patch makes sure PCE EEE feature is disabled on link down. Fixes: 656ed8b015f1 ("net: stmmac: fix EEE init issue when paired with EEE capable PHYs") Signed-off-by: Wong Vee Khee Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: stmmac: dwmac-rk: Fix ethernet on rk3399 based devices

2021-10-13T07:41:56Z

[ Upstream commit aec3f415f7244b7747a7952596971adb0df2f568 ] Commit 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings") while getting rid of a runtime PM warning ended up breaking ethernet on rk3399 based devices. By dropping an extra reference to the device, the commit ends up enabling suspend / resume of the ethernet device - which appears to be broken. While the issue with runtime pm is being investigated, partially revert commit 2d26f6e39afb to restore the network on rk3399. Fixes: 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings") Suggested-by: Heiko Stuebner Signed-off-by: Punit Agrawal Cc: Michael Riesch Tested-by: Heiko Stuebner Link: https://lore.kernel.org/r/20210929135049.3426058-1-punitagrawal@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: stmmac: fix EEE init issue when paired with EEE capable PHYs

2021-10-07T05:53:15Z

[ Upstream commit 656ed8b015f19bf3f6e6b3ddd9a4bb4aa5ca73e1 ] When STMMAC is paired with Energy-Efficient Ethernet(EEE) capable PHY, and the PHY is advertising EEE by default, we need to enable EEE on the xPCS side too, instead of having user to manually trigger the enabling config via ethtool. Fixed this by adding xpcs_config_eee() call in stmmac_eee_init(). Fixes: 7617af3d1a5e ("net: pcs: Introducing support for DWC xpcs Energy Efficient Ethernet") Cc: Michael Sit Wei Hong Signed-off-by: Wong Vee Khee Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: stmmac: allow CSR clock of 300MHz

2021-09-30T08:13:04Z

[ Upstream commit 08dad2f4d541fcfe5e7bfda72cc6314bbfd2802f ] The Synopsys Ethernet IP uses the CSR clock as a base clock for MDC. The divisor used is set in the MAC_MDIO_Address register field CR (Clock Rate) The divisor is there to change the CSR clock into a clock that falls below the IEEE 802.3 specified max frequency of 2.5MHz. If the CSR clock is 300MHz, the code falls back to using the reset value in the MAC_MDIO_Address register, as described in the comment above this code. However, 300MHz is actually an allowed value and the proper divider can be estimated quite easily (it's just 1Hz difference!) A CSR frequency of 300MHz with the maximum clock rate value of 0x5 (STMMAC_CSR_250_300M, a divisor of 124) gives somewhere around ~2.42MHz which is below the IEEE 802.3 specified maximum. For the ARTPEC-8 SoC, the CSR clock is this problematic 300MHz, and unfortunately, the reset-value of the MAC_MDIO_Address CR field is 0x0. This leads to a clock rate of zero and a divisor of 42, and gives an MDC frequency of ~7.14MHz. Allow CSR clock of 300MHz by making the comparison inclusive. Signed-off-by: Jesper Nilsson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

stmmac: dwmac-loongson:Fix missing return value

2021-09-22T10:39:27Z

[ Upstream commit 5289de5929d1758a95477a4d160195397ccffa7b ] Add the return value when phy_mode < 0. Signed-off-by: zhaoxiao Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: stmmac: platform: fix build warning when with !CONFIG_PM_SLEEP

2021-09-22T10:39:23Z

commit 2a48d96fd58a666ae231c3dd6fe4a458798ac645 upstream. Use __maybe_unused for noirq_suspend()/noirq_resume() hooks to avoid build warning with !CONFIG_PM_SLEEP: >> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:796:12: error: 'stmmac_pltfr_noirq_resume' defined but not used [-Werror=unused-function] 796 | static int stmmac_pltfr_noirq_resume(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:775:12: error: 'stmmac_pltfr_noirq_suspend' defined but not used [-Werror=unused-function] 775 | static int stmmac_pltfr_noirq_suspend(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Fixes: 276aae377206 ("net: stmmac: fix system hang caused by eee_ctrl_timer during suspend/resume") Reported-by: kernel test robot Signed-off-by: Joakim Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman