Fwd: Micrel KSZ9031RN PHY problem

[Guillermo Rodriguez Garcia]

2016-04-26 11:55 GMT+02:00 Guillermo Rodriguez Garcia
<guille.rodriguez at gmail.com>:
> Hello,
>
> 2016-04-21 9:32 GMT+02:00 Sascha Hauer <s.hauer at pengutronix.de>:
>> On Wed, Apr 20, 2016 at 05:58:40PM +0200, Guillermo Rodriguez Garcia wrote:
>>> Hello,
>>>
>>> 2016-04-19 9:11 GMT+02:00 Sascha Hauer <s.hauer at pengutronix.de>:
>>> > Hi Guillermo,
>>> >
>>> > +Cc Philipp Zabel who ported the patch to barebox
>>> >
>>> > On Mon, Apr 18, 2016 at 04:49:47PM +0200, Guillermo Rodriguez Garcia wrote:
>>> >> Hello all,
>>> >>
>>> >> I am playing with barebox on an Atmel SAMA5D3 Xplained board. It is
>>> >> now working fine for the most part, however after updating to the
>>> >> latest sources from git I found a problem that I had not seen before.
>>> >>
>>> >> This board has two Ethernet interfaces; eth0 uses a Micrel KSZ9031RN
>>> >> PHY, and eth1 uses a Micrel KSZ8081RNB PHY.
>>> >>
>>> >> It seems that after release 2016.03.0, eth0 does not work anymore with
>>> >> some routers. Specifically I found this problem with a Comtrend
>>> >> VG-8050. I have tested other routers and the problem was not present
>>> >> there.
>>> >>
>>> >> After some research it seems that the problem is caused by this
>>> >> commit: http://git.pengutronix.de/?p=barebox.git;a=commit;h=da89ee8f2e04e116410632a185024f58b8262d87
>>> >>
>>> >> Before this commit eth0 was working fine. After this commit, the link
>>> >> cannot established anymore:
>>> >>
>>> >> [...]
>>> >> barebox:/# ping 192.168.0.128
>>> >> ping failed: Network is down
>>> >>
>>> >> Before diving further into this I thought it could be a good idea to
>>> >> ask, in case someone can shed some light here.
>>> >
>>> > I have no idea what the issue is here. We might have to make this option
>>> > configurable via devicetree to give boards different options. Since the
>>> > patch comes from the Linux Kernel, do you have the same problems under
>>> > Linux?
>>>
>>> I'm trying to get the latest kernel to boot. The latest version
>>> supported by Atmel is 4.1, which doesn't have the patch yet. Will
>>> report back asap.
>>
>> Thanks. We can revert this patch since Philipp only ported it to stay in
>> sync with the kernel. Anyway, if it makes problems we'll probably need a
>> solution for the kernel aswell.
>
> More info on this after researching the issue.
>
> Looks like problem is not directly caused by the modified FLP timings,
> but is revealed by that change.
>
> Immediately after setting the FLP timings, the autonegotiation is
> restarted by calling genphy_restart_aneg(phydev).
> Within genphy_restart_aneg, the following line:

This line is actually in genphy_config_advert, sorry for the noise.

Guillermo

>
>     oldadv = adv = phy_read(phydev, MII_ADVERTISE);
>
> returns 0xffff, and negotiation fails.
>
> It seems to be a timing problem. Any minimal delay _before_ that
> phy_read (1ms) is enough to make it work -- phy_read returns 481
> instead of 0xffff, and the negotiation completes. The same delay right
> after phy_read does not solve the problem.
>
> This happens even if I modify ksz9031_center_flp_timing() so that it
> does NOT touch the FLP timings. So as I said it is not directly
> related to the actual FLP timing values, but rather to some timing
> issue related to the negotiation itself. It just happens that the
> center_flp_timing function does restart the autonegotiation, and thus
> reveals the problem.
>
> Is it OK to add this 1ms delay in genphy_restart_aneg?
>
> Best,
>
> Guillermo Rodriguez Garcia
> guille.rodriguez at gmail.com