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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A5F8CC77B7D for ; Mon, 15 May 2023 15:35:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cGmmyl8gDHjGXmYB37ZqfJPC65r3hY8pU5Hi1YdBn5M=; b=r0Gr8VbjNRMJzm 8fjkme/3nTp84GcT8D1wCE+I1NY3imjLtf9Gl3r/qnv1RLA3hr/JDWc8Qjka/TE+QPXP7nOPeUFpc zwS7ZKRQQwD3/VwD1aeV+WI1B6dUVfKZ9e49kzaI/tM6+e/lp4UPyseVygO6D0z7SKDHRxUexCkBP WIPEgqF+Gzz0WnVlWgFYZMICp6tCOnphyZ1n24XhRsuh6pu83kUYQb4mjDXsx/Z+Rc4GxLkBvTJrw LkMLrEztOqB3+ovfD6xuuhfnXXsSVibenc2GK4cMCUn3nWAKRBlJkYJJx9+wFxgL26IbntzzA6Xl2 YejGXEIz2Xh7ItRcvIDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyaEC-002afU-2z; Mon, 15 May 2023 15:35:12 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pyaE9-002aeF-3A; Mon, 15 May 2023 15:35:11 +0000 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=8a+oLK/EjvW2iWa4CvVnKNi6T68qPXF5eHPAeQXKSvQ=; b=HGU6JtmhWszCAfdURqlW/Ut+66 84hfuyjtPVc0MwUYbNBETFcAfz5NM3sIeqSEbFmEmGNNvk3dFGzJLjogP8wMWREs0etAtaMdhmewm eVB3ZrcO8d3CLxmquVIK+CrS92ER5HYC6ww+g+uoqGRBYqiImluxiC4kzdz5jaQ4iDt1Di0fqZKBe ru8cAs/vtn2Mr9fpOiEsLtOvHpTZXDV2GgAXjra2y9NOMRR3vTgDvwzfD8V37n6i5xEat0O+glzPX JGSGf6Toh6R6H9RaiXqOH9/EsOCgWMoGpewU/wbqrdHB1aQE0K5gpPeazG68DSGxo3CXk9EPM9nhq Le3hPnQw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:35164) 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 1pyaDg-0003ww-8S; Mon, 15 May 2023 16:34:40 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1pyaDZ-0008Ic-Pp; Mon, 15 May 2023 16:34:33 +0100 Date: Mon, 15 May 2023 16:34:33 +0100 From: "Russell King (Oracle)" To: Andrew Lunn Cc: AngeloGioacchino Del Regno , Daniel Machon , "David S. Miller" , Eric Dumazet , Felix Fietkau , Florian Fainelli , Heiner Kallweit , Horatiu Vultur , Ioana Ciornei , Jakub Kicinski , John Crispin , Jose Abreu , Lars Povlsen , Lorenzo Bianconi , Marcin Wojtas , Mark Lee , Matthias Brugger , Maxime Chevallier , Paolo Abeni , Sean Wang , Steen Hegelund , Taras Chornyi , Thomas Petazzoni , UNGLinuxDriver@microchip.com, Vladimir Oltean , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, netdev@vger.kernel.org Subject: Re: [PATCH RFC] Providing a helper for PCS inband negotiation Message-ID: References: <9f7b1d6f-ca62-4c6c-9cd5-37726e7857b7@lunn.ch> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9f7b1d6f-ca62-4c6c-9cd5-37726e7857b7@lunn.ch> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230515_083510_024242_81C104B2 X-CRM114-Status: GOOD ( 19.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, May 15, 2023 at 03:58:09PM +0200, Andrew Lunn wrote: > > 2. XLGMII.. Looking at the XPCS driver, it's unclear whether Clause 73 > > AN gets used for this. A quick scan of IEEE 802.3 suggests that > > XLGMII doesn't have any support for any inband signalling, and it's > > just an intermediary protocol between the MAC (more specifically the > > RS, but for the purposes of this I'll just refer to MAC) and the > > attached PCS, and any autonegotiation happens after the XLGMII link. > > So isn't XLGMII then a generic PHY thing, not a phylink thing? Honestly, I'm really not sure. It feels more like an internal-SoC thing. See my last diagram why I think this. > Or am i not correctly understanding how > drivers/phy/marvell/phy-*-comphy.c and > drivers/phy/microchip/*_serdev.c fit into the overall picture? In the case of serdes-based protocols with an external PHY, the general structure we have is: ------------------------------+ SoC | +-----+ +-----+ +--------+ | +--------------+ | MAC +---+ PCS +--+ SERDES +------------+ Ethernet PHY +---- Media +-----+ +-----+ +--------+ | ^ +--------------+ ------------------------------+ | | PHY_INTERFACE_MODE_xxx has referred to this bit, and this is the bit where inband can occur. In the case of multi-rate implementations, there can be one of many different PCS that can be placed there, and the SERDES handles converting the data stream from the PCS into its appropriate electrical form, essentially covering the PMA and PMD functions. (That same SERDES block generally can also handle PCIe and SATA.) In the case of non-serdes based protocols, then it's essentially the same as the above, but with the PCS and SERDES blocks removed. For Fibre based connections: ------------------------------+ SoC | +-----+ +-----+ +--------+ | | MAC +---+ PCS +--+ SERDES +------------ Media +-----+ +-----+ +--------+ | ^ ------------------------------+ | | PHY_INTERFACE_MODE_xxx has referred to this bit, and 1000BASE-X runs negotiation on this. 10GBASE-R also used for fibre has no negotiation, but there's still the 10GBASE-R PCS and the 802.3 PMA/PMD are subsumed by the SERDES block. What I think seems to be the case with XPCS is: ------------------------------+ SoC | +-----+ +-----+ +--------+ | | MAC +---+ PCS +--+ SERDES +----------- Media +-----+ ^ +-----+ +--------+ | --------|---------------------+ | PHY_INTERFACE_MODE_xxx seems to be referring to this bit. When clause 73 negotiation is used, that happens where I've stated "media" above, and that's involved with negotiating backplane protocols e.g. 40GBASE-KR4, 40GBASE-CR4, 25GBASE-KR, 10GBASE-KR, 1000BASE-KX etc on the bit I've called "Media" above. However, we can also have this for a fibre link: ------------------------------+ SoC | +-----+ +-----+ +--------+ | | MAC +---+ PCS +--+ SERDES +----------- Fibre +-----+ ^ +-----+ +--------+ | ^ --------|---------------------+ | | | XLGMII 40GBASE-R Given that in this case, we'd want PHY_INTERFACE_MODE_xxx to say 40GBASE-R, using the existing PHY_INTERFACE_MODE_xxx to specify at where I've pointed XLGMII just makes things confused... but in the case above with clause 73 negotiation, we wouldn't have a standard PHY_INTERFACE_MODE_xxx specifier for the external "media" side because that's dependent on the result of the negotiation. So... this seems to be a right can of wriggly things. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel