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:   Tue, 13 Apr 2021 10:23:48 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Ivan Bornyakov <i.bornyakov@...rotek.ru>
Cc:     Andrew Lunn <andrew@...n.ch>, system@...rotek.ru,
        hkallweit1@...il.com, davem@...emloft.net, kuba@...nel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] net: phy: marvell-88x2222: check that link
 is operational

On Tue, Apr 13, 2021 at 10:19:30AM +0300, Ivan Bornyakov wrote:
> On Tue, Apr 13, 2021 at 01:40:32AM +0200, Andrew Lunn wrote:
> > On Mon, Apr 12, 2021 at 03:16:59PM +0300, Ivan Bornyakov wrote:
> > > Some SFP modules uses RX_LOS for link indication. In such cases link
> > > will be always up, even without cable connected. RX_LOS changes will
> > > trigger link_up()/link_down() upstream operations. Thus, check that SFP
> > > link is operational before actual read link status.
> > 
> > Sorry, but this is not making much sense to me.
> > 
> > LOS just indicates some sort of light is coming into the device. You
> > have no idea what sort of light. The transceiver might be able to
> > decode that light and get sync, it might not. It is important that
> > mv2222_read_status() returns the line side status. Has it been able to
> > achieve sync? That should be independent of LOS. Or are you saying the
> > transceiver is reporting sync, despite no light coming in?
> > 
> > 	Andrew
> 
> Yes, with some SFP modules transceiver is reporting sync despite no
> light coming in. So, the idea is to check that link is somewhat
> operational before determing line-side status. 

Indeed - it should be a logical and operation - there is light present
_and_ the PHY recognises the signal. This is what the commit achieves,
although (iirc) doesn't cater for the case where there is no SFP cage
attached.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ