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=-6.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 A634DC433DB for ; Thu, 4 Feb 2021 18:52:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5FEF864E3F for ; Thu, 4 Feb 2021 18:52:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239493AbhBDSwJ (ORCPT ); Thu, 4 Feb 2021 13:52:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:48922 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239432AbhBDSvS (ORCPT ); Thu, 4 Feb 2021 13:51:18 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 34E4464DE1; Thu, 4 Feb 2021 18:50:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612464637; bh=wQVyhdRNYLOtfcHYPyHdQOe6nKL416vQhusWYRh1wiA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=X6/K4PGGKz3sz6w2EJunmSU7nF8z8M6MWKYtJWWvpbW6pigiEWGNnboeaOjGvwPFX 3Kw2V3FQxxKJhIVWfZcr3YyWY9MS2p7agYzmu3Qjy7LbDxsW2+N7PeTZmkI13cSr6L IWPI4Rg7vlJ5FxFsH8t6JXaM96jndNBnIhZLsmPW9H+EoOs6x4ya7NKIrbxL24cNnD m9VYp00Bm5fgLFBvYsTE8Gkuw/kyemb5kEwbet2o6w51RuaXGVbo3OyjEK4txgYrWC 92zfTvN+gzEzVxN72YOq+knVp5Ad3iN9xwoHO15GXeDkvh9oXJ/XmyO+UeiuRo8j/N S9nql31lDQLAA== Date: Thu, 4 Feb 2021 10:50:36 -0800 From: Jakub Kicinski To: Hariprasad Kelam Cc: "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "davem@davemloft.net" , "willemdebruijn.kernel@gmail.com" , "andrew@lunn.ch" , Sunil Kovvuri Goutham , Linu Cherian , "Geethasowjanya Akula" , Jerin Jacob Kollanukkaran , Subbaraya Sundeep Bhatta Subject: Re: [Patch v3 net-next 7/7] octeontx2-pf: ethtool physical link configuration Message-ID: <20210204105036.0e6cd8a9@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 4 Feb 2021 17:37:41 +0000 Hariprasad Kelam wrote: > > > + req->args.speed = req_ks.base.speed; > > > + /* firmware expects 1 for half duplex and 0 for full duplex > > > + * hence inverting > > > + */ > > > + req->args.duplex = req_ks.base.duplex ^ 0x1; > > > + req->args.an = req_ks.base.autoneg; > > > + otx2_get_advertised_mode(&req_ks, &req->args.mode); > > > > But that only returns the first bit set. What does the device actually do? What > > if the user cleared a middle bit? > > > This is initial patch series to support advertised modes. Current firmware design is such that > It can handle only one advertised mode. Due to this limitation we are always checking > The first set bit in advertised modes and passing it to firmware. > Will add multi advertised mode support in near future. Looking at patch 6 it seems like the get side already supports multiple modes, although the example output only lists supported no advertised. Is the device actually doing IEEE autoneg or just configures the speed, lanes etc. according to the link mode selected?