From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4600FC433E1 for ; Tue, 2 Jun 2020 22:50:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 22A2720734 for ; Tue, 2 Jun 2020 22:50:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="O78nHFvB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730552AbgFBWup (ORCPT ); Tue, 2 Jun 2020 18:50:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730538AbgFBWup (ORCPT ); Tue, 2 Jun 2020 18:50:45 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 874B7C08C5C0; Tue, 2 Jun 2020 15:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XI9cmcvIp+zxYD2LnkDNCdpEuGEtD9ivOfT8pNYkEmQ=; b=O78nHFvB6wFptLGE3yECGhxTh mpSWC35Ev/9JddYutopFnftt5RT8FFLJuZMxhTUs/fhpbLI8+D1j0Ijtuzt/p179IM050ipyOAA1v WIeQzr4Da3cRH8Yb9gOglG00zPShgJQZNidsWb3bbyz0XltfhZMbryV9P12dQDqVp9CTDIUXvvtDv nQMMqk8AvBJjaiiUurLB8tGRUKZyb+9IO7SZa6mAWt1yNE9eNOvoEMeY3YufEuVKHuRTvyMsa5HmN xQHnHCn1mWvMMg307Lywp9XGF0i/pN/Ao2vkTuYMeRekR4bb0M9dQ0Hhq/JQ2gmEXGDWOq55cS/wv 5xcQXcMyQ==; Received: from shell.armlinux.org.uk ([2002:4e20:1eda:1:5054:ff:fe00:4ec]:38106) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgFjh-0003sd-5T; Tue, 02 Jun 2020 23:50:26 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jgFjd-0004lD-60; Tue, 02 Jun 2020 23:50:17 +0100 Date: Tue, 2 Jun 2020 23:50:17 +0100 From: Russell King - ARM Linux admin To: Andrew Lunn Cc: Thomas Bogendoerfer , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net: mvpp2: Enable autoneg bypass for 1000BaseX/2500BaseX ports Message-ID: <20200602225016.GX1551@shell.armlinux.org.uk> References: <20200528151733.f1bc2fcdcb312b19b2919be9@suse.de> <20200528135608.GU1551@shell.armlinux.org.uk> <20200528163335.8f730b5a3ddc8cd9beab367f@suse.de> <20200528144805.GW1551@shell.armlinux.org.uk> <20200528204312.df9089425162a22e89669cf1@suse.de> <20200528220420.GY1551@shell.armlinux.org.uk> <20200529130539.3fe944fed7228e2b061a1e46@suse.de> <20200529145928.GF869823@lunn.ch> <20200529175225.a3be1b4faaa0408e165435ad@suse.de> <20200529163340.GI869823@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200529163340.GI869823@lunn.ch> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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