netdev - Re: 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-prev] [day] [month] [year] [list]

Message-ID: <aa94591013f9e656878d318526a5442e@agner.ch>
Date:	Wed, 10 Feb 2016 14:20:23 -0800
From:	Stefan Agner <stefan@...er.ch>
To:	Florian Fainelli <f.fainelli@...il.com>
Cc:	david.choi@...rel.com, netdev@...r.kernel.org
Subject: Re: Micrel PHY and power down mode

On 2016-02-10 14:10, Florian Fainelli wrote:
> 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.

Yes, that seems to be the case. However, since it is clearing the power
down bit, calling resume after reset seems somewhat superfluous. But
maybe there are PHY's out there which require that?

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

By using U-Boot's mii read/write commands I could isolate the problem
and try some possible combinations manually. So far I was not able to
find a sequence of commands which allowed to take the PHY reliably out
of power down.... 

> 
> Getting some insight from somebody at Micrel would definitively help
> with understanding what a workaround or fix would look like.

Ok, thanks, will get in touch with Micrel.

--
Stefan