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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180516142401.GA4752@salem.gmr.ssr.upm.es>
Date:   Wed, 16 May 2018 16:24:02 +0200
From:   "Alvaro G. M." <alvaro.gamez@...ent.com>
To:     Andrew Lunn <andrew@...n.ch>
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 03:11:34PM +0200, Andrew Lunn wrote:
> 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.

I didn't know about the SFP device. I don't think this will help my specific
case because my board didn't route the i2c bus from the SFP, so it basically
sits there and does it thing alone, I can't communicate with it.

I see that net/phy/marvell.c has a custom marvell_update_link that reads a
different register to check for fiber connectivity instead of using
genphy_update_link, which I see reads from MII_BMSR.BMSR_LSTATUS

It looks like the DP83620 may do something similar, and the fiber status may
be accesible from some other register. This starts to make sense, thanks for
setting my on track!

Best regards!

-- 
Alvaro G. M.