Andrew Lunn wrote:
That is a basic assumption of the code. If you cannot read the IDs how
are you supposed to know what device it is, and what quirks you need
to work around its broken features...
Does the datasheet say anything about this?
I would say for this device, suspend() is too aggressive.
This change in my driver makes the problem go away (I'm not sure if it's
@@ -992,7 +992,7 @@ int emac_mac_up(struct emac_adapter *adpt)
ret = phy_connect_direct(netdev, adpt->phydev, emac_adjust_link,
With the interface not set as SGMII, the following code in
at803x_suspend() is not executed:
/* also power-down SGMII interface */
ccr = phy_read(phydev, AT803X_REG_CHIP_CONFIG);
phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr & ~AT803X_BT_BX_REG_SEL);
phy_write(phydev, MII_BMCR, phy_read(phydev, MII_BMCR) | BMCR_PDOWN);
phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr | AT803X_BT_BX_REG_SEL);
I don't see any other driver issue BMCR_PDOWN in their functions. I
added some printks for the PHYSID1 and PHYSID2 registers before and
at803x_suspend:235 MII_PHYSID1=004d MII_PHYSID2=d074
at803x_suspend:242 MII_PHYSID1=ffff MII_PHYSID2=ffff
So after calling BMCR_PDOWN, the PHYSID1 and PHYSID2 registers are no
longer readable. Is that expected?
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.