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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 3EB19C433B4 for ; Wed, 7 Apr 2021 13:06:44 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A2F726120E for ; Wed, 7 Apr 2021 13:06:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A2F726120E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=YysMW9vTwB0AWhLpMXgTeKNH+6wTUxp15getHH9AIXQ=; b=flhoxZRDM5GaznMg1ZIesJ61F gtVQ8I3ouhWCYjwcNm1yEeQYvLRPSSUaPICLUsRg4gjamTYN2umZVJcg8P+eT6Rv8UeVhuMh1C6Lt yldYYiI56AWK/qfR9aYM8HbxESvJF59d2j/B35gCoiJJbYAUmnTRaTC+dZ1wGogMR0Q/mBlItC3C4 TmBbf+O74PdrftiDHoE+v6jmA8gbn0c9BZ0lgsmsS+JmxAZ+o3n1FFEvOvLkSiyS92/vXPJ+Ej2O8 Jvso5RTwavQLjW+4evnpYH1oZHTdAjBsjBS3Ej8Gi2nUnyZAW7U0stUWJsp30/Kbp4Ec/K8LYEcRM mm7Po+dJg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lU7r2-0050N2-Vt; Wed, 07 Apr 2021 13:04:21 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lU7qw-0050F5-2R for linux-arm-kernel@lists.infradead.org; Wed, 07 Apr 2021 13:04:17 +0000 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=MwmTlFwIZ0WzFA7gpz/Eu4MuKSxZumxg+JxlyNKfb2E=; b=a34kgWuUKrL77AW2ECUJOqgeL fgvzS2gIsLSSqcjUVD8/SOhvbjo4b+c9gEhfFsMIPBQ6AnBD6j56PiTRa3+30bFhPYZVN84GFVmYP TMy3uXGFp5PWXKA8fAFNBo81Eb5kFZbxvwY57wokoZqaPc3YuCCdTQyuUjA/UOdmI9E+hd0ScyaaE TPs1cS9Bztbb5Ia+1a/geN3obzQGxdHepvtOUvJfHlzLO2V9KtERh9fki2g+KTtA0XMVooqz/qjLZ rOoM6r3YmQv1QD2d0giCqngoIN0oRoyZo15oBKvo1zaTsAGF2Gfb4/pLp6PdllUejbs+FQoEV43K6 AykgOgGXg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:52186) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lU7n1-0008Ht-84; Wed, 07 Apr 2021 14:00:11 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1lU7mx-0001zo-Dm; Wed, 07 Apr 2021 14:00:07 +0100 Date: Wed, 7 Apr 2021 14:00:07 +0100 From: Russell King - ARM Linux admin To: Andrew Lunn Cc: "Voon, Weifeng" , "Sit, Michael Wei Hong" , "peppe.cavallaro@st.com" , "alexandre.torgue@st.com" , "joabreu@synopsys.com" , "davem@davemloft.net" , "kuba@kernel.org" , "mcoquelin.stm32@gmail.com" , "Ong, Boon Leong" , "qiangqing.zhang@nxp.com" , "Wong, Vee Khee" , "fugang.duan@nxp.com" , "Chuah, Kim Tatt" , "netdev@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "hkallweit1@gmail.com" Subject: Re: [PATCH net-next v2 0/2] Enable 2.5Gbps speed for stmmac Message-ID: <20210407130006.GH1463@shell.armlinux.org.uk> References: <20210405112953.26008-1-michael.wei.hong.sit@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210407_140414_333176_01F35A7F X-CRM114-Status: GOOD ( 22.11 ) 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 Wed, Apr 07, 2021 at 02:44:39PM +0200, Andrew Lunn wrote: > > Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell > > multi-gige PHY can do rate adaption right? > > The Marvell/Marvell multi-gige PHY can also do rate > adaptation. Marvell buying Aquantia made naming messy :-( > I should probably use part numbers. > > > Hence, we still need to take care of others PHYs. > > Yes, it just makes working around the broken design harder if you want > to get the most out of the hardware. FYI, we really need to come up with a good solution to the rate adaption issue. What we have today really is not good. For example, take a MAC that supports only 2500base-X connected to a PHY that does rate adaption from 2500base-X to media speed. So, the PHY could be capable of 10, 100, 1G and 2.5G media speeds, and would advertise those in its supported mask. The MAC however would only report (via the validate callback) support for 2.5G speed because that's all that 2500base-X supports. What we really want when a rate adapting capable PHY is connected is to ignore what ethtool link modes the MAC supports beyond "does it support this interface type" and just use the PHY supported mask. However, that's another property of the PHY that we need to know from phylib, and it's not clear when that property should be made available. As we know from Marvell PHYs, it depends on the configurable MAC_TYPE setting, so could only be available once we've selected an interface mode for the PHY. On the other hand, we might need to know what interface mode(s) are available from the PHY and MAC to select an appropriate mode. This is not easy problems to overcome; I have had some patches for some time which allow some combination of MAC and PHY to advertise which interface mode(s) they support but I haven't been entirely happy with them to push them upstream - and it would be another phylink API change which means having to maintain the new and old code until everything has been updated (thereby making stuff a lot more complex.) After the last round of phylink API updates and the hostility from people over that, this is a big demotivating factor. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel