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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17EC3C43334 for ; Sat, 2 Jul 2022 20:27:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229891AbiGBU1m (ORCPT ); Sat, 2 Jul 2022 16:27:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229436AbiGBU1k (ORCPT ); Sat, 2 Jul 2022 16:27:40 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D2FFBC0C for ; Sat, 2 Jul 2022 13:27:37 -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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To: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=WWRpsl5ggL/SCJkSQDZVOouYeoKfRcbKaFLWJ7eZmeM=; b=G0YYxPX+RBUvgZDPW64RQO0MAl yUOL7+KruWwkIkhhqd16BunpjaFwYSqhToh6EQotU39rRP/5IIU0kQZbtxf0k5+K6HlxNnm2GP4zp I2/vhTawk/OUyDk/TqA1bGPYjTMgrqiGXAuIAE9vz2O0pHm2FIPa6xn8NREaT7lyB8VtEbRyGT6OP 1VxsAuHQARL26Kfjv2bc242sLpLqsTN0e4wt16A/6MwheHDlz0NRKnlDC0wf1Nxfe5gDW77jybqXr TDilDkrBpwFGyhyS+Dn8ZDRVTod2t3Nol9f9PZSdkbTphOW2KWrhXXxrKct4SgFas9eLZuxrEsZhU ajTzTnJQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:33142) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o7jhs-0006zt-Dq; Sat, 02 Jul 2022 21:27:08 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1o7jhk-0000X2-7R; Sat, 02 Jul 2022 21:27:00 +0100 Date: Sat, 2 Jul 2022 21:27:00 +0100 From: "Russell King (Oracle)" To: Marek =?iso-8859-1?Q?Beh=FAn?= Cc: Andrew Lunn , Heiner Kallweit , Alexandre Belloni , Alvin __ipraga , Claudiu Manoil , "David S. Miller" , DENG Qingfang , Eric Dumazet , Florian Fainelli , George McCollister , Hauke Mehrtens , Jakub Kicinski , Kurt Kanzenbach , Landen Chao , Linus Walleij , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Matthias Brugger , netdev@vger.kernel.org, Paolo Abeni , Sean Wang , UNGLinuxDriver@microchip.com, Vivien Didelot , Vladimir Oltean , Woojung Huh Subject: Re: [PATCH RFC net-next 5/6] net: dsa: always use phylink for CPU and DSA ports Message-ID: References: <20220701213435.53ecdd70@thinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220701213435.53ecdd70@thinkpad> Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jul 01, 2022 at 09:34:35PM +0200, Marek Behún wrote: > On Wed, 29 Jun 2022 13:51:43 +0100 > "Russell King (Oracle)" wrote: > > > Currently, we only use phylink for CPU and DSA ports if there is a > > fixed-link specification, or a PHY specified. The reason for this > > behaviour is that when neither is specified, there was no way for > > phylink to know the link parameters. > > > > Now that we have phylink_set_max_link_speed() (which has become > > possible through the addition of mac_capabilities) we now have the > > ability to know the maximum link speed for a specific link, and can > > now use phylink for this case as well. > > > > However, we need DSA drivers to report the interface mode being used > > on these ports so that we can select a maximum speed appropriate for > > the interface mode that hardware may have configured for the port. > > > > This is especially important with the conversion of DSA drivers to > > phylink_pcs, as the PCS code only gets called if we are using > > phylink for the port. > > > > Signed-off-by: Russell King (Oracle) > > Reviewed-by: Marek Behún > > So this is the one that may break other drivers? It's the one that I'm most concerned about breakage happening, because the other drivers won't be setting the default interface for the port, which means if they're taking advantage of this "defaulting" feature, this patch will break them. The original code just did nothing when this "defaulting" feature was used - it didn't call the DSA phylink_mac_link_down() op, and didn't register with phylink. The phylink_mac_link_down() there was to ensure that the ports are in a link-down state prior to setting up phylink, because that's what phylink expects. The problem comes is that once we've called phylink_mac_link_down(), there isn't a way to back out of that without knowing the interface mode, speed, duplex etc - which is the problem with this defaulting feature, none of that is specified in DT, it can only come from the drivers. Note that the mv88e6xxx series I posted earlier depends on getting this problem sorted - if we don't, I can't send the mv88e6xxx pcs conversion because mv88e6xxx boards that _do_ make use of this defaulting feature will break (and there are a number that do make use of it.) If I send this RFC series (minus the top patch) then all the drivers that make use of this defualting feature that aren't mv88e6xxx will probably break - but I've no idea which make use of this feature because it's not documented. It's not really documented in the DT binding either, it's just something that Andrew "knows about", mv88e6xxx makes use of, and Andrew has suggested to some other DSA driver authors. This absolutely needs Andrew's involvement. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0E30AC433EF for ; Sat, 2 Jul 2022 20:29:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3iVHgmHLyYTemtFlHa6wKZQgd/9vqnLb/sl40u7sJqo=; b=FTo/BS7VBbpfv9 SnW3Ef7cKeBtf/bmFq5Egibzvc7O2sl8TwzFi8DCWefBUfCkSIpPTdlT2qrK/YHgh45LPO/29esbt B5M9uGSvj+Dl5bJeUAhFinKplP+N8ITUwMdb2ZxfPqC/jgAvJ7Oj5vLNrz9BZ0ntoo403QqUN4BqM WTSZx9repwfrqks7JPfsGQR1a9nJj5tOuHsCoLmaNzTLpW+deOZH8g3BaV47G3SQp2F4AK601YPGO LUrkaGsJCELFw3SGyKvbj5Yelq7xUDW9FEBY+0d3qJWYcDZF35IY0SUiJ5W/72ILSsJfkIzminGUf S1oNUGHpRe6RBq0CFwsA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o7jiO-00BMDU-JV; Sat, 02 Jul 2022 20:27:40 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o7jiJ-00BMA5-8m; Sat, 02 Jul 2022 20:27:38 +0000 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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To: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=WWRpsl5ggL/SCJkSQDZVOouYeoKfRcbKaFLWJ7eZmeM=; b=G0YYxPX+RBUvgZDPW64RQO0MAl yUOL7+KruWwkIkhhqd16BunpjaFwYSqhToh6EQotU39rRP/5IIU0kQZbtxf0k5+K6HlxNnm2GP4zp I2/vhTawk/OUyDk/TqA1bGPYjTMgrqiGXAuIAE9vz2O0pHm2FIPa6xn8NREaT7lyB8VtEbRyGT6OP 1VxsAuHQARL26Kfjv2bc242sLpLqsTN0e4wt16A/6MwheHDlz0NRKnlDC0wf1Nxfe5gDW77jybqXr TDilDkrBpwFGyhyS+Dn8ZDRVTod2t3Nol9f9PZSdkbTphOW2KWrhXXxrKct4SgFas9eLZuxrEsZhU ajTzTnJQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:33142) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o7jhs-0006zt-Dq; Sat, 02 Jul 2022 21:27:08 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1o7jhk-0000X2-7R; Sat, 02 Jul 2022 21:27:00 +0100 Date: Sat, 2 Jul 2022 21:27:00 +0100 From: "Russell King (Oracle)" To: Marek =?iso-8859-1?Q?Beh=FAn?= Cc: Andrew Lunn , Heiner Kallweit , Alexandre Belloni , Alvin __ipraga , Claudiu Manoil , "David S. Miller" , DENG Qingfang , Eric Dumazet , Florian Fainelli , George McCollister , Hauke Mehrtens , Jakub Kicinski , Kurt Kanzenbach , Landen Chao , Linus Walleij , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Matthias Brugger , netdev@vger.kernel.org, Paolo Abeni , Sean Wang , UNGLinuxDriver@microchip.com, Vivien Didelot , Vladimir Oltean , Woojung Huh Subject: Re: [PATCH RFC net-next 5/6] net: dsa: always use phylink for CPU and DSA ports Message-ID: References: <20220701213435.53ecdd70@thinkpad> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220701213435.53ecdd70@thinkpad> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220702_132736_428051_EE5EA4EA X-CRM114-Status: GOOD ( 29.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jul 01, 2022 at 09:34:35PM +0200, Marek Beh=FAn wrote: > On Wed, 29 Jun 2022 13:51:43 +0100 > "Russell King (Oracle)" wrote: > = > > Currently, we only use phylink for CPU and DSA ports if there is a > > fixed-link specification, or a PHY specified. The reason for this > > behaviour is that when neither is specified, there was no way for > > phylink to know the link parameters. > > = > > Now that we have phylink_set_max_link_speed() (which has become > > possible through the addition of mac_capabilities) we now have the > > ability to know the maximum link speed for a specific link, and can > > now use phylink for this case as well. > > = > > However, we need DSA drivers to report the interface mode being used > > on these ports so that we can select a maximum speed appropriate for > > the interface mode that hardware may have configured for the port. > > = > > This is especially important with the conversion of DSA drivers to > > phylink_pcs, as the PCS code only gets called if we are using > > phylink for the port. > > = > > Signed-off-by: Russell King (Oracle) > = > Reviewed-by: Marek Beh=FAn > = > So this is the one that may break other drivers? It's the one that I'm most concerned about breakage happening, because the other drivers won't be setting the default interface for the port, which means if they're taking advantage of this "defaulting" feature, this patch will break them. The original code just did nothing when this "defaulting" feature was used - it didn't call the DSA phylink_mac_link_down() op, and didn't register with phylink. The phylink_mac_link_down() there was to ensure that the ports are in a link-down state prior to setting up phylink, because that's what phylink expects. The problem comes is that once we've called phylink_mac_link_down(), there isn't a way to back out of that without knowing the interface mode, speed, duplex etc - which is the problem with this defaulting feature, none of that is specified in DT, it can only come from the drivers. Note that the mv88e6xxx series I posted earlier depends on getting this problem sorted - if we don't, I can't send the mv88e6xxx pcs conversion because mv88e6xxx boards that _do_ make use of this defaulting feature will break (and there are a number that do make use of it.) If I send this RFC series (minus the top patch) then all the drivers that make use of this defualting feature that aren't mv88e6xxx will probably break - but I've no idea which make use of this feature because it's not documented. It's not really documented in the DT binding either, it's just something that Andrew "knows about", mv88e6xxx makes use of, and Andrew has suggested to some other DSA driver authors. This absolutely needs Andrew's involvement. -- = RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel