Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 29 May 2020 18:02:32 +0100
From:   Russell King - ARM Linux admin <linux@armlinux.org.uk>
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     Thomas Bogendoerfer <tbogendoerfer@suse.de>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net: mvpp2: Enable autoneg bypass for
 1000BaseX/2500BaseX ports
Message-ID: <20200529170231.GB1551@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>
 <20200529155121.GA1551@shell.armlinux.org.uk>
 <20200529162504.GH869823@lunn.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200529162504.GH869823@lunn.ch>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, May 29, 2020 at 06:25:04PM +0200, Andrew Lunn wrote:
> > I wonder how much risk there is to changing that, so we force the link
> > down if phylink says the link should be down, otherwise we force the
> > speed/duplex, disable AN, and allow the link to come up depending on
> > the serdes status.  It /sounds/ like something sane to do.
> 
> Hi Russell
> 
> I actually did this for mv88e6xxx in a patchset for ZII devel B. It
> was determining link based on SFP LOS, which we know is unreliable. It
> said there was link even when the SERDES had lost link.
> 
> I did it by making use of the fixed-link state call back, since it was
> a quick and dirty patch. But it might make more sense for the MAC to
> call phylink_mac_change() for change in PCS state? Or add a PCS
> specific.

Correct.  In the early phylink versions, I did have sync state reported
from the PCS back to phylink, but as phylink didn't make use of it, I
removed it as it wasn't obvious how it should be used.

-- 
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