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 68009CFB440 for ; Mon, 7 Oct 2024 08:43:24 +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=YjJjYm1U3UwrwhBRK0WKJKYtopNlAlvdyEXIDZdRFuA=; b=QR245zbhcDWEijHf4nBatOZhAK GINkwm8u6e4f48dLsCpC849YubIaNq1mwv3F1kQBSRO5sLPLABZNVBOwXhHl79+5W+ozLa+azVfgD ZjSTIGCfpDg6YWps55Bb+xOZF22IfwEnQtt2O9hwRZ8E9C5pYxtc/j/du+hf2vr0VGlmEcabb6ih2 h9OfyKaS3LOe9GjaJ8QDRyAsf4SGzVfhxMdRL5wVvsqxxmgJbbGG34fP1adwzU76VAJfurxEOmvro mNNbFJlCGDdCu0fl+vPtugnFnnH0zOrKovYeW2c1jd3bBXljuJbXAJQ71RAIix0stWWdhlwN+jYUv ba0+gt9A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sxjKk-00000001oZY-03Sx; Mon, 07 Oct 2024 08:43:14 +0000 Received: from relay3-d.mail.gandi.net ([2001:4b98:dc4:8::223]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1sxjIe-00000001nzc-3Njj for linux-arm-kernel@lists.infradead.org; Mon, 07 Oct 2024 08:41:06 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 88D366000A; Mon, 7 Oct 2024 08:41:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1728290462; 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=YjJjYm1U3UwrwhBRK0WKJKYtopNlAlvdyEXIDZdRFuA=; b=fed6/b/KZ0zpimBoYUijOJX9VPpnoYkEZ57MkJ/kMDZNwhhVGTZEPANMcaTtOEAhqxZcYz 8tUdLHAnwFv388rIZPsol5y3n9j+y/IIQhtDS5h/88sNzG8XQAgjIw4IUEJeL3aOxc1ndq XF+DNiuSHkF5slxT/PQd85PzpKHbHdHRpENj8hUXA7jySvrUd9dDsmxKfS6mEHdc+egYFm v0k3ch38XWLzDwTKJ2jBg+Jiho7jI+0m8xKL7NBoDG/Kjv8iTkDfvdit2imfOAU5vxMWAQ ps8aPLWtEplIULhASHEz7DIdam+1ZNHRFI2nlS4oeOsknbB0KexGAmTxXf6fEQ== Date: Mon, 7 Oct 2024 12:37:51 +0200 From: Maxime Chevallier To: "Russell King (Oracle)" 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 =?UTF-8?B?QmVow7pu?= , =?UTF-8?B?S8O2cnk=?= 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: <20241007123751.3df87430@device-21.home> In-Reply-To: References: <20241004161601.2932901-1-maxime.chevallier@bootlin.com> <20241004161601.2932901-8-maxime.chevallier@bootlin.com> <4d4c0c85-ec27-4707-9613-2146aa68bf8c@lunn.ch> 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_014105_338640_15A3FA42 X-CRM114-Status: GOOD ( 28.78 ) 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, Russell, On Fri, 4 Oct 2024 20:02:05 +0100 "Russell King (Oracle)" wrote: [...] > > This seems overly simplistic to me. Don't you need to iterate over all > > the other PHYs attached to this MAC and ensure they are isolated? Only > > one can be unisolated at once. > > > > It is also not clear to me how this is going to work from a MAC > > perspective. Does the MAC call phy_connect() multiple times? How does > > ndev->phydev work? Who is responsible for the initial configuration, > > such that all but one PHY is isolated? > > > > I assume you have a real board that needs this. So i think we need to > > see a bit more of the complete solution, including the MAC changes and > > the device tree for the board, so we can see the big picture. > > Also what the ethernet driver looks like too! > > One way around the ndev->phydev problem, assuming that we decide that > isolate is a good idea, would be to isolate the current PHY, disconnect > it from the net_device, connect the new PHY, and then clear the isolate > on the new PHY. Essentially, ndev->phydev becomes the currently-active > PHY. It seems I am missing details in my cover and the overall work I'm trying to achieve. This series focuses on isolating the PHY in the case where only one PHY is attached to the MAC. I have followup work to support multi-PHY interfaces. I will do my best to send the RFC this week so that you can take a look. I'm definitely not saying the current code supports that. To tell you some details, it indeed works as Russell says, I detach/re-attach the PHYs, ndev->phydev is the "currently active" PHY. I'm using a new dedicated "struct phy_mux" for that, which has : - Parent ops (that would be filled either by the MAC, or by phylink, in the same spirit as phylink can be an sfp_upstream), which manages PHY attach / detach to the netdev, but also the state-machine or the currently inactive PHY. - multiplexer ops, that implement the switching logic, if any (drive a GPIO, write a register, this is in the case of real multiplexers like we have on some of the Turris Omnia boards, which the phy_mux framework would support) - child ops, that would be hooks to activate/deactivate a PHY itself (isoalte/unisolate, power-up/power-down). I'll send the RFC ASAP, I still have a few rough edges that I will mention in the cover. > However, I still want to hear whether multiple PHYs can be on the same > MII bus from a functional electrical perspective. Yup, I have that hardware. Thanks, Maxime