Fwd: Micrel KSZ9031RN PHY problem

[Sascha Hauer]

On Tue, Apr 26, 2016 at 11:55:29AM +0200, Guillermo Rodriguez Garcia wrote:
> 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:
> 
>     oldadv = adv = phy_read(phydev, MII_ADVERTISE);
> 
> returns 0xffff, and negotiation fails.

The code you are referring to seems to be the first phy access after the
network device opens. Maybe the hardware is not yet ready for some
reason. Could you add the same delay in macb_open() right before the
call to phy_device_connect()?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |