From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (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 E2AF01DDA24 for ; Tue, 26 Nov 2024 21:43:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732657420; cv=none; b=dDi3BvzKyvErbTio9/A++QFT4oEhD2tRG8+6uAHP3k90f0j7HjcCLSXB+8OJv8DIvx0xrFXxurAvJ9G/4V5dRBwcnHKZB1him+gB+oU5viEp9KS/MgUf8X1LOtyPick3pvv2M31FdFKGyt905SOOU1ms33gIjG9TLhAAzU2TGzA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732657420; c=relaxed/simple; bh=RhMVcfwDjgwApC2eBZUZBrY6cSLZUrEhkmUR5nW0adQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fihPDo4P4Kgk8wLQzztYNaRswB1F0a72u9gip5pKRJGhztotd1zFZtUntXRO2a/vS6NnI4FYFg4upQTRChOlrdArLgETgazZbKwybObUbhv27WmESgV7Thgss+jmw6K5DEzE0MYRl+EoGlbzc/Qft0rryfdmxcXR9MOxVKOL9W8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=FFYZHdso; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="FFYZHdso" 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=boX705ixGpX0WIhU4HsHMX1LO3WzB02Fz6xUUWqOtdg=; b=FFYZHdsokE0B/sNH1TVhXQGepS YcmDSz+0gpqG1KHdFM+5lQSHUBjhH3JTcTxjsWMGBxw97s+9LgiKBrZ6JHQ8SP9i8jdvCC7JSh+li Es0g3quRaeHJHsL821rY4mu0+0mn7maNDYLja9l6cKU6I/Huw1bvCXGedqsTIp86fRhiPCDb+MrFO XrcZS7Pf122Mv76xy3DRRXKia8j4I5lUL3KjUYupkfQ0B2hTvGg5X2s9xIBSukMvBGEVwPeEnG/gy WtaRvGmHOzJS8CSgTXQ8fS+ih3MYTXXgIsHBV9H3tS+OxaWJoEZff9lTCK7JH56wkQVYXM5YWJI0y L3KwSlOA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:42268) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tG3L5-0007k1-2T; Tue, 26 Nov 2024 21:43:20 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.96) (envelope-from ) id 1tG3L0-0004sg-1X; Tue, 26 Nov 2024 21:43:14 +0000 Date: Tue, 26 Nov 2024 21:43:14 +0000 From: "Russell King (Oracle)" To: Andrew Lunn Cc: Heiner Kallweit , Alexander Couzens , Andrew Lunn , AngeloGioacchino Del Regno , Broadcom internal kernel review list , Daniel Golle , "David S. Miller" , Eric Dumazet , Florian Fainelli , Ioana Ciornei , Jakub Kicinski , Jose Abreu , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Marcin Wojtas , Matthias Brugger , netdev@vger.kernel.org, Paolo Abeni Subject: Re: [PATCH RFC net-next 15/16] net: phylink: add negotiation of in-band capabilities Message-ID: References: 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: Sender: Russell King (Oracle) On Tue, Nov 26, 2024 at 10:18:56PM +0100, Andrew Lunn wrote: > > + if (pcs_ib_caps && pcs_ib_caps != LINK_INBAND_DISABLE) { > > + /* PCS supports reporting in-band capabilities, and > > + * supports more than disable mode. > > + */ > > + if (pcs_ib_caps & LINK_INBAND_DISABLE) > > + neg_mode = PHYLINK_PCS_NEG_OUTBAND; > > + else if (pcs_ib_caps & LINK_INBAND_ENABLE) > > + pcs_ib_only = true; > > + } > > + > > + if (phy_ib_caps && phy_ib_caps != LINK_INBAND_DISABLE) { > > + /* PHY supports in-band capabilities, and supports > > + * more than disable mode. > > + */ > > + if (phy_ib_caps & LINK_INBAND_DISABLE) > > + pl->phy_ib_mode = LINK_INBAND_DISABLE; > > + else if (phy_ib_caps & LINK_INBAND_BYPASS) > > + pl->phy_ib_mode = LINK_INBAND_BYPASS; > > + else if (phy_ib_caps & LINK_INBAND_ENABLE) > > + phy_ib_only = true; > > Looking at the different handling between PCS and PHY, i asked myself, > does PCS BYPASS exist? If it is invalid, i don't see a check if the > PCS is reporting it and should we be issuing a warning? Yes, it does exist - see for example MVNETA_GMAC_AN_BYPASS_ENABLE for mvneta - but there's complications to using it that need sorting first. The problem is if SGMII enters bypass mode, then the duplex is configured according to MVNETA_GMAC_CONFIG_FULL_DUPLEX. In wonderful Marvell style, it makes no mention about the speed setting. It does say that it's supported for "SGMII modes". One assumes that it would do the same thing and fall back to setting described by the two speed bits, but the documentation doesn't say that. Maybe "SGMII modes" is referring to Base-X only and not Cisco SGMII. The problem of what seems to be almost an industry wide abuse of the "SGMII" term creating a trainwreck strikes again! -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!