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 0E174CFB449 for ; Mon, 7 Oct 2024 16:13:44 +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=tOIWOo9QQODjzaxMqM3UFZVHDTlN3XAQg5QyI1UoT+8=; b=pWKk+Ju0sfTcMn3oviJWbk9giO d2f+FFeSwCX7OrKTDRy7S2/+vPQQRfZGo5Q/SYtAxMhjyKjwZfRX/YvN0rxa5AtHufhKl3i/YgGe3 v6dIzymPf+ePZRJ287t7GOWi/MCcqR6wa3l/MamEOuz0yxSFLm2ihQv78UsR074v35i89O8NJ6SoJ u/wLKcY8QtTZoOfb41mcswlFW4mlq8TiOqDyK3qzvCpF86EzPqDv9OVJxiGOOTv3hPzv34jZs7eVl fo1joL2ZZfD/K9IQew2YqC+QEU/Wk7Iz98hW6wOqOSWFma2y2pcPnzfO01tAFxy1aucy5USN6W5TF xAuSGi5w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sxqMU-0000000370E-32Mr; Mon, 07 Oct 2024 16:13:30 +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 1sxqKH-000000036Iz-1Rb8 for linux-arm-kernel@lists.infradead.org; Mon, 07 Oct 2024 16:11:15 +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=tOIWOo9QQODjzaxMqM3UFZVHDTlN3XAQg5QyI1UoT+8=; b=rwm+tfbYKoATZHUThmBlYrHhVo RKvrKxKAFA1ek+CFZ5UWHLUqfbcSQjq/AezsoSwL5H1CMo0xCTMCMkxj5tDcrqzAcyb8ygsgeU5S2 pFe+BbW98E1RY0B/MtZ00aS4mOeH9rV98n0qm23PnjPtURuJzH5G9s+eiuYV7fXKuCABzf5i/ohVQ /FIN7HxXaxtf+/HEfwyNh/MKcAVEIat+GNg5R6AJ44Es6KeWEhzgpkDLKLg8kyphasi9pjcTYWg+V 9jzM9rqLeDRyGKJZTFunmosIsULh+StBly/D3oOzILNbxq9Ho3MNd8mxTlvK6H/4UxrkHPo8cB8eS 6mCcakTg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:46640) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1sxqK4-00062G-1L; Mon, 07 Oct 2024 17:11:00 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.96) (envelope-from ) id 1sxqK0-0004LE-1f; Mon, 07 Oct 2024 17:10:56 +0100 Date: Mon, 7 Oct 2024 17:10:56 +0100 From: "Russell King (Oracle)" To: Maxime Chevallier 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 , 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 7/9] net: phy: introduce ethtool_phy_ops to get and set phy configuration Message-ID: References: <20241004161601.2932901-1-maxime.chevallier@bootlin.com> <20241004161601.2932901-8-maxime.chevallier@bootlin.com> <4d4c0c85-ec27-4707-9613-2146aa68bf8c@lunn.ch> <20241007123751.3df87430@device-21.home> <6bdaf8de-8f7e-42db-8c29-1e8a48c4ddda@lunn.ch> <20241007154839.4b9c6a02@device-21.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241007154839.4b9c6a02@device-21.home> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241007_091113_434047_CF425CAA X-CRM114-Status: GOOD ( 29.81 ) 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 03:48:39PM +0200, Maxime Chevallier wrote: > Sure thing. There are multiple devices out-there that may have multiple > PHYs accessible from the MAC, through muxers (I'm trying to be generic > enough to address all cases, gpio muxers, mmio-controlled muxers, etc.), > but let me describe the HW I'm working on that's a bit more problematic. > > The first such platform I have has an fs_enet MAC, a pair of LXT973 > PHYs for which the isolate mode doesn't work, and no on-board circuitry to > perform the isolation. Here, we have to power one PHY down when unused : > > /--- LXT973 > fs_enet -- MII--| > \--- LXT973 > > > The second board has a fs_enet MAC and a pair of KSZ8041 PHYs connected > in MII. > > The third one has a pair of KSZ8041 PHYs connected to a > ucc_geth MAC in RMII. > > On both these boards, we isolate the PHYs when unused, and we also > drive a GPIO to toggle some on-board circuitry to disconnect the MII > lines as well for the unused PHY. I'd have to run some tests to see if > this circuitry could be enough, without relying at all on PHY > isolation : > > /--- KSZ8041 > | > MAC ------ MUX > | | > to SoC <-gpio--/ \--- KSZ8041 > > > One point is, if you look at the first case (no mux), we need to know > if the PHYs are able to isolate or not in order to use the proper > switching strategy (isolate or power-down). > > I hope this clarifies the approach a little bit ? What I gather from the above is you have these scenarios: 1) two LXT973 on a MII bus (not RMII, RGMII etc but the 802.3 defined MII bus with four data lines in each direction, a bunch of control signals, clocked at a maximum of 25MHz). In this case, you need to power down each PHY so it doesn't interfere on the MII bus as the PHY doesn't support isolate mode. 2) two KSZ8041 on a MII bus to a multiplexer who's exact behaviour is not yet known which may require the use of the PHYs isolate bit. I would suggest that spending time adding infrastructure for a rare scenario, and when it is uncertain whether it needs to be used in these scenarios is premature. Please validate on the two KSZ8041 setups whether isolate is necessary. Presumably on those two KSZ88041 setups, the idea is to see which PHY ends up with media link first, and then switch between the two PHYs? Lastly, I'm a little confused why someone would layout a platform where there are two identical PHYs connected to one MAC on the same board. I can see the use case given in 802.3 - where one plugs in the media specific attachment unit depending on the media being used - Wikipedia has a photo of the connector on a Sun Ultra 1 - but to have two PHYs on the same board doesn't make much sense to me. What is trying to be achieved with these two PHYs on the same board? It's got me wondering whether the platform you have is some kind of development board, and the manufacturer feels the need to provide a network socket on either end of the board because folk don't have a long enough ethernet cable to reach the other end! :D -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!