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 C1553C433EF for ; Thu, 7 Jul 2022 16:33:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235510AbiGGQd3 (ORCPT ); Thu, 7 Jul 2022 12:33:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235202AbiGGQd2 (ORCPT ); Thu, 7 Jul 2022 12:33:28 -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 056A41114 for ; Thu, 7 Jul 2022 09:33:25 -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-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=W1luyxt6XqoqNG1cOwcZcNryytjX2axh+qChWLTs2RA=; b=N/UN3+bi39NJCUQzYPqEOzHjMx a7WrcFu5Z7e+Q940v0ahh8EWaOvTIsTHAa15FPHTOTXxepvjmlI07CLFq1e1CacbY8j6u4h4G3K73 R4HHmqkSMA2z/TcbA8S1qN0FkFedfGFm5nce6pv4RTUD7PnHIEZa5QGzJHQtKriivsSNAZw7qy0aK n1LfOowZaH/NxnMDlhJJG6GeHKUGBQx02rj92fSihJSd2KdHWUGhnqSrXnL3KGGY+wakFbj2gV2Fo v9DYTp3u2PPoxW21IU4DzFUB0Zp5d4N138/YyAki16pmNYuMCHrtRGqcZBYr8fHUHDTvh2TMpHgvi agbgIp0g==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:33230) 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 1o9UR4-00047L-Je; Thu, 07 Jul 2022 17:33:02 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1o9UQz-0005PK-4Z; Thu, 07 Jul 2022 17:32:57 +0100 Date: Thu, 7 Jul 2022 17:32:57 +0100 From: "Russell King (Oracle)" To: Vladimir Oltean 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 , Woojung Huh , Marek =?iso-8859-1?Q?Beh=FAn?= Subject: Re: [PATCH RFC net-next 5/5] net: dsa: always use phylink for CPU and DSA ports Message-ID: References: <20220706102621.hfubvn3wa6wlw735@skbuf> <20220707154303.236xaeape7isracw@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220707154303.236xaeape7isracw@skbuf> Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Jul 07, 2022 at 06:43:03PM +0300, Vladimir Oltean wrote: > On Thu, Jul 07, 2022 at 12:00:54PM +0100, Russell King (Oracle) wrote: > > More importantly, we need your input on Ocelot, which you are listed as > > a maintainer for, and Ocelot is the only DSA driver that does stuff > > differently (due to the rate adapting PCS). It doesn't set > > mac_capabilities, and therefore phylink_set_max_fixed_link() will not > > work here. > > > > Has Ocelot ever made use of this DSA feature where, when nothing is > > specified for a CPU or DSA port, we use an effective fixed-link setup > > with an interface mode that gives the highest speed? Or does this not > > apply to this DSA driver? > > > > Thanks. > > I'm fine with both the ocelot and sja1105 drivers. > > The ocelot driver has 3 users: > > - felix_vsc9959 (arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi) on NXP > LS1028A, where the CPU ports have and have always had a fixed-link > node in the SoC dtsi. LS1028A based boards should include the SoC > dtsi. If other board DT writers don't do that or if they delete the > fixed-link node from the CPU ports, that's not my problem and I don't > really want to help them. > > - seville_vsc9953 (arch/powerpc/boot/dts/fsl/t1040si-post.dtsi) on NXP > T1040. Same thing, embedded switch, not my fault if the fixed-link > disappears from the SoC dtsi. Great, so I'll mark ocelot is safe. > - Colin Foster's SPI-controlled VSC7512 (still downstream). He has an > Ethernet cable connecting the CPU port to a Beaglebone Black, so he > has a phy-handle on the CPU port, so definitely not nothing. I believe > his work hasn't made it to production in any case, so enforcing > validation now shouldn't bother him too much if at all. Ok, thanks. > As for sja1105, there is DT validation that checks for the presence of > all required properties in sja1105_parse_ports_node(). Looking at those, it requires all of: - a phy mode to be specified (as determined by of_get_phy_mode()) - a phy-handle or of_phy_is_fixed_link() to return true otherwise it errors out. > There is some DT validation in felix_parse_ports_node() too, but it > doesn't check that all specifiers that phylink might use are there. Phylink (correction, fwnode_get_phy_node() which is not part of phylink anymore) will look for phy-handle, phy, or phy-device. This is I don't see that there's any incompatibility between what the driver is doing and what phylink does. If there's a fixed-link property, then sja1105_parse_ports_node() is happy, and so will phylink. If there's a phy-handle, the same is true. If there's a "phy" or "phy-device" then sja1105_parse_ports_node() errors out. That's completely fine. "phy" and "phy-device" are the backwards compatibility for DT - I believe one of them is the ePAPR specified property that we in Linux have decided to only fall back on if there's not our more modern "phy-handle" property. It seems We have a lot of users of "phy" in DT today, so we can't drop that from generic code such as phylink, but I haven't found any users of "phy-device". > I'd really like to add some validation before I gain any involuntary > users, but all open-coded constructs I can come up with are clumsy. > What would you suggest, if I explicitly don't want to rely on > context-specific phylink interpretation of empty OF nodes, and rather > error out? 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. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!