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 61237C433EF for ; Thu, 7 Jul 2022 16:36:41 +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=Vbv9abWC/sROQ2SLpxZFw+GW3vwXIGNAoydNSX1ih6w=; b=Kq8bWmv8A5y2dX fofBHsn5nn8STiBo/3EqjkBPNqG2qPOWfImB3EtVMKWWR/GNqQduufjq3LCfgb4de224NePLpEl7q hNcSPEDa6W+/SgU8rcUQ+V8WlHQICCzZwEatYS0KUWf3mWluy4WKpfAtivCmx+grwyqawV0P4MpKV xRjqivb0bqobQVR3nmKsQumglmYgvQIENJtR10v+R2XAyQoFx/FUNHGc+q9y3v+NbVyEl3O5WQE3K x6Miabbl98X1rbXjBKyWN7pcuLeNpQJJ5/+FRoi4cpk4to9qKSa1HAGzpSoKINFho8iz3cdFrAPgm m1uXTbXl58wQaNvlxY0A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9UTS-00H02L-SH; Thu, 07 Jul 2022 16:35:30 +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 1o9UTO-00Gzgj-Pp; Thu, 07 Jul 2022 16:35:28 +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=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-Disposition: inline In-Reply-To: <20220707154303.236xaeape7isracw@skbuf> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220707_093526_888207_47899C65 X-CRM114-Status: GOOD ( 30.34 ) 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 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! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel