netdev - Re: Xilinx axienet + DP83620 in fiber mode won't set netif_carrier

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180516131134.GF22000@lunn.ch>
Date:   Wed, 16 May 2018 15:11:34 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Alvaro G. M." <alvaro.gamez@...ent.com>
Cc:     netdev@...r.kernel.org
Subject: Re: Xilinx axienet + DP83620 in fiber mode won't set netif_carrier_on

On Wed, May 16, 2018 at 11:16:31AM +0200, Alvaro G. M. wrote:
> Hi,
> 
> I have a custom board with a Xilinx FPGA running Microblaze and fitting a
> Xilinx Axi Ethernet IP core.  This core communicates through MII mode with a
> DP83620 PHY from Texas that supports both cabled and fiber interfaces, of
> which I'm using the latter.
> 
> Under these circumstances, I've noticed that the interface is pretty much
> dead except for receiving broadcast packages, so I tried to dig on the
> driver to find the cause. Please, beware that I'm not very familiar with the
> netdev subsystem, so I may be mistaken on lots of things.
> 
> It seems that of_phy_connect ends up calling netif_carrier_off:
> 
> phy_device.c:1036
> 	/* Initial carrier state is off as the phy is about to be
> 	 * (re)initialized.
> 	 */
> 	netif_carrier_off(phydev->attached_dev);
> 
> 	/* Do initial configuration here, now that
> 	 * we have certain key parameters
> 	 * (dev_flags and interface)
> 	 */
> 	err = phy_init_hw(phydev);
> 	if (err)
> 		goto error;
> 
> 	phy_resume(phydev);
> 
> However, neither xilinx_axienet_main.c nor dp83848.c ever runs
> netif_carrier_on.

Hi Alvaro

What should happen in general terms is that at some point the link to
the peer is established. phylib, the generic PHY code, polls the PHY
ever second, asking what the link state is. When the link changes from
down to up, phylib will call the link_adjust callback in the MAC, and
netif_carrier_on().

When the PHY reports the link has gone down, it does similar, calls
the adjust_link callback, and netif_carrier_off().

So what you need to do is find out why the PHY driver never reports
link up. Does the PHY even know when the link is up? Often SFF/SFP
modules have a Signal Detect pin, which is connected to a gpio. Do you
have something like that? If so, you should look at the PHYLINK code
and the SFP device which was added recently.

    Andrew