The changeset that causes my problems is ee62ed32
The original code calls init_phy(dev) followed by phy_change(dev) *once* during PHY initialization. The part of changeset that appears to cause my problems is calling phy_change(dev) every time uec_init() is called.
On my mpc8360emds board, without this change the second command that does a network operation hangs the board (requires a hard reset to recover). Example failure sequence is two "ping" commands: the first works, the second hangs the board.
This also speeds up the network initialization and doesn't cause a packet error on the first TFTP packet.
Signed-off-by: Gerald Van Baren vanbaren@cideas.com ---
Kim:
Does this make any sense? Any thoughts why it isn't causing problems for you? It makes all the difference in the world for me.
One other interesting sequence difference with patch ee62ed32 is that the ethernet MAC address is set on every uec_init() call. The following code was inside the "if (uec->the_first_run == 0)" conditional, now it is outside the conditional and thus run on every uec_init() call. Functionally, it doesn't seem to matter for me either way, but seems unnecessary.
+ /* Set up the MAC address */ + if (dev->enetaddr[0] & 0x01) { + printf("%s: MacAddress is multcast address\n", + __FUNCTION__); + return -1; + } + uec_set_mac_address(uec, dev->enetaddr);
Best regards, gvb
P.S. What's the Guiness World Book record for number of words written to explain moving two lines of code?
drivers/qe/uec.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c index 55f37cb..d447d96 100644 --- a/drivers/qe/uec.c +++ b/drivers/qe/uec.c @@ -1163,6 +1163,8 @@ static int uec_init(struct eth_device* dev, bd_t *bd) return err; }
+ phy_change(dev); + curphy = uec->mii_info->phyinfo;
if (curphy->config_aneg) { @@ -1201,8 +1203,6 @@ static int uec_init(struct eth_device* dev, bd_t *bd) return -1; }
- phy_change(dev); - return (uec->mii_info->link ? 0 : -1); }