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:   Tue, 2 Jun 2020 23:50:17 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
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 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.

I have mvneta using it, and partially tested on the SolidRun Clearfog
platform; for testing, I've stripped out everything for the SFP and
replaced it with a fixed link - that way, I can control whether the
serdes is in sync or not. It isn't mainline quality as I need to work
out how to properly handle the MVNETA_INTR_MISC_MASK which looks to me
like it's needlessly written in multiple places in the driver.

I have a partial implementation on mvpp2, but not complete yet, that
is to come - it will need mvpp2 converted to the new phylink pcs_ops
which has yet to happen, and may take a bit of time to sort.

So, some progress towards a solution, but not to the point where I'd
be happy to post some patches just yet.

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?

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

3) re-enabling AN bypass for mvpp2 would create inconsistencies
   between different drivers for similar hardware from the same
   manufacturer, so should we propagate the "fix" to them as
   well (e.g. mvneta.)

4) what about when we have a proper solution to this, what do we
   then do with mvpp2 if we decide to change it's behaviour, and
   do we then recommend that Thomas switches to using this (I
   suppose so, otherwise there's not much point me developing a
   solution to this problem.)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up