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 898B7C4332F for ; Mon, 17 Oct 2022 13:05:23 +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:In-Reply-To:MIME-Version:References: 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=uiSfL9RN1pjC+iSJCA7xnvU5HrUDbyhH5emY6H4vaeg=; b=d7Rn3/jgtuXVfN c951MAwRP14ZLw/8k+GSZjwIpUEwB0pxUTzbHf0biZAKZITtMxzrq6Y+i9QrTmlXbaQGGjh/KsFSq MJ4J5UlEE6R5Y/Gx5nL0HvBkoSqNVHAPKRxY3GQd5ee0U59r3VqfEOkDuj09cLdlKFk19bS0qpeWN w2v3ynjSDgIVj6OUsltuKJY/jcKzyrukY6nYekGzgTCU2ACjGtzNUkDIj9rc8m3DmxzEfSupXytoW 7tCD/CcQc2Icj0In0v4cZIZY+ob7YA89xxuzYnod065/bizwpKZ854AOCYYDMWe00gSJ4JeZ7Q4tI Oe8Jkns3sXW2vESbaxvw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1okPmy-00C2iZ-Oi; Mon, 17 Oct 2022 13:04:16 +0000 Received: from vps0.lunn.ch ([185.16.172.187]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1okPmv-00C2YM-94 for linux-arm-kernel@lists.infradead.org; Mon, 17 Oct 2022 13:04:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=UKBi0FNN9u33tTEw8/XVN/EAYN1acJAaABnam46l1A8=; b=3+B7ffxagQ6K3ft7ZCWaYK6ydi WqqcYcfeLUc294sTy2OO7w8pgSoijuT8dJukiuiwCfD7PAx6lH0At1GY7ITLLENcOvjpwPeMt+/CL cQ8Xn8XZ6J62gmJxBIj6mb4+qRpdyhIpV6x47ZFEwRCJIU2qeT04RKf9rvBl3IN0QJbc=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1okPmh-002E5o-86; Mon, 17 Oct 2022 15:03:59 +0200 Date: Mon, 17 Oct 2022 15:03:59 +0200 From: Andrew Lunn To: "Russell King (Oracle)" Cc: Maxime Chevallier , 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: References: <20221017105100.0cb33490@pc-8.home> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221017_060413_347312_0813ED8E X-CRM114-Status: GOOD ( 21.04 ) 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 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. 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? Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel