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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
