netdev - Re: Software loopback with phy 88E1116R and marvell MV78100 gbe

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]

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