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 EA193CFB448 for ; Mon, 7 Oct 2024 15:57:25 +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: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-Owner; bh=1W2GwgW+APmUS4pvv9gMoyqqnk6ovxCaiwBqGyMOiNA=; b=pWkFsprUtyQiGXtMJJPlQ95sb0 Z9c3a+fkk1enEowuYE8n2McQrvXCzODBWjsHrjMslZLLlEx8F8v7e3xfoktAemNpqDfEkTSa0ZyVo BRHaXl5fx9uTQCQeZsrCXu9LVyJIG5xW/XIeKo/079Nh1hEFMXUxMnrj1w93mneAnrTOZ7GBjuXoa xsRZNlBali1ZMiCsmwoYiQ7RQwdjoEkbWhoujtHpOxGvAmgAvT7OjnSzj7lpi/KcqdcB9Hos+ztBj BG6DhkAkb2+o7VpEfr+D9y3IKDNK3P9igFEW6Bkr0LAOxZgirVwwXfSa2mu8dvpYbtKrIPj5q9l/M P8UKFiLw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sxq6m-000000033Xt-0zFC; Mon, 07 Oct 2024 15:57:16 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1sxq5S-000000032mt-3SjZ for linux-arm-kernel@lists.infradead.org; Mon, 07 Oct 2024 15:55:56 +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=1W2GwgW+APmUS4pvv9gMoyqqnk6ovxCaiwBqGyMOiNA=; b=s/whtzDI77U86sqcQklzx7Vjyl Y3WDSHSOBwI1j+QSp0hsq1SIo/i+VW98U3RTEvrdsHV0P3qYMuetVPuEMv6O8pyFyzDpoec9c4jll U709R1dpaDCQFfSvpWYc8eMnGE++0QsvUHHnc13TcwYDS98nZ4hCZbBOYWlfDdQRrGRp8JyeaYd/p Oc6lqFcoHDzRJXrS75CB8rrPenvtSvKGTqQpsIptzgHO8l68eh7Dd8vU9kad5uCUmsuRZn26POhSs NoNULtNO9MhtScqXpmF+EiswXQO0i7+rdupBt4DEyL3p8UiT2nXwjyyYAhGluNJa1u+XgqqyAoT2g djExF07Q==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:56788) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1sxq3G-0005zY-1F; Mon, 07 Oct 2024 16:53:38 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.96) (envelope-from ) id 1sxq3B-0004KC-07; Mon, 07 Oct 2024 16:53:33 +0100 Date: Mon, 7 Oct 2024 16:53:32 +0100 From: "Russell King (Oracle)" To: Maxime Chevallier 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 =?iso-8859-1?Q?Beh=FAn?= , =?iso-8859-1?Q?K=F6ry?= Maincent , Oleksij Rempel Subject: Re: [PATCH net-next v2 0/9] Allow isolating PHY devices Message-ID: References: <20241004161601.2932901-1-maxime.chevallier@bootlin.com> <20241007122513.4ab8e77b@device-21.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241007122513.4ab8e77b@device-21.home> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241007_085554_891353_222389D0 X-CRM114-Status: GOOD ( 42.91 ) 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 On Mon, Oct 07, 2024 at 12:25:13PM +0200, Maxime Chevallier wrote: > 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. Looking at 802.3, there is no support for isolation in the clause 45 register set - the isolate bit only appears in the clause 22 BMCR. Clause 22 registers are optional for clause 45 PHYs. My reading of this is that 802.3 has phased out isolation support on the MII side of the PHY on more modern PHYs, so this seems to be a legacy feature. Andrew has already suggested that we should default to isolate not being supported - given that it's legacy, I agree with that. > > 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. You have given further details in other response to Andrew. I'll comment further there. > I will include that in the cover. Yes, it would be good to include all these details in the cover message so that it isn't spread out over numerous replies. > 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 ? I think the question should be: which MII interfaces can electrically support multi-drop setups. 22.2.4.1.6 describes the Clause 22 Isolate bit, which only suggests at one use case - for a PHY connected via an 802.3 defined connector which shall power up in isolated state "to avoid the possibility of having multiple MII output drivers actively driving the same signal path simultaneously". This connector only supports four data signals in each direction, which precludes GMII over this defined connector. However, it talks about isolating the MII and GMII signals in this section. Putting that all together, 802.3 suggests that it is possible to have multiple PHYs on a MII or GMII (which in an explanatory note elsewhere, MII means 100Mb/s, GMII for 1Gb/s.) However, it is vague. Now... I want to say more, but this thread is fragmented and the next bit of the reply needs to go elsewhere in this thread, which is going to make reviewing this discussion later on rather difficult... but we're being drip-fed the technical details. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!