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 6BE4FC54798 for ; Sat, 9 Mar 2024 05:27:28 +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:MIME-Version:References:In-Reply-To: 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=tfDd1Hd7tXzB3kmhhIbYhfAlYXEoD8I7HxjXON2mdRQ=; b=PlIWL5HZkkiHJK w3HC0QRf4DqXnA8KdXhiRBG0sPX1pIt71/0Nz4LBeSgYM8PZ0r3pifROoCeGZwUVD0hPVNdJ47uyZ Nd1lU3b8elvHQm5EYnboOGFGDNGG5LADyL0HdjAfrIY5MuIfPHS2YBGT2L1PQahuQo7s3lu3oOh62 /NazQuztlk/R2iIqqfJ5VuPTEYoXFzJ7U6pfuBYU5W2da1CP5BxNLJGCevu+ipskLBPjBbLF5vlfL 9hmAbaaUFKqUuVNQbPF90QKpV/HYZ/p74XKc2jaj8MRox4r920nLOC+WA/pWr6/R9S2wtX41UVvJF zoqnifBSzts4zqlp5jGQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ripEm-0000000CZHL-3x0D; Sat, 09 Mar 2024 05:27:12 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ripEk-0000000CZGo-1CwY for linux-arm-kernel@lists.infradead.org; Sat, 09 Mar 2024 05:27:12 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id D0BA6CE291A; Sat, 9 Mar 2024 05:27:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E977C433F1; Sat, 9 Mar 2024 05:27:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709962026; bh=kKwe57YoGVcoyss0ap390jlp9pG9+fYB0DFZcYPltOE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=b2ZGK//sZVoGCK02BOQX1N2SWoVYhLNLuWKRrK4U2EvKKX2lkalC9BAVxWqqfHz63 Y1oUqjkEcMiGdHBElb2WXygtEzxODSEpDjkOSPlXpnwdkx54xnG9hnxgSTmEXcZxnP 0KvUJ1QY4H4WYpPZV+peQ/SXK8vH70uohDLr/WE39uHCNnPgrW1kkMNhOqpHZEiDwI SyrMGz6xMePCwJgmd6+XflwN809gbAHED+OHMZTx1HlG4BQd+0ND84XmgKrmlcLJh1 CBrJPerRgAFKe158Twx8qOSO4IXKrbSJyzIpYd4Zn+45vO+X5/bpg1fVXoJbLlUKao SyKUcdJ7uvKJw== Date: Fri, 8 Mar 2024 21:27:04 -0800 From: Jakub Kicinski To: Maxime Chevallier Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, Andrew Lunn , Eric Dumazet , Paolo Abeni , Russell King , linux-arm-kernel@lists.infradead.org, Christophe Leroy , Herve Codina , Florian Fainelli , Heiner Kallweit , Vladimir Oltean , =?UTF-8?B?S8O2cnk=?= Maincent , Jesse Brandeburg , Jonathan Corbet , Marek =?UTF-8?B?QmVow7pu?= , Piergiorgio Beruto , Oleksij Rempel , =?UTF-8?B?Tmljb2zDsg==?= Veronese , Simon Horman , mwojtas@chromium.org Subject: Re: [PATCH net-next v10 13/13] Documentation: networking: document phy_link_topology Message-ID: <20240308212704.02766ff6@kernel.org> In-Reply-To: <20240304151011.1610175-14-maxime.chevallier@bootlin.com> References: <20240304151011.1610175-1-maxime.chevallier@bootlin.com> <20240304151011.1610175-14-maxime.chevallier@bootlin.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240308_212710_777161_45FBCA7B X-CRM114-Status: GOOD ( 14.57 ) 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 We should :ref: to this doc from the PHY_GET in the ethtool one as well? On Mon, 4 Mar 2024 16:10:09 +0100 Maxime Chevallier wrote: > +An Ethernet Interface from userspace's point of view is nothing but a interface > +:c:type:`struct net_device `, which exposes configuration options > +through the legacy ioctls and the ethool netlink commands. The base assumption ethtool > +when designing these configuration channels were that the link looked nit: s/channels/APIs/ channels sometimes means IRQs/queues in netdev :S s/looked/looks/ > +something like this :: s/this// > + +-----------------------+ +----------+ +--------------+ > + | Ethernet Controller / | | Ethernet | | Connector / | > + | MAC | ------ | PHY | ---- | Port | ---... to LP > + +-----------------------+ +----------+ +--------------+ > + struct net_device struct phy_device > + > +Commands that needs to configure the PHY will go through the net_device.phydev > +field to reach the PHY and perform the relevant configuration. > + > +This assumption falls apart in more complex topologies that can arise when, > +for example, using SFP transceivers (although that's not the only specific case). s/specific/such/ > +Here, we have 2 basic scenarios. Either the MAC is able to output a serialized > +interface, that can directly be fed to an SFP cage, such as SGMII, 1000BaseX, > +10GBaseR, etc. The "Either" makes me expect and "or" at some state in this paragraph.. > +The link topology then looks like this (when an SFP module is inserted) :: > + > + +-----+ SGMII +------------+ > + | MAC | ------- | SFP Module | > + +-----+ +------------+ > + > +Knowing that some modules embed a PHY, the actual link is more like :: > + > + +-----+ SGMII +--------------+ > + | MAC | -------- | PHY (on SFP) | > + +-----+ +--------------+ > + > +In this case, the SFP PHY is handled by phylib, and registered by phylink through > +its SFP upstream ops. > + > +Now some Ethernet controllers aren't able to output a serialized interface, so > +we can't directly connect them to an SFP cage. However, some PHYs can be used s/However, some/In such cases, certain/ > +as media-converters, to translate the non-serialized MAC MII interface to a > +serialized MII interface fed to the SFP :: > + > + +-----+ RGMII +-----------------------+ SGMII +--------------+ > + | MAC | ------- | PHY (media converter) | ------- | PHY (on SFP) | > + +-----+ +-----------------------+ +--------------+ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel