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.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 326A0C4BA0B for ; Wed, 26 Feb 2020 10:12:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0574724656 for ; Wed, 26 Feb 2020 10:12:56 +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="v6DlCO/O" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726425AbgBZKMz (ORCPT ); Wed, 26 Feb 2020 05:12:55 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:45312 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726057AbgBZKMz (ORCPT ); Wed, 26 Feb 2020 05:12:55 -0500 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=CAamW1A7wSi+dl1kSJ3MLj0iB7qeqpYQKI22daCCGM8=; b=v6DlCO/OJmb9kQvoiXW+Zr432 8BvCAsk7BQEZrQZMpP9iJSc7ZzWQ1beEXWg6f1rkJar2gHLh0bO6C6g55IjbliVm8GG4wOPoJ5Ua6 vdY5znpf7BdEkxFYx1esKe7H+3s72RVuWJei0owKFkgQfwQhq1p1LxnrcjjwuMtgy8iRnkfHSDWCU ppAdE2TIyan/4aiw8Za37GFy7p9KLPAfuhtItrM+Jis7E9Z6EPwm8rGSfhBsW5F9DrRXs0k6PUwkh r9XT5Ir1bufpF5nVPFO5gkuAhgxd3lpmT5fPbnsxbBNoWcWXG+AklBbInbQTfslvbHfTUtRdAfMqJ fNfXuKgBA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:57116) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1j6tfp-0006nj-Vd; Wed, 26 Feb 2020 10:12:14 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1j6tfh-0008KB-0V; Wed, 26 Feb 2020 10:12:05 +0000 Date: Wed, 26 Feb 2020 10:12:04 +0000 From: Russell King - ARM Linux admin To: Ioana Ciornei Cc: Andrew Lunn , Florian Fainelli , Heiner Kallweit , Alexandre Torgue , "David S. Miller" , Felix Fietkau , Giuseppe Cavallaro , Hauke Mehrtens , Jakub Kicinski , John Crispin , Jonathan Corbet , Jose Abreu , "linux-arm-kernel@lists.infradead.org" , "linux-doc@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , "linux-stm32@st-md-mailman.stormreply.com" , Mark Lee , Matthias Brugger , Maxime Coquelin , Michal Simek , "netdev@vger.kernel.org" , Nicolas Ferre , Radhey Shyam Pandey , Sean Wang , Thomas Petazzoni , Vivien Didelot , Vladimir Oltean Subject: Re: [PATCH net-next 5/8] net: dpaa2-mac: use resolved link config in mac_link_up() Message-ID: <20200226101204.GW25745@shell.armlinux.org.uk> References: <20200225093703.GS25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Tue, Feb 25, 2020 at 04:36:32PM +0000, Ioana Ciornei wrote: > > Subject: [PATCH net-next 5/8] net: dpaa2-mac: use resolved link config in > > mac_link_up() > > > > Convert the DPAA2 ethernet driver to use the finalised link parameters in > > mac_link_up() rather than the parameters in mac_config(), which are more > > suited to the needs of the DPAA2 MC firmware than those available via > > mac_config(). > > > > Signed-off-by: Russell King > > Tested-by: Ioana Ciornei Thanks. > > + > > + /* This is lossy; the firmware really should take the pause > > + * enablement status rather than pause/asym pause status. > > + */ > > In what sense it's lossy? I cannot see how information can be lost by translating the rx/tx pause state to pause/asym. > If it's just about the unnecessary double translation, then I agree.. this could have been done in an easier manner. If you're just translating rx/tx to pause/asym and then doing the reverse, then it isn't lossy, but if the firmware is resolving pause/asym according to the table in IEEE 802.3, then it will be lossy. If the firmware doesn't interpret the bits, then why not do the sensible thing and just pass the enablement status rather than trying to confusingly encode it back to pause/asym? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up