netdev - Micrel PHY and power down mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 10 Feb 2016 11:25:46 -0800
From:	Stefan Agner <stefan@...er.ch>
To:	david.choi@...rel.com, f.fainelli@...il.com
Cc:	netdev@...r.kernel.org
Subject: Micrel PHY and power down mode

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.

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... 

--
Stefan