On 12/15/2019 1:53 PM, Vladimir Oltean wrote:
Hi Alex,
On Tue, 3 Dec 2019 at 18:18, Alex Marginean alexandru.marginean@nxp.com wrote:
+static int felix_port_enable(struct udevice *dev, int port,
struct phy_device *phy)+{
struct felix_priv *priv = dev_get_priv(dev);void *base = priv->regs_base;out_le32(base + FELIX_GMII_MAC_ENA_CFG(port),FELIX_GMII_MAX_ENA_CFG_TX | FELIX_GMII_MAX_ENA_CFG_RX);out_le32(base + FELIX_QSYS_SYSTEM_SW_PORT_MODE(port),FELIX_QSYS_SYSTEM_SW_PORT_ENA |FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));if (phy)phy_startup(phy);return 0;+}
+static void felix_port_disable(struct udevice *dev, int port,
struct phy_device *phy)+{
struct felix_priv *priv = dev_get_priv(dev);void *base = priv->regs_base;out_le32(base + FELIX_GMII_MAC_ENA_CFG(port), 0);out_le32(base + FELIX_QSYS_SYSTEM_SW_PORT_MODE(port),FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));/** we don't call phy_shutdown here to avoind waiting next time we use* the port, but the downside is that remote side will think we're* actively processing traffic although we are not.*/+}
2.17.1
What is the correct general procedure here, is it to call phy_startup so late (felix_port_enable)? I'm trying to take this driver as an example for sja1105, which has RGMII so PCS and no autonomous in-band AN like felix does. On this switch, it is too late to do phy_startup now.
Why is it too late? Is it a functional problem, or you're looking to reduce the waiting time?
Instead, I would need to look at phy->speed which should have been settled by now, and reprogram my MAC with it. My question is: don't you think phy_startup() and phy_shutdown() belong in the DSA uclass code?
Thanks, -Vladimir
The API is similar to the one in Linux, plus I didn't want to force a specific PHY related behavior to drivers. Sometimes it's fine to start up the PHYs at probe and then just send/receive as needed, but that behavior is not always acceptable. Assume there is some other host connected to one of the front panel ports, if it sees link up it may start doing DHCP, IPv6 discovery. I think it's generally better to keep links down unless the port is actually in use for the benefit of the remote end. I didn't want to force this by moving the PHY calls to uclass code. This approach is also similar to eth uclass, it doesn't handle phy calls for the driver either.
Alex