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 X-Spam-Level: X-Spam-Status: No, score=-8.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB1E4C433DF for ; Thu, 11 Jun 2020 17:47:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B2C23207ED for ; Thu, 11 Jun 2020 17:47:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=earth.li header.i=@earth.li header.b="ANXsmusz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728107AbgFKRrV (ORCPT ); Thu, 11 Jun 2020 13:47:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725824AbgFKRrU (ORCPT ); Thu, 11 Jun 2020 13:47:20 -0400 Received: from the.earth.li (the.earth.li [IPv6:2a00:1098:86:4d:c0ff:ee:15:900d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3307C03E96F; Thu, 11 Jun 2020 10:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=earth.li; s=the; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject :Cc:To:From:Date:Sender: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=LYQ+N8x0aH8bz40x26RW7A4B2ALqLvrlMXrsdbkjenw=; b=ANXsmusz27gS1YColuHDf8V1Wd UL5B1uIB3xQ2AJ0LHCIxuJM62SxcKcAbej8Fi5PEUaPfzHm2MiJ+rsdBMkbTCD5TxC4T52LuNb9VA DAfiZbKDaxU1GFvOyqgY/YDgFwuKGGhC+gjJ0YWLJVQYRczWQZgH9eIa+0pyXDvU8tobWDPiXVAiW MDUhbCDT88Eid+1ZkoK22Xmb0SgcXMxsObUMPmPkevl5bh3d4ZdRDjTJ6BAU/KSCtwGUp6rCDJyvN sc+xDp79WYLSFCgzBHn+T9kKzE6tOYaaplKvQ0z0yOV9H+coc4+1FIAzSIwJdnNcmQdQRUPb+rloy 8BxMoZEw==; Received: from noodles by the.earth.li with local (Exim 4.92) (envelope-from ) id 1jjRIG-0003Xp-Ro; Thu, 11 Jun 2020 18:47:12 +0100 Date: Thu, 11 Jun 2020 18:47:12 +0100 From: Jonathan McDowell To: Florian Fainelli Cc: Russell King - ARM Linux admin , Andrew Lunn , Vivien Didelot , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] net: dsa: qca8k: Improve SGMII interface handling Message-ID: <20200611174712.GW311@earth.li> References: <2150f4c70c754aed179e46e166f3c305254cf85a.1591816172.git.noodles@earth.li> <9d7d09d5-393f-d5bd-5c57-78c914bdc850@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9d7d09d5-393f-d5bd-5c57-78c914bdc850@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 10, 2020 at 08:31:11PM -0700, Florian Fainelli wrote: > On 6/10/2020 12:15 PM, Jonathan McDowell wrote: > > This patch improves the handling of the SGMII interface on the QCA8K > > devices. Previously the driver did no configuration of the port, even if > > it was selected. We now configure it up in the appropriate > > PHY/MAC/Base-X mode depending on what phylink tells us we are connected > > to and ensure it is enabled. > > > > Tested with a device where the CPU connection is RGMII (i.e. the common > > current use case) + one where the CPU connection is SGMII. I don't have > > any devices where the SGMII interface is brought out to something other > > than the CPU. > > > > Signed-off-by: Jonathan McDowell > > --- > > drivers/net/dsa/qca8k.c | 28 +++++++++++++++++++++++++++- > > drivers/net/dsa/qca8k.h | 13 +++++++++++++ > > 2 files changed, 40 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/dsa/qca8k.c b/drivers/net/dsa/qca8k.c > > index dcd9e8fa99b6..33e62598289e 100644 > > --- a/drivers/net/dsa/qca8k.c > > +++ b/drivers/net/dsa/qca8k.c > > @@ -681,7 +681,7 @@ qca8k_phylink_mac_config(struct dsa_switch *ds, int port, unsigned int mode, > > const struct phylink_link_state *state) > > { > > struct qca8k_priv *priv = ds->priv; > > - u32 reg; > > + u32 reg, val; > > > > switch (port) { > > case 0: /* 1st CPU port */ > > @@ -740,6 +740,32 @@ qca8k_phylink_mac_config(struct dsa_switch *ds, int port, unsigned int mode, > > case PHY_INTERFACE_MODE_1000BASEX: > > /* Enable SGMII on the port */ > > qca8k_write(priv, reg, QCA8K_PORT_PAD_SGMII_EN); > > + > > + /* Enable/disable SerDes auto-negotiation as necessary */ > > + val = qca8k_read(priv, QCA8K_REG_PWS); > > + if (phylink_autoneg_inband(mode)) > > + val &= ~QCA8K_PWS_SERDES_AEN_DIS; > > + else > > + val |= QCA8K_PWS_SERDES_AEN_DIS; > > + qca8k_write(priv, QCA8K_REG_PWS, val); > > + > > + /* Configure the SGMII parameters */ > > + val = qca8k_read(priv, QCA8K_REG_SGMII_CTRL); > > + > > + val |= QCA8K_SGMII_EN_PLL | QCA8K_SGMII_EN_RX | > > + QCA8K_SGMII_EN_TX | QCA8K_SGMII_EN_SD; > > + > > + val &= ~QCA8K_SGMII_MODE_CTRL_MASK; > > + if (dsa_is_cpu_port(ds, port)) { > > + /* CPU port, we're talking to the CPU MAC, be a PHY */ > > + val |= QCA8K_SGMII_MODE_CTRL_PHY; > > Since port 6 can be interfaced to an external PHY, do not you have to > differentiate here whether this port is connected to an actual PHY, > versus connected to a MAC? You should be able to use mode == MLO_AN_PHY > to differentiate that case from the others. I don't think MLO_AN_PHY is sufficient? If it's a fixed link we'll have MLO_AN_FIXED and that could be talking to a PHY? The logic I've gone for is assuming that a port hooked up to the CPU should look like a PHY, and otherwise we're hooked up to a PHY so we're acting as a MAC. That means we don't cope with the situation that we're hooked up to something that isn't the CPU but wants us to look like a PHY, but I don't think we have any current way to describe that. > > + } else if (state->interface == PHY_INTERFACE_MODE_SGMII) { > > + val |= QCA8K_SGMII_MODE_CTRL_MAC; > > + } else { > > + val |= QCA8K_SGMII_MODE_CTRL_BASEX; > > Better make this explicit and check for PHY_INTERFACE_MODE_1000BASEX, > even if those are the only two possible values covered by this part of > the case statement. Sure. I'll move the mask inside the if block too in that case, so we don't change the setting if we get fed something invalid. J. -- Beware of programmers carrying screwdrivers.