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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 441B5C433FE for ; Tue, 22 Nov 2022 11:21:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232503AbiKVLVW (ORCPT ); Tue, 22 Nov 2022 06:21:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233000AbiKVLUt (ORCPT ); Tue, 22 Nov 2022 06:20:49 -0500 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 BD9725B5B7 for ; Tue, 22 Nov 2022 03:16:28 -0800 (PST) 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=RYtpynv/kogTOkI7TLHvo2p/ncitXmtCLLJ+tXI0lNU=; b=FxmC0QuRwhmbDzGQTJ2xEnft63 WsvydlPeI6q5SfJtVeex9MDVxyNoij5iY5yyZzt7SAx3Hi5+OBOBjZPvkUovubVkwjhOAYlqxLOav aYOWI2fALk0yiycskgB2O5iwytArwq8LmWZnCglL62fYSWGW/iq5XKf9BOV4LjoyropsZYrmjclyJ Jqf/E1brPgXy6Nf3WPLbS3rfkktNQsHIJAsBx92c8nRjoWZwWKT0Yx8UHm96JCSDDHEmpXqa2W3Wz WCCYbsCu+L6hL3Ml7d+BaWP2Zi960HC4rQkdLngi+acsgJkjMy9rMn20DI9hChAlSVTSCqNN6VziB dQEPyZOg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:35378) 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 1oxRGD-0001PG-NQ; Tue, 22 Nov 2022 11:16:17 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1oxRG3-0003HC-TZ; Tue, 22 Nov 2022 11:16:07 +0000 Date: Tue, 22 Nov 2022 11:16:07 +0000 From: "Russell King (Oracle)" To: Vladimir Oltean Cc: netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Heiner Kallweit , Andrew Lunn , Florian Fainelli , UNGLinuxDriver@microchip.com, bcm-kernel-feedback-list@broadcom.com, Madalin Bucur , Camelia Groza , Claudiu Manoil , Ioana Ciornei , Maxim Kochetkov , Sean Anderson , Antoine Tenart , Michael Walle , Raag Jadav , Siddharth Vadapalli , Ong Boon Leong , Colin Foster , Marek Behun Subject: Re: [PATCH v4 net-next 3/8] net: phy: bcm84881: move the in-band capability check where it belongs Message-ID: References: <20221118000124.2754581-1-vladimir.oltean@nxp.com> <20221118000124.2754581-4-vladimir.oltean@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Nov 22, 2022 at 09:38:43AM +0000, Russell King (Oracle) wrote: > Also, if we get the Marvell driver implementing validate_an_inband() > then I believe we can get rid of other parts of this patch - 88E1111 is > the commonly used accessible PHY on gigabit SFPs, as this PHY implements > I2C access natively. As I mentioned, Marvell PHYs can be set to no > inband, requiring inband, or inband with bypass mode enabled. So we > need to decide how we deal with that - especially if we're going to be > changing the mode from 1000base-X to SGMII (which we do on some SFP > modules so they work at 10/100/1000.) For the Marvell 88E1111: - If switching into 1000base-X mode, then bypass mode is enabled by m88e1111_config_init_1000basex(). However, if AN is disabled in the fibre page BMCR (e.g. by firmware), then AN won't be used. - If switching into SGMII mode, then bypass mode is left however it was originally set by m88e1111_config_init_sgmii() - so it may be allowed or it may be disallowed, which means it's whatever the hardware defaulted to or firmware set it as. For the 88e151x (x=0,2,8) it looks like bypass mode defaults to being allowed on hardware reset, but firmware may change that. I don't think we make much of an effort to configure other Marvell PHYs, relying on their hardware reset defaults or firmware to set them appropriately. So, I think for 88e151x, we should implement something like: int mode, bmcr, fscr2; /* RGMII too? I believe RGMII can signal inband as well, so we * may need to handle that as well. */ if (interface != PHY_INTERFACE_MODE_SGMII && interface != PHY_INTERFACE_MODE_1000BASE_X) return PHY_AN_INBAND_UNKNOWN; bmcr = phy_read_paged(phydev, MII_MARVELL_FIBER_PAGE, MII_BMCR); if (bmcr < 0) return SOME_ERROR? mode = PHY_AN_INBAND_OFF; if (bmcr & BMCR_ANENABLE) { mode = PHY_AN_INBAND_ON; fscr2 = phy_read_paged(phydev, MII_MARVELL_FIBER_PAGE, 0x1a); if (fscr2 & BIT(6)) mode |= PHY_AN_INBAND_TIMEOUT; } return mode; Obviously adding register definitions for BIT(6) and 01a. For the 88E1111: int mode, hwcfg; /* If operating in 1000base-X mode, we always turn on inband * and allow bypass. */ if (interface == PHY_INTERFACE_MODE_1000BASEX) return PHY_AN_INBAND_ON | PHY_AN_INBAND_TIMEOUT; if (interface == PHY_INTERFACE_MODE_SGMII) { hwcfg = phy_read(phydev, MII_M1111_PHY_EXT_SR); if (hwcfg < 0) return SOME_ERROR? mode = PHY_AN_INBAND_ON; if (hwcfg & MII_M1111_HWCFG_SERIAL_AN_BYPASS) mode |= PHY_AN_INBAND_TIMEOUT; return mode; } return PHY_AN_INBAND_UNKNOWN; Maybe? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!