Hi Andrew, sorry for delayed reply. Looks like I did not receive a copy of your e-mail.
>> Do you suggest that there are cases where auto negotiation does not >> reach completion, and still provides a usable link status? > > My experience is that it often return 10/half, since everything should > support that. And depending on what the MAC is doing, packets can > sometime get across the link. >> >> I have tried to connect to link partners with fixed configuration >> but even then the auto negotiation always competes normally. > > Which is a bit odd. > > There are a few different possibilities here. The peer PHY driver is > broken. Rather than doing fixed, it actually set the possible > negotiation options to just the one setting you tried to fix it > to. And hence the uPD60620 device negotiated fine. Or the uPD60620 is > broken is said it negotiated, but in fact it failed. > > What was the result? 10/Half, or the fixed values you set the peer to? This is a dual-channel PHY, so I did just connect both ports and played with the mii-tool -F / -A in different combinations on each port and observed what happens when the cable is plugged in. What happens is that the port with autonegotiation enabled detects the correct speed and always half duplex, so the ASIC _pretends_ that autonegotiatiation completes, when in fact only parallel detection succeeded. Of course the other phy may be in full-duplex mode, but that can not be detected by parallel detection. The duplex mode would be full duplex by default, but my initialization overrides a possible strap option and changes that to half duplex: + /* Enable support for passive HUBs (could be a strap option) */ + /* PHYMODE: All speeds, HD in parallel detect */ + return phy_write(phydev, PHY_SPM, 0x0180 | phydev->mdio.addr); >> >> Signed-off-by: Bernd Edlinger <bernd.edlin...@hotmail.de> > > Please send this is a new patch. If we were to take this is is, all > the comments above would end up in the commit message. > > --- > > Under the --- you can however add comments which don't go into the > commit log. Good practice is to list the things you changed since the > previous version. Thanks, I did not know that. I will re-send the patch in a new thread. Bernd.
