netdev - Re: [PATCH net] net: mvpp2: Enable autoneg bypass for 1000BaseX/2500BaseX ports

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:   Wed, 3 Jun 2020 15:21:47 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Thomas Bogendoerfer <tbogendoerfer@...e.de>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net: mvpp2: Enable autoneg bypass for
 1000BaseX/2500BaseX ports

On Tue, Jun 02, 2020 at 11:50:17PM +0100, Russell King - ARM Linux admin wrote:
> On Fri, May 29, 2020 at 06:33:40PM +0200, Andrew Lunn wrote:
> > Given the current code, you cannot. Now we understand the
> > requirements, we can come up with some ideas how to do this properly.
> 
> Okay, I've been a little quiet because of sorting out the ARM tree
> for merging with Linus (now done) and I've been working on a solution
> to this problem.
> 
> The good news is, I have an implementation in phylink to use the sync
> status reported from a PCS, and to appropriately enable sync status
> reporting.  I'm quite nervous about having that enabled as a matter of
> routine as I've seen some Marvell hardware end up with interrupt storms
> from it - presumably due to noise pickup on the serdes lines being
> interpreted as an intermittently valid signal.

Hi Russell

I have seen similar with an SFP without link. I think squelch is
optional, so noise gets passed through, which is enough to get and
loose sync.

I think we probably need to only enable the interrupt when the LOS
signal indicates there is at least some power coming into the SFP.

> However, I think we need to think about:
> 1) how we classify Thomas' problem - does it count as a regression
>    given that support for his platform is not part of mainline, and
>    the use of in-band-status in his unreviewed DT is clearly incorrect?

I would say no, it is not a regression.

> 2) if we deem it to be a regression, then how do we intend to solve
>    this for stable kernels?

I think this new code should go into net-next, when it opens. I
suspect it is going to be a big change, once we consider LOS.

	Andrew