Hi Stefan, On 10/02/16 11:25, Stefan Agner wrote: > Hi David, Hi Florian, > > We use a Micrel KSZ8041NL and we observe sometimes continuous RX errors > (PHY's RXER counter is continuously incrementing, activity LED blinks > and no communication is possible). It seems that only some PHY's are > affected (3-4%) and only in certain temperature ranges (the PHY I can > reproduce the issue here shows the problem ~30°C). We could narrow the > issue down, and realized that the problem only appears after the PHY has > been in power down mode. Since Linux calls suspend/resume when > attaching/detaching the PHY, a simple ifup/ifdown bascially can trigger > the issue. > > Currently, the wakeup sequence writes the following registers > 0x8000 to 0x00 (phy_attach_direct -> phy_init_hw -> genphy_soft_reset) > 0x3000 to 0x00 (phy_attach_direct -> genphy_resume) > > I am not sure if this sequence is really ok. It seems to me that > genphy_soft_reset clears the power down bit already, which makes > genphy_resume somewhat useless. However, altering the behavior of > genphy_soft_reset to not clear the power down bit (yet) did not resolve > the issue.
AFAIR, issuing a BMCR reset, with a PHY which was in power down should clear the power down bit, but I would not be surprised if some PHYs were not quite behaving like that though. > > Is clearing the power down bit and generating the reset in one go > intended? I checked the datasheet, and did not found particular > information about the "resume" sequence... Does it help if your PHY resume callback does the same thing as what the config_init() does? You have the ability to skip the generic software reset of the PHY via BMCR bit 15, and instead do nothing by implementing your own soft_reset() callback, that might tell you whether the software reset is what is screwing things up? Getting some insight from somebody at Micrel would definitively help with understanding what a workaround or fix would look like. HTH -- Florian
