On Fri, Aug 02, 2024 at 11:47:37AM GMT, Russell King wrote: > From: Serge Semin <fancer.lancer@xxxxxxxxx> > > The HWFEATURE.PCSSEL flag is set if the PCS block has been synthesized > into the DW GMAC controller. It's always done if the controller supports > at least one of the SGMII, TBI, RTBI PHY interfaces. If none of these > interfaces support was activated during the IP-core synthesize the PCS > block won't be activated either and the HWFEATURE.PCSSEL flag won't be > set. Based on that the RGMII in-band status detection procedure > implemented in the driver hasn't been working for the devices with the > RGMII interface support and with none of the SGMII, TBI, RTBI PHY > interfaces available in the device. > > Fix that just by dropping the dma_cap.pcs flag check from the conditional > statement responsible for the In-band/PCS functionality activation. If the > RGMII interface is supported by the device then the in-band link status > detection will be also supported automatically (it's always embedded into > the RGMII RTL code). If the SGMII interface is supported by the device > then the PCS block will be supported too (it's unconditionally synthesized > into the controller). The later is also correct for the TBI/RTBI PHY > interfaces. > > Note while at it drop the netdev_dbg() calls since at the moment of the > stmmac_check_pcs_mode() invocation the network device isn't registered. So > the debug prints will be for the unknown/NULL device. > > Signed-off-by: Serge Semin <fancer.lancer@xxxxxxxxx> > [rmk: fix build errors, only use PCS for SGMII if priv->dma_cap.pcs is set] > Signed-off-by: Russell King (Oracle) <rmk+kernel@xxxxxxxxxxxxxxx> Russell, did you add in the priv->dma_cap.pcs check with SGMII just because it *is* expected to be set unconditionally when SGMII support is there? Always fan of less conditionals, so just curious as to your motivation since Serge's message makes it seem like SGMII && dma_cap.pcs is a redundant check. Otherwise, looks good to me. Thanks, Andrew
