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 F0198CFB440 for ; Mon, 7 Oct 2024 08:28:49 +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=RDlA1X7tGs3142aa6D/JEOTJoAWg3dIH40lOQBP02kw=; b=s2ueThv2umU22pUuOoEjlJW+0O yUI/cxKe2gIIYUX59GnmOWdPdf64dC6UrBtpnYlWqToKdkuHth6El8ud845MGGRTuhl4ZSRLxLr1r sE3StNl1CZkFIKec1yi3tcAsyaZx90Mcis2z4gdm4peqtIgU0oWcuA11rWFJjm+owlBJD6StgZMGl 0HKKhAgDUBHcADx835nWHcicYb+MO6AQe9U8WkbW4SaCxL/nG3d+WdoivZoRpprtJlMm7y8jnJxPI viwiaMqeCyASN6uKKGmlTWbBm+IMY/2DYCigpJUjCVtVOfJ7GM6k4fuJewtPt8Dsw7Zr/jHawO7H3 5UiXnvhw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sxj6f-00000001lox-2L7u; Mon, 07 Oct 2024 08:28:41 +0000 Received: from relay8-d.mail.gandi.net ([217.70.183.201]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1sxj5N-00000001lbT-35GW for linux-arm-kernel@lists.infradead.org; Mon, 07 Oct 2024 08:27:23 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id D08B81BF204; Mon, 7 Oct 2024 08:27:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1728289637; 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=RDlA1X7tGs3142aa6D/JEOTJoAWg3dIH40lOQBP02kw=; b=R3fdxtJIxcXhhUkm9VQMwfMFsiGqQYjaeiAeB7qGedH07dwtd6wXyG+sTwrnE7YrHqeFLw 45ZzuDHNCPE5LUmdMoMzvT53VeJiGgav2zbgQvI8W9WVb4kiPHpkrew2SBgT1BXmooyg9N Fuq+EjkkcIPcE2DY4kYYkgMUoIbGJ6bvnv7ENLtiV5dzZJbViyOSnTpr0L8OiKse8ER1Le FccFecqNRUgKXPGldbmHkEInA2J6Gx6nIXfs4YEX+M25zzxnVMCeJZhrdvi9h9PipP3TTW WDb9i9HX2Ec5tpUpos4rpgORi9AUz7cLDVLRg2Cl9Jgj6w91jPtKm0qX7Cm4ew== Date: Mon, 7 Oct 2024 12:25:13 +0200 From: Maxime Chevallier To: "Russell King (Oracle)" Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, Andrew Lunn , Jakub Kicinski , Eric Dumazet , Paolo Abeni , linux-arm-kernel@lists.infradead.org, Christophe Leroy , Herve Codina , Florian Fainelli , Heiner Kallweit , Vladimir Oltean , Marek =?UTF-8?B?QmVow7pu?= , =?UTF-8?B?S8O2cnk=?= Maincent , Oleksij Rempel Subject: Re: [PATCH net-next v2 0/9] Allow isolating PHY devices Message-ID: <20241007122513.4ab8e77b@device-21.home> In-Reply-To: References: <20241004161601.2932901-1-maxime.chevallier@bootlin.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-20241007_012722_074934_65D976BB X-CRM114-Status: GOOD ( 24.47 ) 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 Russell On Fri, 4 Oct 2024 18:02:25 +0100 "Russell King (Oracle)" wrote: > I'm going to ask a very basic question concerning this. > > Isolation was present in PHYs early on when speeds were low, and thus > electrical reflections weren't too much of a problem, and thus star > topologies didn't have too much of an effect. A star topology is > multi-drop. Even if the PCB tracks go from MAC to PHY1 and then onto > PHY2, if PHY2 is isolated, there are two paths that the signal will > take, one to MAC and the other to PHY2. If there's no impediance match > at PHY2 (e.g. because it's in high-impedance mode) then that > transmission line is unterminated, and thus will reflect back towards > the MAC. > > As speeds get faster, then reflections from unterminated ends become > more of an issue. > > I suspect the reason why e.g. 88x3310, 88E1111 etc do not support > isolate mode is because of this - especially when being used in > serdes mode, the topology is essentially point-to-point and any > side branches can end up causing data corruption. I suspect indeed that this won't work on serdes interfaces. I didn't find any reliable information on that, but so far the few PHYs I've seen seem to work that way. The 88e1512 supports that, but I was testing in RGMII. > > So my questions would be, is adding support for isolation mode in > PHYs given todays network speeds something that is realistic, and > do we have actual hardware out there where there is more than one > PHY in the bus. If there is, it may be useful to include details > of that (such as PHY interface type) in the patch series description. I do have some hardware with this configuration (I'd like to support that upstream, the topology work was preliminary work for that, and the next move would be to send an RFC for these topolopgies exactly). I am working with 3 different HW platforms with this layout : /--- PHY | MAC -| phy_interface_mode == MII so, 100Mbps Max. | \--- PHY and another that is similar but with RMII. I finally have one last case with MII interface, same layout, but the PHYs can't isolate so we need to make sure all but one PHYs are powered-down at any given time. I will include that in the cover. Could we consider limiting the isolation to non-serdes interfaces ? that would be : - MII - RMII - GMII - RGMII and its -[TX|RX] ID flavours - TBI and RTBI ?? (I'm not sure about these) Trying to isolate a PHY that doesn't have any of the interfaces above would result in -EOPNOTSUPP ? Thanks, Maxime