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: <20170223105958.GC14312@lunn.ch>
Date:   Thu, 23 Feb 2017 11:59:58 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Paolo Minazzi <paolo.minazzi@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: Software loopback with phy 88E1116R and marvell MV78100 gbe

> I tried to do the same things on 88E1116R, setting the but 14 of reg 0.
> But If I do it I lose the link, and the test program does not work.
> I tried to force the link in software, but seems the controller send
> packets but it is not able to receive them.
> Is possibile to do such a software loopback on 88E1116R ?

Hi Paolo

What you are talking about here is MAC loopback. Packets are looped
back at the MAC level. The copper side will be left idle, and so the
link will be lost. This explains why you are seeing link down..

What you might need to do is extend marvell_update_link() to check if
MAC loopback is happening, and if so, say the link is up.

But this is all a bit questionable. How are you setting the PHY into
loopback? I guess the rest of the stack has no idea this is happening,
in particular the phy state machine. What happens when it comes out of
loopback? How is autoneg kicked off.

You might want to think about the big picture, and how this can be
incorporated into ethtool, and phylib. MAC loopback is pretty much
standard, so you should be able to solve this for all PHYs, not just
Marvell.

	     Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ