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 988DFEEE245 for ; Fri, 13 Sep 2024 07:36:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type: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=/vDMD1mz7qag9tEUPclLr5THupOcTv6X+Brs4WZuFfQ=; b=H/pfLqQb+NPopBAMjI85q0E25S L869JuG30qlZQemar8C9epU2vIBRuo90N8Yo/u4bqsDm9LlwUe9fvLJ9R6ir9dEQlN0Ww3oOnIOBw cytAEKtD9mJoIViZm9ruWOFhALZFAOxQ4ASBuyYINUGkXHiCE4Gddl/cq55T/JTxXMrV1b32ZzOwn 3uS5zd9Gh8AbrK8eNBMxMaqY3jD9y6UoLu70CbSCiL/w94F9M+a98ZvFPhKYK4LLM9m2uoYd8wpKK 2+O5ljFzEqOE0TXYhDa8k83jNHK/YtZnK/jDnaAnpJJuABuw14OdAcrSuU+KRDQvjUqOblQmAhN+6 SvxFfbaQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sp0qc-0000000FAh2-1Wvj; Fri, 13 Sep 2024 07:36:06 +0000 Received: from relay7-d.mail.gandi.net ([217.70.183.200]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sp0pX-0000000FAZh-3RRO for linux-arm-kernel@lists.infradead.org; Fri, 13 Sep 2024 07:35:01 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 6A2AE20005; Fri, 13 Sep 2024 07:34:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1726212897; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/vDMD1mz7qag9tEUPclLr5THupOcTv6X+Brs4WZuFfQ=; b=ihMVstQ5VzodMRLaKFCwMp5j8g2iNPC21AvpGx5mswUpXCxHYSscXU5Mkz2A0GDX/DocYP p91hNIGOeDE5y+3zaAxn+9T4eDMF2tpnGJvqu8xxPHUnkXh98/OtCn70moyqsSqroxtWK0 xMLmC/HoIlrXeXIMkN4nasF3ZQllDuB51UQk+xRV130nf6j1ZgqQjAOV5C3XfOlDMajAFd yEXT/q4CcoLNOnNT+BbXGBV5NxMuMDKu6wWVcDwEFy/xpWKbjmY842IsDkuHD8RiFJ+8v8 c1MOTUW8+UxrDUxp+HQeODL4ujGpod8mMAxDrGeLYOcoJE10whV293T8+fZIyA== Date: Fri, 13 Sep 2024 09:34:53 +0200 From: Maxime Chevallier To: Florian Fainelli Cc: Andrew Lunn , davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, Jakub Kicinski , Eric Dumazet , Paolo Abeni , Russell King , linux-arm-kernel@lists.infradead.org, Christophe Leroy , Herve Codina , Heiner Kallweit , Vladimir Oltean , Marek =?UTF-8?B?QmVow7pu?= , =?UTF-8?B?S8O2cnk=?= Maincent , Oleksij Rempel Subject: Re: [PATCH net-next 0/7] Allow controlling PHY loopback and isolate modes Message-ID: <20240913093453.30811cb3@fedora.home> In-Reply-To: <8372fe02-110a-4fca-839a-a4fa6a2dea74@gmail.com> References: <20240911212713.2178943-1-maxime.chevallier@bootlin.com> <8372fe02-110a-4fca-839a-a4fa6a2dea74@gmail.com> Organization: Bootlin X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-GND-Sasl: maxime.chevallier@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240913_003500_461823_128D8C74 X-CRM114-Status: GOOD ( 28.28 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Andrew, Florian, On Thu, 12 Sep 2024 11:26:41 -0700 Florian Fainelli wrote: > On 9/12/24 11:21, Andrew Lunn wrote: > >> The loopback control from that API is added as it fits the API > >> well, and having the ability to easily set the PHY in MII-loopback > >> mode is a helpful tool to have when bringing-up a new device and > >> troubleshooting the link setup. > > > > We might want to take a step back and think about loopback some more. > > > > Loopback can be done at a number of points in the device(s). Some > > Marvell PHYs can do loopback in the PHY PCS layer. Some devices also > > support loopback in the PHY SERDES layer. I've not seen it for Marvell > > devices, but maybe some PHYs allow loopback much closer to the line? > > And i expect some MAC PCS allow loopback. > > > > So when talking about loopback, we might also want to include the > > concept of where the loopback occurs, and maybe it needs to be a NIC > > wide concept, not a PHY concept? > > Agreed, you can loop pretty much anywhere in the data path, assuming the > hardware allows it. For the hardware I maintain, we can loop back within > the MAC as close as possible from the interface to DRAM, or as "far" as > possible, within the MII signals, but without actually involving the PHY. > > Similarly, the PHY can loop as close as possible from the electrical > data lines, or as far as possible by looping the *MII pins, before > hitting the MAC. > > So if nothing else, we have at least 4 kinds of loopbacks that could be > supported, it is not clear whether we want to define all of those as > standardized "modes" within Linux, and let drivers implement the ones > they can, or if we just let drivers implement the mode they have, and > advertise those. Meaning your user experience could vary. Oleksji identified some loopback modes in TI PHYs, the PHYs have access to have even different sets of loopback modes / locations as well, to me it's hard to come-up with a list of all the possible loopback locations indeed. However, I don't think it's inconceivable to come-up with a list - that can be extented - of possible loopback spots. Making the loopback a NIC concept would indeed make sense here, where we would aggregate all possible loopback points within the NIC and PHY(s) combined, and having ways for MAC/PHYS to enumerate their loopback modes through a set of ethtoop ops. With that being said, is it OK if I split the loopback part out of that series ? From the comments, it looks like a complex-enough topic to be covered on its own, and if we consider the loopback as a NIC feature, then it doesn't really fit into the current work anymore. I am however happy to continue discussing that topic. Using loopback has proven to be most helpful several times for me when bringing-up devices. Thanks, Maxime