netdev - Re: [PATCH] Add a driver for Renesas uPD60620 and uPD60620A PHYs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <AM5PR0701MB2657CC23E268601D24CF2B0EE4770@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Date:   Sun, 8 Oct 2017 13:31:50 +0000
From:   Bernd Edlinger <bernd.edlinger@...mail.de>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH] Add a driver for Renesas uPD60620 and uPD60620A PHYs

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.edlinger@...mail.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.