Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3827358pxj; Mon, 21 Jun 2021 07:28:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyoy/19m9cz0mCTbX69T5NVqvOaWMX+5IUe1onGXPDY1nrkLXYHrIJ3/XEFIKRbtbOGhVtr X-Received: by 2002:a17:906:f915:: with SMTP id lc21mr24902844ejb.71.1624285705968; Mon, 21 Jun 2021 07:28:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624285705; cv=none; d=google.com; s=arc-20160816; b=0ETKQ2K2J8nBRtN54KaiyFH5AM5v6s0Xc0vRFeWU9ezMZVt5Wck1CuKYtibg9Nw7gO f72E0cI9QZ58W41uQy/IB6T0wgUCUMBIHVoey16OuVr+WLQeDb7mOSC2aO+35uBMdTaB hJ8jJo2xJScKalNG79ht3tcJ0gWJISGeyg4Gzb5UGHd/dL1/dNMOEaLSoiVvKTfiQ85p 5evgVHY031nFpRC8RFiBgcoi+3Et9s9ixzL0gtppQATISIApO6n6oXHPcEoUdzFEXzc0 1Adlhj1an0dIMO+ld08pHKIDpf9NTtn42q96f72mR6Bxh2O4gGVsbiAX5G4lhCt6byX9 MjdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=+FLy97mYiZUhpCmnjYrs9sM1itPFoTYvaxLbjIGV0Vo=; b=dtRpDkhIbrO0ZnXbHQBxy7137/OPehWYeUProrgjdY7eVDO/CxIw7bSGVD09Uk6UOQ opKubNnhFHJLSRL2uV+ZKHILQ6d2IpDe5VylF2Q6GUKsBvcGc2oquDSn7VzrrIDWEKBi flJgaddTC3BFNz6YxWjuhxnUd7SZKWDDq09gMncewAbNRlv6ZfNnDpxCgCCkDom+rHZO LauVAggk4zHNJk3hdXDbAj2yIeXplYZFoBrNqanV3P7EiesSwVFJkDqQvsHClhTlfTQQ O/dDSujZsho5I2CrCt/P2wfyXRK/2QSka3O+HtYDyLL7Y0c5Vo5kLvTORE7Ut7e6GKfU 5J3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=ra6UFsNT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l9si6922712edv.6.2021.06.21.07.28.03; Mon, 21 Jun 2021 07:28:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=ra6UFsNT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230137AbhFUO3C (ORCPT + 99 others); Mon, 21 Jun 2021 10:29:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229765AbhFUO3B (ORCPT ); Mon, 21 Jun 2021 10:29:01 -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 65925C061574; Mon, 21 Jun 2021 07:26:47 -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=+FLy97mYiZUhpCmnjYrs9sM1itPFoTYvaxLbjIGV0Vo=; b=ra6UFsNTyawCbvwUOQ4AmcVjY ZUEnTXHRmXzkEE3aIfpcLE3COwLKLFVy2ZBqsybs9U7dwlMCYflbJgWW/jdbfGAnL8sY0b7mXq3MZ +GBGwc8815KLbSQP17ex7rB5Fm/Fndju7fS64XbZErWb36BvqDelQtDONcKy2VAK4Gmtw5i0dV8lo 7IRdiAgloL0DaeTeI3OVatJPcBHqIScdDl+1efRNgJpR4KGtFouyAvjteszHpTs26L0BdgBUGHQZT za8H9bdN+7EOovuOrhR3/1xW3Vs5/HFiXHQMl12MNd34Lq61deVnGb2GJzBi34taHIDpdXnjPtDWi aLw7i5Yww==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:45226) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lvKsh-0004FE-NN; Mon, 21 Jun 2021 15:26:31 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1lvKse-0002xR-Iz; Mon, 21 Jun 2021 15:26:28 +0100 Date: Mon, 21 Jun 2021 15:26:28 +0100 From: "Russell King (Oracle)" To: Steen Hegelund Cc: "David S. Miller" , Jakub Kicinski , Andrew Lunn , Microchip Linux Driver Support , Alexandre Belloni , Madalin Bucur , Mark Einon , Masahiro Yamada , Arnd Bergmann , Philipp Zabel , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Bjarni Jonasson , Lars Povlsen Subject: Re: [PATCH net-next v4 03/10] net: sparx5: add hostmode with phylink support Message-ID: <20210621142628.GM22278@shell.armlinux.org.uk> References: <20210615085034.1262457-1-steen.hegelund@microchip.com> <20210615085034.1262457-4-steen.hegelund@microchip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210615085034.1262457-4-steen.hegelund@microchip.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 15, 2021 at 10:50:27AM +0200, Steen Hegelund wrote: > This patch adds netdevs and phylink support for the ports in the switch. > It also adds register based injection and extraction for these ports. > > Frame DMA support for injection and extraction will be added in a later > series. > > Signed-off-by: Steen Hegelund > Signed-off-by: Bjarni Jonasson > Signed-off-by: Lars Povlsen Hi, While looking at this patch, I found sparx5_destroy_netdev() which seems to be unreferenced - it may be referenced in a future patch. However, this means that while sparx5_create_port() creates the phylink structure, there is nothing in this patch that cleans it up. I'm puzzled by the call to phylink_disconnect_phy() in sparx5_destroy_netdev() too - surely if we get to the point of tearing down stuff that we've created at initialisation, the interface had better be down? > diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c b/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c > new file mode 100644 > index 000000000000..c17a3502645a > --- /dev/null > +++ b/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c > @@ -0,0 +1,185 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* Microchip Sparx5 Switch driver > + * > + * Copyright (c) 2021 Microchip Technology Inc. and its subsidiaries. > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#include "sparx5_main_regs.h" > +#include "sparx5_main.h" > + > +static void sparx5_phylink_validate(struct phylink_config *config, > + unsigned long *supported, > + struct phylink_link_state *state) > +{ > + struct sparx5_port *port = netdev_priv(to_net_dev(config->dev)); > + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, }; > + > + phylink_set(mask, Autoneg); > + phylink_set_port_modes(mask); > + phylink_set(mask, Pause); > + phylink_set(mask, Asym_Pause); > + > + switch (state->interface) { > + case PHY_INTERFACE_MODE_5GBASER: > + case PHY_INTERFACE_MODE_10GBASER: > + case PHY_INTERFACE_MODE_25GBASER: > + case PHY_INTERFACE_MODE_NA: > + if (port->conf.bandwidth == SPEED_5000) > + phylink_set(mask, 5000baseT_Full); > + if (port->conf.bandwidth == SPEED_10000) { > + phylink_set(mask, 5000baseT_Full); > + phylink_set(mask, 10000baseT_Full); > + phylink_set(mask, 10000baseCR_Full); > + phylink_set(mask, 10000baseSR_Full); > + phylink_set(mask, 10000baseLR_Full); > + phylink_set(mask, 10000baseLRM_Full); > + phylink_set(mask, 10000baseER_Full); > + } > + if (port->conf.bandwidth == SPEED_25000) { > + phylink_set(mask, 5000baseT_Full); > + phylink_set(mask, 10000baseT_Full); > + phylink_set(mask, 10000baseCR_Full); > + phylink_set(mask, 10000baseSR_Full); > + phylink_set(mask, 10000baseLR_Full); > + phylink_set(mask, 10000baseLRM_Full); > + phylink_set(mask, 10000baseER_Full); > + phylink_set(mask, 25000baseCR_Full); > + phylink_set(mask, 25000baseSR_Full); > + } I really need to fix phylink so we shouldn't be lying about which speeds are supported over a 10GBASER link... but that's something for the future. > +static bool port_conf_has_changed(struct sparx5_port_config *a, struct sparx5_port_config *b) > +{ > + if (a->speed != b->speed || > + a->portmode != b->portmode || > + a->autoneg != b->autoneg || > + a->pause != b->pause || > + a->power_down != b->power_down || > + a->media != b->media) > + return true; > + return false; > +} Should this be positioned somewhere else rather than in the middle of the sparx5 phylink functions (top of file maybe?) > +static void sparx5_phylink_mac_config(struct phylink_config *config, > + unsigned int mode, > + const struct phylink_link_state *state) > +{ > + struct sparx5_port *port = netdev_priv(to_net_dev(config->dev)); > + > + port->conf.autoneg = state->an_enabled; > + port->conf.pause = state->pause; What are you doing with state->pause? It looks to me like you're using both of these to carry configuration to pcs_config? Generally, an_enabled can be pulled out of the advertising mask, it should always reflect ETHTOOL_LINK_MODE_Autoneg_BIT. The "pause" interpretation of the pause bits here are somewhat hardware specific. It depends whether the MAC automatically receives state information from the PCS or not. If the hardware does, then MLO_PAUSE_AN indicates whether that should be permitted or not. Otherwise, the advertising mask in pcs_config() indicates which pause modes should be advertised, and the tx_pause/rx_pause in the *_link_up() indicates what should actually be set. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!