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 65857C433FE for ; Tue, 18 Oct 2022 08:03:18 +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=z/P/EZVxxCxYf3iK8nmx52XlJ6mrTq0Z+6sE1+wQgHM=; b=mnsxewmqblSNfh ZiCInkuv0ljrcx6krOLqjySaAgVzUqavJ+FtwGXMbaPXlCpCfYAzW1k1fyYB4iRv9ym97xpNL556Q OLdiL+9mRuj9JwugGi2jKW/vBICsM3Vb1hhpKnivdgMsFJzvCZdXK1IMowS7YAq+L+bjNFBkpae5B iJBUXWzsnBevtd6Qv4+XtAmVU0Vlwi347BYpmLqh6RelWrYp1dCzobKtoAxLt1sLJ3eH+/x9pK039 tMBEKKD7+GNlQ0Ye/hA6C21P2uIYXw9u9X3irqxWcs2cFf3mEHNUZOUwDpNPICmrdIQwSQvbRpzQX xa11dlNevnWPtTkMKSlg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1okhYI-004EyC-6Y; Tue, 18 Oct 2022 08:02:18 +0000 Received: from relay2-d.mail.gandi.net ([217.70.183.194]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1okhYE-004Esb-SY for linux-arm-kernel@lists.infradead.org; Tue, 18 Oct 2022 08:02:16 +0000 Received: (Authenticated sender: maxime.chevallier@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id AA0C34000A; Tue, 18 Oct 2022 08:02:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1666080130; 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=XJWJU9lKQmbYfvTpjAh7Zx79mWxmQZB+hipoTlechIg=; b=H6qAHFYYOjLQZsJwpPtIgSYs+cuP4sLLwOiPDrMIk45Xl5gsS4LBzcokBKuWNZWj6BzzC0 p2Qxb1eUmny7+/3Ax9wogscY/uQ4RxHWFcFERuLd/wMwFU4xaWzkeyCbLbnZ/mHmVRGDM9 FylOyZa/tyGyAy2T5qtSuasJgzBev/hVvC7bZb6nP6bOsw1jc9idzITNIbY/njzv59Cbp0 76qJgDWQ98B/yLYtpWNNq01iSFi6HdskF31V84WBJ7PruSctaQ96+klUy8JjZLAwCKlwdM QPNp7SWnkcqCNY6pNecTZKsOL0SsrL3kinckRHXl6tEoeBpkr8CkokQR+NWkwQ== Date: Tue, 18 Oct 2022 10:02:05 +0200 From: Maxime Chevallier To: "Russell King (Oracle)" Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Petazzoni , Antoine Tenart , "David S. Miller" , Heiner Kallweit , Florian Fainelli , Vivien Didelot , Andrew Lunn , Tobias Waldekranz , Oleksij Rempel , Jakub Kicinski , Jiri Pirko Subject: Re: Multi-PHYs and multiple-ports bonding support Message-ID: <20221018100205.000ac57d@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_010215_219665_FDE07343 X-CRM114-Status: GOOD ( 28.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 Hello Russell, On Mon, 17 Oct 2022 10:24:49 +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 do have use cases though - consider a setup such as the mcbin with > the 3310 in SGMII mode on the fibre link and a copper PHY plugged in > with its own PHY - a stacked PHY situation (we don't support this > right now.) Which PHY should the MII ioctls, ethtool, and possibly the > PTP timestamp code be accessing with a copper SFP module plugged in? > > This needs to be solved for your multi-PHY case, because you need to > deal with programming e.g. the link advertisement in both PHYs, not > just one - and with the above model, you have no choice which PHY gets > the call, it's always going to be the one registered with the netdev. > > The point I'm making is that you're suggesting this is a phylink > issue, but it isn't, it's a generic networking layering bypass issue. > If the net code always forwarded the ethtool etc stuff to the MAC and > let the MAC make appropriate decisions about how these were handled, > then we would have a properly layered approach where each layer can > decide how a particular interface is implemented - to cope with > situations such as the one you describe. I agree with all you say, and indeed this problem is a good opportunity IMO to consider the other use-cases like the one you mention and come up with a nice solution. My intention was never to imply that this is a phylink issue. Quite the contrary, what I'm saying is that phylink as it is would need to take this into account, by extending it, with all the above-mentionned use-cases. When you mention that ethtool bypasses the MAC layer and talks to phylib, since phylink has the overall view of the link, and abstracts the phy away from the MAC, I would think this is a good place to manage this tree of PHYs/ports, but on the other hand that's adding quite a lot of complexity to phylink. Maxime _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel