Re: Fwd: Micrel KSZ9031RN PHY problem

[Trent Piepho <tpiepho@kymetacorp.com>]

On Thu, 2016-04-28 at 11:51 +0200, Guillermo Rodriguez Garcia wrote:
> >
> > 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()?
> 
> Tried this, but doesn't help. Here's the call sequence, for example
> when you run 'dhcp' from the command line prompt:
> 
> macb_open
> phy_device_connect
> phy_device_attach
> phy_init_hw
> ksz9031_config_init
> ksz9031_center_flp_timing
> genphy_restart_aneg
> genphy_config_advert -> fails (adv = 0xffff)
> 
> I can verify that:
> - Any delay happening before the call to genphy_restart_aneg (which
> itself is called at the end of ksz9031_center_flp_timing) does not fix
> the problem.
> - Any delay happening after the phy_read(phydev, MII_ADVERTISE) insde
> genphy_config_advert does not fix the problem.
> - A delay of 1ms at any point after genphy_restart_aneg and before the
> phy_read call in genphy_config_advert fixes the problem

So the same problem appears if you take out the FLP call out entirely,
if there is an aneg restart done immediately before trying to read from
MII_ADVERTISE?

Does only MII_ADVERTISE fail to read, or does reading any PHY register
fail?  Specifically, does reading MII_BMSR fail?

Reading PHY register after restarting aneg isn't unusual.  Especially
polling MII_BMSR to check for BMSR_ANEGCOMPLETE.  It would be odd if one
couldn't do that.

The first anreg start call will also un-powerdown the PHY if BMCR_PDOWN
was set.  I wonder if that is happening?
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox