Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4437868pxb; Tue, 5 Oct 2021 03:09:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzz6pvMH1n0qrMsT2/jabKtJGTlNug5VGykC7N5JqMoleq/X1tOi9pIMlpEFXPDqD9ZF8y3 X-Received: by 2002:a65:62c4:: with SMTP id m4mr15151212pgv.453.1633428550695; Tue, 05 Oct 2021 03:09:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633428550; cv=none; d=google.com; s=arc-20160816; b=rgdg6EtagIr8CAAiB99d7Xm3vsTp9If3GSl/Vtb4FG2jV+ZcXvaxQyOLcQ4SUBzdhQ lQOz6/jQcdwsb8TYvaIOq/KIj9Vd3IUFKTyhe7W21C9RsmnmoFOwPX1WLId2tqz1zi8M HEcmLOiYxE9o2w0rLazbjTXB2LF7tbeyZdh6BU73iSF1IcEtfM2WxBNDoSbkPy67d6Vt vI3bYn+2NC91z7gXm8i4NGOMlVt491gfjt6vExUgADqbEqnkILEuYHZMkgxe+5EBtFLi yRLFeWl2bnrXqe3p6Mm8CSG5wJQ5yWuWeXOuW/478kLBOmZw+NbkdY5zlw/kVr/HiiCR /A6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=x5LyrEZtyTYgVW8P7eEdPEoGjAnPMtn7SJqGAKJ+WAM=; b=UPVhbGZ8zzb3IRMMpZaZy0OaPqETKxFwWgFP57wKEWnwp+u51ueuK3seYMX8cbkfNI 0dinntoFLi2qLjw9LjFNIBELv1bzUHb5eoVPX+zlT224hy4gPCP56qPrRuKJP30G8Iai KlExvzkjhMKyC6072nBzoUnT05Cz33E/DpM92XzQ7sYGqVDKHNHDYJeTAB5rv7YLWGxA OYW8Ooxe5zfsYV+TW5hNM9TM3SxaVePFbkTFTameHvK9foEPUzmviYO+OlEgf/KlMmbd xmrfvSsD1OCoC6Z95Dxwfcn0uBGOZwpkbfFkwRUtKpczeRmK9HYq53Ubze37RhuWBxOX ksrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=xcPaIYgX; 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 nl10si2620726pjb.40.2021.10.05.03.08.57; Tue, 05 Oct 2021 03:09:10 -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=xcPaIYgX; 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 S233915AbhJEKIG (ORCPT + 99 others); Tue, 5 Oct 2021 06:08:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233784AbhJEKIB (ORCPT ); Tue, 5 Oct 2021 06:08: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 1C1F0C06161C; Tue, 5 Oct 2021 03:06:11 -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=x5LyrEZtyTYgVW8P7eEdPEoGjAnPMtn7SJqGAKJ+WAM=; b=xcPaIYgXlOo2smSUYYX6a3wMi+ Z3QY34kICgFD+S/huIFroTkxJUAiwbL4z7zZsBhbqviiC8lZ2Ace5P+fx6FwMoo660DfRJvR/GOIl gzTVGFdQdsMxQ6ZafP+x/0tbhoXYFUbFZObP1qt3ViPNghfb2pxRc/PPB0A39wSVA8MiythyYW9A2 hayH3VYhxeNhbVK7rQK+M4xQBceIdjhAibAegPmZI1igzduL8UVst9H1LlSFWaP+QKfGCPtEfQ9xV pIW8y+QfBl3Tn9IKlGIXU5WTSBm9tRa6WGizDDaIevuItbW+3GDkO0lBM3dBa/uIu+iVkVMCvkwkv Sp07Fyig==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:54950) 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 1mXhKq-00007Y-KF; Tue, 05 Oct 2021 11:06:08 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1mXhKo-0008NG-Dp; Tue, 05 Oct 2021 11:06:06 +0100 Date: Tue, 5 Oct 2021 11:06:06 +0100 From: "Russell King (Oracle)" To: Sean Anderson Cc: netdev@vger.kernel.org, "David S . Miller" , Jakub Kicinski , linux-kernel@vger.kernel.org, Andrew Lunn , Heiner Kallweit , Claudiu Beznea , Nicolas Ferre Subject: Re: [RFC net-next PATCH 10/16] net: macb: Move PCS settings to PCS callbacks Message-ID: References: <20211004191527.1610759-1-sean.anderson@seco.com> <20211004191527.1610759-11-sean.anderson@seco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211004191527.1610759-11-sean.anderson@seco.com> Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 04, 2021 at 03:15:21PM -0400, Sean Anderson wrote: > +static void macb_pcs_get_state(struct phylink_pcs *pcs, > + struct phylink_link_state *state) > +{ > + struct macb *bp = pcs_to_macb(pcs); > + > + if (gem_readl(bp, NCFGR) & GEM_BIT(SGMIIEN)) > + state->interface = PHY_INTERFACE_MODE_SGMII; > + else > + state->interface = PHY_INTERFACE_MODE_1000BASEX; There is no requirement to set state->interface here. Phylink doesn't cater for interface changes when reading the state. As documented, phylink will set state->interface already before calling this function to indicate what interface mode it is currently expecting from the hardware. > +static int macb_pcs_config_an(struct macb *bp, unsigned int mode, > + phy_interface_t interface, > + const unsigned long *advertising) > +{ > + bool changed = false; > + u16 old, new; > + > + old = gem_readl(bp, PCSANADV); > + new = phylink_mii_c22_pcs_encode_advertisement(interface, advertising, > + old); > + if (old != new) { > + changed = true; > + gem_writel(bp, PCSANADV, new); > + } > + > + old = new = gem_readl(bp, PCSCNTRL); > + if (mode == MLO_AN_INBAND) Please use phylink_autoneg_inband(mode) here. > + new |= BMCR_ANENABLE; > + else > + new &= ~BMCR_ANENABLE; > + if (old != new) { > + changed = true; > + gem_writel(bp, PCSCNTRL, new); > + } There has been the suggestion that we should allow in-band AN to be disabled in 1000base-X if we're in in-band mode according to the ethtool state. I have a patch that adds that. > + return changed; > +} > + > +static int macb_pcs_config(struct phylink_pcs *pcs, unsigned int mode, > + phy_interface_t interface, > + const unsigned long *advertising, > + bool permit_pause_to_mac) > +{ > + bool changed = false; > + struct macb *bp = pcs_to_macb(pcs); > + u16 old, new; > + unsigned long flags; > + > + spin_lock_irqsave(&bp->lock, flags); > + old = new = gem_readl(bp, NCFGR); > + if (interface == PHY_INTERFACE_MODE_SGMII) { > + new |= GEM_BIT(SGMIIEN); > + } else if (interface == PHY_INTERFACE_MODE_1000BASEX) { > + new &= ~GEM_BIT(SGMIIEN); > + } else { > + spin_lock_irqsave(&bp->lock, flags); > + return -EOPNOTSUPP; You can't actually abort at this point - phylink will print the error and carry on regardless. The checking is all done via the validate() callback and if that indicates the interface mode is acceptable, then it should be accepted. > static const struct phylink_pcs_ops macb_phylink_usx_pcs_ops = { > .pcs_get_state = macb_usx_pcs_get_state, > .pcs_config = macb_usx_pcs_config, > - .pcs_link_up = macb_usx_pcs_link_up, > }; > > static const struct phylink_pcs_ops macb_phylink_pcs_ops = { > .pcs_get_state = macb_pcs_get_state, > - .pcs_an_restart = macb_pcs_an_restart, You don't want to remove this. When operating in 1000BASE-X mode, it will be called if a restart is required (e.g. macb_pcs_config() returning positive, or an ethtool request.) You need to keep the empty function. That may also help the diff algorithm to produce a cleaner patch too. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!