From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751133AbeACS1G convert rfc822-to-8bit (ORCPT + 1 other); Wed, 3 Jan 2018 13:27:06 -0500 Received: from mx0a-0016f401.pphosted.com ([67.231.148.174]:51150 "EHLO mx0b-0016f401.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750819AbeACS1E (ORCPT ); Wed, 3 Jan 2018 13:27:04 -0500 From: Stefan Chulski To: Russell King - ARM Linux CC: Marcin Wojtas , Thomas Petazzoni , Andrew Lunn , "Florian Fainelli" , Yan Markman , "Jason Cooper" , netdev , "Antoine Tenart" , "linux-kernel@vger.kernel.org" , "kishon@ti.com" , Nadav Haklai , =?iso-8859-1?Q?Miqu=E8l_Raynal?= , =?iso-8859-1?Q?Gregory_Cl=E9ment?= , "David S. Miller" , "linux-arm-kernel@lists.infradead.org" , Sebastian Hesselbarth Subject: RE: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface Thread-Topic: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface Thread-Index: AQHTf2F55n3e4ALPAEKXWVh4e4VErqNYP5+AgAAm0oCAAFLvgIAAOWqAgAAFUwCAARNcgIAAB20AgAHk6YCAABAVgIACq4KAgAAiZ5CAABHZAIAByDgggAGnuQCAACafgA== Date: Wed, 3 Jan 2018 18:26:27 +0000 Message-ID: <47d9fdb3b11f4f5cbdb58cc85f0d7875@IL-EXCH01.marvell.com> References: <20171228182739.GH2626@kwain> <20171228184642.GV10595@n2100.armlinux.org.uk> <20171229113850.GX10595@n2100.armlinux.org.uk> <20171230173157.GC10595@n2100.armlinux.org.uk> <616c2f3b0fe64184bc26d2de43442540@IL-EXCH01.marvell.com> <20180101132520.GB28752@n2100.armlinux.org.uk> <0e95e9b20e2d42bc95e04034bd88e781@IL-EXCH01.marvell.com> <20180103175446.GI28752@n2100.armlinux.org.uk> In-Reply-To: <20180103175446.GI28752@n2100.armlinux.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.5.102.207] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-03_12:,, signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801030251 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: > Sorry, I find this very confusing. > > It seems we have some people telling me that when there's no PHY described > in DT, we use this link interrupt, and have a functional network interface > (presumably at whatever speed.) I give you couple of examples when we have functional network interface with link interrupt: 1) 10G XLG mode without PHY - since XLG doesn't have auto negation mechanism 2) SGMII with in-band auto negation 3) RGMII with auto negation done previously by boot loader or by change default fixed speed same as speed on cable. Of course correct way to do it in RGMII mode is use values provided by phylink/phylib. Stefan. > > I can't see this working from what you describe - what you describe basically > tells me that when in-band autonegotiation is disabled, and we have no PHY in > the kernel, then effectively we are in fixed-link mode - since we need to know > what speed, duplex and flow control settings to use. > > So, this means that mvpp2 should be enforcing the presence of a fixed-link > description in DT if there is no PHY node at the moment, but it doesn't. > > Instead, it looks to me like the speed and duplex settings are inherited from the > boot loader or whatever was running before - I can't find anything that > configures MVPP2_GMAC_AUTONEG_CONFIG in this case. That seems quite a > mess. > > Maybe I'm missing something, but I don't see how mvpp2 can be converted to > phylink given this without causing some kind of regression, unless someone can > be much clearer about exactly what kinds of link mvpp2 supports and how they > work (which is basically what I asked back in > October.) > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up > According to speedtest.net: 8.21Mbps down 510kbps up From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Chulski Subject: RE: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface Date: Wed, 3 Jan 2018 18:26:27 +0000 Message-ID: <47d9fdb3b11f4f5cbdb58cc85f0d7875@IL-EXCH01.marvell.com> References: <20171228182739.GH2626@kwain> <20171228184642.GV10595@n2100.armlinux.org.uk> <20171229113850.GX10595@n2100.armlinux.org.uk> <20171230173157.GC10595@n2100.armlinux.org.uk> <616c2f3b0fe64184bc26d2de43442540@IL-EXCH01.marvell.com> <20180101132520.GB28752@n2100.armlinux.org.uk> <0e95e9b20e2d42bc95e04034bd88e781@IL-EXCH01.marvell.com> <20180103175446.GI28752@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Thomas Petazzoni , Andrew Lunn , Florian Fainelli , Yan Markman , Jason Cooper , netdev , Antoine Tenart , "linux-kernel@vger.kernel.org" , "kishon@ti.com" , Nadav Haklai , =?iso-8859-1?Q?Miqu=E8l_Raynal?= , =?iso-8859-1?Q?Gregory_Cl=E9ment?= , Marcin Wojtas , "David S. Miller" , "linux-arm-kernel@lists.infradead.org" , Sebastian Hesselbarth To: Russell King - ARM Linux Return-path: In-Reply-To: <20180103175446.GI28752@n2100.armlinux.org.uk> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org List-Id: netdev.vger.kernel.org > Sorry, I find this very confusing. > > It seems we have some people telling me that when there's no PHY described > in DT, we use this link interrupt, and have a functional network interface > (presumably at whatever speed.) I give you couple of examples when we have functional network interface with link interrupt: 1) 10G XLG mode without PHY - since XLG doesn't have auto negation mechanism 2) SGMII with in-band auto negation 3) RGMII with auto negation done previously by boot loader or by change default fixed speed same as speed on cable. Of course correct way to do it in RGMII mode is use values provided by phylink/phylib. Stefan. > > I can't see this working from what you describe - what you describe basically > tells me that when in-band autonegotiation is disabled, and we have no PHY in > the kernel, then effectively we are in fixed-link mode - since we need to know > what speed, duplex and flow control settings to use. > > So, this means that mvpp2 should be enforcing the presence of a fixed-link > description in DT if there is no PHY node at the moment, but it doesn't. > > Instead, it looks to me like the speed and duplex settings are inherited from the > boot loader or whatever was running before - I can't find anything that > configures MVPP2_GMAC_AUTONEG_CONFIG in this case. That seems quite a > mess. > > Maybe I'm missing something, but I don't see how mvpp2 can be converted to > phylink given this without causing some kind of regression, unless someone can > be much clearer about exactly what kinds of link mvpp2 supports and how they > work (which is basically what I asked back in > October.) > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up > According to speedtest.net: 8.21Mbps down 510kbps up From mboxrd@z Thu Jan 1 00:00:00 1970 From: stefanc@marvell.com (Stefan Chulski) Date: Wed, 3 Jan 2018 18:26:27 +0000 Subject: [EXT] Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface In-Reply-To: <20180103175446.GI28752@n2100.armlinux.org.uk> References: <20171228182739.GH2626@kwain> <20171228184642.GV10595@n2100.armlinux.org.uk> <20171229113850.GX10595@n2100.armlinux.org.uk> <20171230173157.GC10595@n2100.armlinux.org.uk> <616c2f3b0fe64184bc26d2de43442540@IL-EXCH01.marvell.com> <20180101132520.GB28752@n2100.armlinux.org.uk> <0e95e9b20e2d42bc95e04034bd88e781@IL-EXCH01.marvell.com> <20180103175446.GI28752@n2100.armlinux.org.uk> Message-ID: <47d9fdb3b11f4f5cbdb58cc85f0d7875@IL-EXCH01.marvell.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > Sorry, I find this very confusing. > > It seems we have some people telling me that when there's no PHY described > in DT, we use this link interrupt, and have a functional network interface > (presumably at whatever speed.) I give you couple of examples when we have functional network interface with link interrupt: 1) 10G XLG mode without PHY - since XLG doesn't have auto negation mechanism 2) SGMII with in-band auto negation 3) RGMII with auto negation done previously by boot loader or by change default fixed speed same as speed on cable. Of course correct way to do it in RGMII mode is use values provided by phylink/phylib. Stefan. > > I can't see this working from what you describe - what you describe basically > tells me that when in-band autonegotiation is disabled, and we have no PHY in > the kernel, then effectively we are in fixed-link mode - since we need to know > what speed, duplex and flow control settings to use. > > So, this means that mvpp2 should be enforcing the presence of a fixed-link > description in DT if there is no PHY node at the moment, but it doesn't. > > Instead, it looks to me like the speed and duplex settings are inherited from the > boot loader or whatever was running before - I can't find anything that > configures MVPP2_GMAC_AUTONEG_CONFIG in this case. That seems quite a > mess. > > Maybe I'm missing something, but I don't see how mvpp2 can be converted to > phylink given this without causing some kind of regression, unless someone can > be much clearer about exactly what kinds of link mvpp2 supports and how they > work (which is basically what I asked back in > October.) > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up > According to speedtest.net: 8.21Mbps down 510kbps up