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 AEC45C4332F for ; Tue, 18 Oct 2022 11:47:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id: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=HPxhSQYB2g3oxMIEAI6qB4bj+extpBpeFDzS93PzpYA=; b=kr9tOi7rNuS9jg KgzMpdNcgJE/yPFflABpZZkPMOgEsTMFd1UY9Iz63w2QvEqp+e9at7JAw5cqhTe5G6cvlx59fncAo gaWdHBJ21ZWYq+Db+OeOGEN2mCSj4iOr9N19rvMy5PZNokmGXXn/4+/ybdVrYr5jY7W1QGe2i4Dy8 ZGoMrbt+DwjSgYzj4A8l070U0lhSEmhcZI6nLacTJnccrAJZqDqAK5gxnqfsxz3fE+1Xy106mz+53 kyDR2YfqgCIkNX/Z8WfuhUK54+E+I81GVRw9JBRfrbu2kPIMZbeONj7l1KhRCENfEZLWBTpklNHLU ZMKFxZdvRVny8+OqXx5A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1okl2o-006CK8-Sz; Tue, 18 Oct 2022 11:46:03 +0000 Received: from relay3-d.mail.gandi.net ([2001:4b98:dc4:8::223]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1okl2l-006CDB-0i for linux-arm-kernel@lists.infradead.org; Tue, 18 Oct 2022 11:46:01 +0000 Received: (Authenticated sender: maxime.chevallier@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 21B2F60008; Tue, 18 Oct 2022 11:45:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1666093553; 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=foqT3NAnuG1A67EIZZREcFShvqHNGhgtMHvlC41QDNQ=; b=jE87XLA/2qSt48gbFPp4XbsbR24R1mdE943v/8/bHn6VGBZcA6BiXclBs6rg9YEZkuCvxo 3Au1A7xZS46mxMGoD6SzXp7Du50O6gGGwqRwv5ig0b3+QhSZmR5wfMl9BW0aHbuXzSZ2ff hcxDz6rb1HrRfso6BQHmrf2Ur1wqbKL7s00BwKn7s1RgID2ZXdGgHGjo15AVb71p13jQt6 VOnP1oXo/G9aSKG13ogKSoI+A5FeSiR0DWYHL1C6VAgOHj8gT6bZrM4Qc8kkHi+IA7mClr p34V0FvtlXWrrK5ODytYe+F7+2T9v0T0V4v/hw6C96A13gH5uLswAwpcSB4AGg== Date: Tue, 18 Oct 2022 13:45:47 +0200 From: Maxime Chevallier To: Andrew Lunn Cc: "Russell King (Oracle)" , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Petazzoni , Antoine Tenart , "David S. Miller" , Heiner Kallweit , Florian Fainelli , Vivien Didelot , Tobias Waldekranz , Oleksij Rempel , Jakub Kicinski Subject: Re: Multi-PHYs and multiple-ports bonding support Message-ID: <20221018134547.18a7e36e@pc-8.home> In-Reply-To: References: <20221017105100.0cb33490@pc-8.home> Organization: Bootlin X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221018_044559_398426_2B947839 X-CRM114-Status: GOOD ( 32.36 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Andrew, On Mon, 17 Oct 2022 15:03:59 +0200 Andrew Lunn wrote: > On Mon, Oct 17, 2022 at 10:24:49AM +0100, Russell King (Oracle) wrote: > > On Mon, Oct 17, 2022 at 10:51:00AM +0200, Maxime Chevallier wrote: > > > 2) Changes in Phylink > > > > > > This might be the tricky part, as we need to track several ports, > > > possibly connected to different PHYs, to get their state. For > > > now, I haven't prototyped any of this yet. > > > > The problem is _way_ larger than phylink. It's a fundamental > > throughout the net layer that there is one-PHY to one-MAC > > relationship. Phylink just adopts this because it is the > > established norm, and trying to fix it is rather rediculous without > > a use case. > > > > See code such as the ethtool code, where the MAC and associated > > layers are# entirely bypassed with all the PHY-accessing ethtool > > commands and the commands are passed directly to phylib for the PHY > > registered against the netdev. > > We probably need to model the MII MUX. We can then have netdev->phydev > and netdev->sfp_bus point to the MUX, which then defers to the > currently active PHY/SFP for backwards compatibility. Additionally, > for netlink ethtool, we can add a new property which allows a specific > PHY/SFP hanging off the MUX to be addressed. That's a good idea ! I find it pretty elegant indeed, and would be the right place to implement the switching logic too. > Modeling the MUX probably helps us with the overall architecture. As > Maxime described, there are at least two different architectures: the > MUX is between the MAC and the PHYs, and the MUX is inside the PHY > between the host interface and the line interfaces. There are at least > 4 PHYs like this. > > We also have Russells problem of two PHYs on one path. It would be > nice to solve that at the same time, which the additional identifier > attribute should help solve. > > I would probably start this work from the uAPI. How does the uAPI > work? >From the doc of struct ethtool_link_setting, there seems to be an attempt to support that already : "* Some hardware interfaces may have multiple PHYs and/or physical * connectors fitted or do not allow the driver to detect which are * fitted. For these interfaces @port and/or @phy_address may be * writable, possibly dependent on @autoneg being %AUTONEG_DISABLE. * Otherwise, attempts to write different values may be ignored or * rejected. " https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/ethtool.h#L2047 However, this doesn't allow to enumerate clearly the interfaces available, and it relies on the mdio address + port. This doesn't address the chained PHYs as we don't have a clear view of the topology (but do we need to ?) I like very much the concept of having a way to address the interfaces or the parts of the link chain. Could we introduce a new ethtool cmd, allowing to enumerate the ports and discover the topology, and another one to get an equivalent of the ethtool_link_settings for each block in the chain ? I'll try to prototype a few things to get a clearer picture... Thanks a lot for your input, Maxime > Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel