From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [RFC PATCH] net: mvpp2: fix detection of 10G SFP modules Date: Tue, 4 Dec 2018 10:27:01 +0000 Message-ID: <20181204102701.GO30658@n2100.armlinux.org.uk> References: <2c150415f8a820aed0f113e0884417bc977577d3.1543495790.git.baruch@tkos.co.il> <20181129220043.GB30658@n2100.armlinux.org.uk> <20181204101954.mphe2eezdie75bgd@sapphire.tkos.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Antoine Tenart , Florian Fainelli , netdev@vger.kernel.org, Maxime Chevallier To: Baruch Siach Return-path: Received: from pandora.armlinux.org.uk ([78.32.30.218]:33250 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725613AbeLDK1R (ORCPT ); Tue, 4 Dec 2018 05:27:17 -0500 Content-Disposition: inline In-Reply-To: <20181204101954.mphe2eezdie75bgd@sapphire.tkos.co.il> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Dec 04, 2018 at 12:19:54PM +0200, Baruch Siach wrote: > Hi Russell, > > On Thu, Nov 29, 2018 at 10:00:43PM +0000, Russell King - ARM Linux wrote: > > On Thu, Nov 29, 2018 at 11:31:23AM -0800, Florian Fainelli wrote: > > > On 11/29/2018 4:49 AM, Baruch Siach wrote: > > > > The mvpp2_phylink_validate() relies on the interface field of > > > > phylink_link_state to determine valid link modes. However, when called > > > > from phylink_sfp_module_insert() this field in not initialized. The > > > > default switch case then excludes 10G link modes. This allows 10G SFP > > > > modules that are detected correctly to be configured at max rate of > > > > 2.5G. > > > > > > > > Catch the uninitialized PHY mode case, and allow 10G rates. > > > > > > > > Cc: Maxime Chevallier > > > > Cc: Antoine Tenart > > > > Signed-off-by: Baruch Siach > > > > --- > > > > Is that the right fix? > > > > > > It would be a bit surprising that this is the right fix, you would > > > expect validate to be called once everything has been parsed > > > successfully from the SFP, is not that the case here? If not, can you > > > find out what happens? > > > > Two calls are made - the first with PHY_INTERFACE_MODE_NA to > > determine what the advertising link mode may be, and then again > > once the interface mode has been selected from the advertising mask. > > > > Why? > > > > Consider a 4.3Mbps fiberchannel SFP plugged into a 1G-only MAC. > > If we did it as a single pass, we would end up passing an > > interface mode of 2500BASEX first time around which is illogical. > > So you consider this to be the right fix, right? Yes, but there is another bug lurking here - the handling of invalid interface modes is not correct. Please see mvneta.c as an example - interface modes that are not supported by the MAC (apart from the NA mode) end up with the supported mask completely cleared. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up