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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B4DEC433FE for ; Tue, 22 Nov 2022 09:39:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233299AbiKVJjD (ORCPT ); Tue, 22 Nov 2022 04:39:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233300AbiKVJiy (ORCPT ); Tue, 22 Nov 2022 04:38:54 -0500 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A12FB4FF9D for ; Tue, 22 Nov 2022 01:38:51 -0800 (PST) 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=5BdpH7uCstx53nBFWAVFA9aKrhAthuDfvtbFgzqJR5I=; b=Poxc0h5fooDKduILz5aVeGC/HR iMNiUMe57yyHuniqAH3DC8cjyxjeFH97nLpU5/xdJ16CeUwqxZoo8W7eLvt5QJh9jQM0oEE5s0VVi FDF4b09FMgAKU3pzNtWn9dL0vC3Uw6lOBagf9MRIWVpCYWtW/gGvl6jA1NdamB67tY7OGl2k3qo5u djMs0xZm0LHO89H6ZB3vpVU3ejdjXwrERW2eHjhOPnCmT5k/4rnDBBBLtqOjAr4zj0usHAETB8C4c FrczrPShJO/8n7K9woqWIoljtjEvdbEMTJ9zjTs8v1iPlUXeaSrg8WqWUyBcWCXRLPqwJ34im/Z1W T5yCl55Q==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:35376) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oxPjr-0001HE-1z; Tue, 22 Nov 2022 09:38:47 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1oxPjn-0003DK-GO; Tue, 22 Nov 2022 09:38:43 +0000 Date: Tue, 22 Nov 2022 09:38:43 +0000 From: "Russell King (Oracle)" To: Vladimir Oltean Cc: netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Heiner Kallweit , Andrew Lunn , Florian Fainelli , UNGLinuxDriver@microchip.com, bcm-kernel-feedback-list@broadcom.com, Madalin Bucur , Camelia Groza , Claudiu Manoil , Ioana Ciornei , Maxim Kochetkov , Sean Anderson , Antoine Tenart , Michael Walle , Raag Jadav , Siddharth Vadapalli , Ong Boon Leong , Colin Foster , Marek Behun Subject: Re: [PATCH v4 net-next 3/8] net: phy: bcm84881: move the in-band capability check where it belongs Message-ID: References: <20221118000124.2754581-1-vladimir.oltean@nxp.com> <20221118000124.2754581-4-vladimir.oltean@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221118000124.2754581-4-vladimir.oltean@nxp.com> Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Nov 18, 2022 at 02:01:19AM +0200, Vladimir Oltean wrote: > Now that there is a generic interface through which phylink can query > PHY drivers whether they support various forms of in-band autoneg, use > that and delete the special case from phylink.c. > > Signed-off-by: Vladimir Oltean I think I'd prefer to see patch 2 and patch 3 first in this series (patch 3 without the phylink change). Possibly followed by other PHY driver patches adding the validate_an_inband function, but that's not important. Then the next patch can be patch 1 and the phylink part of this patch combined - which makes the changes to phylink smaller as there's no need to move the phylink_phy_no_inband() function and then delete it a few patches later. Also, if we get the Marvell driver implementing validate_an_inband() then I believe we can get rid of other parts of this patch - 88E1111 is the commonly used accessible PHY on gigabit SFPs, as this PHY implements I2C access natively. As I mentioned, Marvell PHYs can be set to no inband, requiring inband, or inband with bypass mode enabled. So we need to decide how we deal with that - especially if we're going to be changing the mode from 1000base-X to SGMII (which we do on some SFP modules so they work at 10/100/1000.) In that regard, I'm not entirely convinced that validate_an_inband() covers the functionality we need - as reading the config register on Marvell hardware doesn't guarantee that we're reading the right mode - the PHY may be in 1000base-X, and we might change it to SGMII-with-bypass - I'd need to go through the PHY datasheets to check what we actually do. Changing what the PHY driver does would be a recipe for regressions, especially for drivers that do not use phylink. Sorry, the above is a bit rambling, but are my thoughts on the current approach. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!