From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C711E19918 for ; Fri, 2 Jun 2023 10:32:03 +0000 (UTC) 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 225452706; Fri, 2 Jun 2023 03:31:43 -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=W2sRh6JhtwM8CdhoxfQiPGQajleu7UP+IYJtnCKtmjY=; b=wVzTN74TaAAy6g9Z2NXkVzUG5L Lh3YkOFxqNDv7xaYInCmdVm9Wqfx12yfIw9d5w6ZWtHJm02r0uuC8QfHp8shCF/TyOCOgyDCi5/b9 1G6hpT6Q9TikreEApMcQ+xUWMCx67Xjb78qi/81YGpp2S3QMrQfj2tlNS74J7OOgzyOcZ0ZAzV4rD tcgQVp2XNADrg0BubpiIUnI4ztwhbN2dLYjBNB2Fusr9iEykjsjTQFyJT5fNkE9OU5pdd2M7aClxb loLKb79d3C3yXV9lNEOSbQojr1HZRt9sJtgozbosgwMvqcJMzd28jBBT4CQfDa2JviwTlNZuaQxf4 25iNcJRw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:43772) 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 1q523M-0007qI-Lj; Fri, 02 Jun 2023 11:30:40 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1q523I-0002rH-Ui; Fri, 02 Jun 2023 11:30:36 +0100 Date: Fri, 2 Jun 2023 11:30:36 +0100 From: "Russell King (Oracle)" To: msmulski2@gmail.com, Ioana Ciornei Cc: andrew@lunn.ch, f.fainelli@gmail.com, olteanv@gmail.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, simon.horman@corigine.com, kabel@kernel.org, Michal Smulski Subject: Re: [PATCH net-next v6 1/1] net: dsa: mv88e6xxx: implement USXGMII mode for mv88e6393x Message-ID: References: <20230602001705.2747-1-msmulski2@gmail.com> <20230602001705.2747-2-msmulski2@gmail.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230602001705.2747-2-msmulski2@gmail.com> Sender: Russell King (Oracle) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On Thu, Jun 01, 2023 at 05:17:04PM -0700, msmulski2@gmail.com wrote: > +/* USXGMII registers for Marvell switch 88e639x are undocumented and this function is based > + * on some educated guesses. It appears that there are no status bits related to > + * autonegotiation complete or flow control. > + */ > +static int mv88e639x_serdes_pcs_get_state_usxgmii(struct mv88e6xxx_chip *chip, > + int port, int lane, > + struct phylink_link_state *state) > +{ > + u16 status, lp_status; > + int err; > + > + err = mv88e6390_serdes_read(chip, lane, MDIO_MMD_PHYXS, > + MV88E6390_USXGMII_PHY_STATUS, &status); > + if (err) { > + dev_err(chip->dev, "can't read Serdes USXGMII PHY status: %d\n", err); > + return err; > + } > + dev_dbg(chip->dev, "USXGMII PHY status: 0x%x\n", status); > + > + state->link = !!(status & MDIO_USXGMII_LINK); > + > + if (state->link) { > + err = mv88e6390_serdes_read(chip, lane, MDIO_MMD_PHYXS, > + MV88E6390_USXGMII_LP_STATUS, &lp_status); What's the difference between these two registers? Specifically, what I'm asking is why the USXGMII partner status seems to be split between two separate registers. Note that I think phylink_decode_usxgmii_word() is probably missing a check for MDIO_USXGMII_LINK, based on how Cisco SGMII works (and USXGMII is pretty similar.) MDIO_USXGMII_LINK indicates whether the attached PHY has link on the media side or not. It's entirely possible for the USXGMII link to be up (thus allowing us to receive the "LPA" from the PHY) but for the PHY to be reporting to us that it has no media side link. So, I think phylink_decode_usxgmii_word() at least needs at the beginning this added: if (!(lpa & MDIO_USXGMII_LINK)) { state->link = false; return; } The only user of this has been the Lynx PCS, so I'll add Ioana to this email as well to see whether there's any objection from Lynx PCS users to adding it. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!