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 199B7C433EF for ; Thu, 21 Jul 2022 14:59:42 +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=4n+nHBrMqRted6fYrgizyL+UktOTZXR3g0+5CtWGYYs=; b=Wlwqxk9/NaLTgn kYuSoc1BKsBa8zdT0AOOny7dV90cq3B9uEMVqLHYWkt1ciGNplsKDZ6Iu+WPFV053zPYt07fhLAVc F4a7387eCTrZiBDnOldbkAPtFIAubjaoSfKwCFVpi3dHFxpIQhMjDaD/cXmVjY+DbAIKgw+wm5tic AM+LXu7rOJ0FFd6mMNogTj39Ut3nY6nsYIPuNC0KQfpMJLf/C/8q5SJshPhCE79lvkW7Ot+roVnnw U+NmgbCACdunf1CkscFifB02t3YyRhApEgfRQmlKmnEeGnvaJNFYB1km2JcIId8kv6bJFpMs3zYx4 XKzH2st0Uncfk+6SATKA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEXd8-008Vrx-7c; Thu, 21 Jul 2022 14:58:22 +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 1oEXc2-008R2l-PI; Thu, 21 Jul 2022 14:57:16 +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-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=GJms8OFun/ubSdkBaWHWcb6Ty10VDWQdCs1zZ9jGyhY=; b=ParruOU1TaiFmwxpDopn8iE5xb PBBbcYrjpVlwn8/FVBySJV502FPEyp/NYUw9Le2G7RykZqfBiIIkMaWfkFq6SdJZcGkSTZdWNUp7g SO3QpJuLGsK8HgR1NpQdw11aC8U8M3NxghRuKsmxOGrFwUa9+mY9EpYdIHTzk5dXtwA51EJKJSRpD /tAT7222u0J0iuqxN1V56C1GmZrVv+R55s8+dorCMehGUnm3qGB9/EnrWSinar/7FStRgcmo3qH30 LfG23A69SH9pO29kFTPie/EX7YCWBGwzMTh1JeY4Wse3ICJkM7kH/OMzNqEj49NbiUCporkPgowCA bF2R2EfA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:33480) 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 1oEXZF-0005Xd-9J; Thu, 21 Jul 2022 15:54:21 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1oEXZ9-0004wJ-7C; Thu, 21 Jul 2022 15:54:15 +0100 Date: Thu, 21 Jul 2022 15:54:15 +0100 From: "Russell King (Oracle)" To: Vladimir Oltean Cc: Andrew Lunn , Heiner Kallweit , Alexandre Belloni , Alvin __ipraga , Andy Shevchenko , Claudiu Manoil , Daniel Scally , "David S. Miller" , DENG Qingfang , Eric Dumazet , Florian Fainelli , George McCollister , Greg Kroah-Hartman , Hauke Mehrtens , Heikki Krogerus , Jakub Kicinski , Kurt Kanzenbach , Landen Chao , Linus Walleij , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Matthias Brugger , netdev@vger.kernel.org, Paolo Abeni , "Rafael J. Wysocki" , Sakari Ailus , Sean Wang , UNGLinuxDriver@microchip.com, Vivien Didelot , Woojung Huh , Marek =?iso-8859-1?Q?Beh=FAn?= Subject: Re: [PATCH net-next 3/6] net: dsa: add support for retrieving the interface mode Message-ID: References: <20220715172444.yins4kb2b6b35aql@skbuf> <20220715222348.okmeyd55o5u3gkyi@skbuf> <20220716105711.bjsh763smf6bfjy2@skbuf> <20220716123608.chdzbvpinso546oh@skbuf> <20220720224447.ygoto4av7odsy2tj@skbuf> <20220721134618.axq3hmtckrumpoy6@skbuf> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220721134618.axq3hmtckrumpoy6@skbuf> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220721_075714_874099_275E07DD X-CRM114-Status: GOOD ( 30.05 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 21, 2022 at 04:46:18PM +0300, Vladimir Oltean wrote: > On Thu, Jul 21, 2022 at 01:44:47AM +0300, Vladimir Oltean wrote: > > I really wish there was a ready-made helper for validating phylink's > > OF node; I mentioned this already, it needs to cater for all of > > fixed-link/phy-handle/managed/sfp. > > While I was going to expand on this point and state that DSA doesn't > currently instantiate phylink for this OF node: > > port@9 { > reg = <0x9>; > label = "cpu"; > ethernet = <ð1>; > phy-mode = "2500base-x"; > managed = "in-band-status"; > }; > > I was proven wrong. Today I learned that of_phy_is_fixed_link() returns > true if the "managed" property exists and its value differs from "auto". > So in the above case, of_phy_is_fixed_link() returns true, hmmm. Yes, which is why I said on July 7th: "So I also don't see a problem - sja1105 rejects DTs that fail to describe a port using at least one of a phy-handle, a fixed-link, or a managed in-band link, and I don't think it needs to do further validation, certainly not for the phy describing properties that the kernel has chosen to deprecate for new implementations." I had assumed you knew of_phy_is_fixed_link() returns true in this case. Do you now see that sja1105's validation is close enough (except for the legacy phy phandle properties which we don't care about), and thus do we finally have agreement on this point? > On the other hand I found arm64/boot/dts/marvell/cn9130-crb.dtsi, where > the switch, a "marvell,mv88e6190"-compatible (can't determine going just > by that what it actually is) has this: > > port@a { > reg = <10>; > label = "cpu"; > ethernet = <&cp0_eth0>; > }; Port 10 on 88E6393X supports 10GBASE-R, and maybe one day someone will get around to implementing USXGMII. This description relies upon this defaulting behaviour - as Andrew has described, this has been entirely normal behaviour with mv88e6xxx. > To illustrate how odd the situation is, I am able to follow the phandle > to the CPU port and find a comment that it's a 88E6393X, and that the > CPU port uses managed = "in-band-status": > > &cp0_eth0 { > /* This port is connected to 88E6393X switch */ > status = "okay"; > phy-mode = "10gbase-r"; > managed = "in-band-status"; > phys = <&cp0_comphy4 0>; > }; 10GBASE-R has no in-band signalling per-se, so the only effect this has on the phylink instance on the CPU side is to read the status from the PCS as it does for any other in-band mode. In the case of 10GBASE-R, the only retrievable parameter is the link up/down status. This is no different from a 10GBASE-R based fibre link in that regard. A fixed link on the other hand would not read status from the PCS but would assume that the link is always up. > Open question: is it sane to even do what we're trying here, to create a > fixed-link for port@a (which makes the phylink instance use MLO_AN_FIXED) > when &cp0_eth0 uses MLO_AN_INBAND? My simple mind thinks that if all > involved drivers were to behave correctly and not have bugs that cancel > out other bugs, the above device tree shouldn't work. The host port > would expect a clause 37 base page exchange to take place, the switch > wouldn't send any in-band information, and the SERDES lane would never > transition to data mode. To fix the above, we'd really need to chase the > "ethernet" phandle and attempt to mimic what the DSA master did. This is > indeed logic that never existed before, and I don't particularly feel > like adding it. How far do we want to go? It seems like never-ending > insanity the more I look at it. 10GBASE-R doesn't support clause 37 AN. 10GBASE-KR does support inband AN, but it's a different clause and different format. -- 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