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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5955C433E0 for ; Wed, 12 Aug 2020 15:00:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 72DC920838 for ; Wed, 12 Aug 2020 15:00:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="ZmunQALO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726554AbgHLPA6 (ORCPT ); Wed, 12 Aug 2020 11:00:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51338 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726226AbgHLPA5 (ORCPT ); Wed, 12 Aug 2020 11:00:57 -0400 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 94A68C061383 for ; Wed, 12 Aug 2020 08:00:57 -0700 (PDT) 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-Transfer-Encoding:Content-Type: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-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oL4eoDcbzFX3VV+qDqTG7w7eCi+IfPlSB5eO3zYffmY=; b=ZmunQALOydD6xXz4js62mylZB EVEoB849VaiiDcDoQ9xIFhg0PW+DTYuYSYvFjpsiEjom/Mb5zPUhvrnR+TFdmRdaRPVqSMsjIu+WB O3PisUykTxOmuSP0qdrT9ETKPFs0UhAS4oseULC4/2HKJO71Z384N+xMPIFY7xqaRsRMq3PS7yWKV BG/U443I1ABtGa4asjc68LD/exLhO0QBEp7eJITymI1zlRZXGNplasCFyGTu9AAlIHE6o7GJI3ePZ pdpWbEpCuoIWi1MUHweK2y+MNEi2TwQtqZKn5JDOqbB31uINLbcI6NevDuXW4Zgw/qiPFKjshe0cF rRjAwD8sQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:51592) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k5sFL-0002lp-38; Wed, 12 Aug 2020 16:00:55 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1k5sFK-0003tX-E8; Wed, 12 Aug 2020 16:00:54 +0100 Date: Wed, 12 Aug 2020 16:00:54 +0100 From: Russell King - ARM Linux admin To: Marek =?iso-8859-1?Q?Beh=FAn?= Cc: Andrew Lunn , Maxime Chevallier , Baruch Siach , Chris Healy , Florian Fainelli , netdev@vger.kernel.org Subject: Re: [PATCH RFC russell-king 3/4] net: phy: marvell10g: change MACTYPE according to phydev->interface Message-ID: <20200812150054.GP1551@shell.armlinux.org.uk> References: <20200810220645.19326-1-marek.behun@nic.cz> <20200810220645.19326-4-marek.behun@nic.cz> <20200811152144.GN1551@shell.armlinux.org.uk> <20200812164431.34cf569f@dellmb.labs.office.nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200812164431.34cf569f@dellmb.labs.office.nic.cz> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Aug 12, 2020 at 04:44:31PM +0200, Marek Behún wrote: > There is another problem though: I think the PHY driver, when deciding > whether to set MACTYPE from the XFI with rate matching mode to the > 10GBASE-R/5GBASE-R/2500BASE-X/SGMII with AN mode, should check which > modes the underlying MAC support. I'm aware of that problem. I have some experimental patches which add PHY interface mode bitmaps to the MAC, PHY, and SFP module parsing functions. I have stumbled on some problems though - it's going to be another API change (and people are already whinging about the phylink API changing "too quickly", were too quickly seems to be defined as once in three years), and in some cases, DSA, it's extremely hard to work out how to properly set such a bitmap due to DSA's layered approach. Having bitmaps means that we can take the union of what the MAC and PHY supports, and decide which MACTYPE setting would be most suitable. However, to do that we're into also changing phylib's interfaces as well. > driver to phylink in the call to phylink_create. But there is no way > for the PHY driver to get this information from phylink currently, and > even if phylink exposed a function to return the config member of > struct phylink, the problem is that at the time when mv3310_power_up is > called, the phydev->phylink is not yet set (this is done in > phylink_bringup_phy, and mv3310_power_up is called sometime in the > phylink_attach_phy). We _really_ do not want phylib calling back into phylink functions. That would tie phylink functionality into phylib and cause problems when phylink is not being used. I would prefer phylib to be passed "the MAC can use these interface types, and would prefer to use this interface type" and have the phylib layer (along with the phylib driver) make the decision about which mode should be used. That also means that non-phylink MACs can also use it. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!