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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C61FC433EF for ; Thu, 28 Oct 2021 13:51:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 42387610D2 for ; Thu, 28 Oct 2021 13:51:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230282AbhJ1Nxx (ORCPT ); Thu, 28 Oct 2021 09:53:53 -0400 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:51603 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230406AbhJ1Nxw (ORCPT ); Thu, 28 Oct 2021 09:53:52 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 197215805AF; Thu, 28 Oct 2021 09:51:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 28 Oct 2021 09:51:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=EY6Ppd RieQ6Lm/hdWqDPDgeMydgm2AXJQ8PLkaYkjtY=; b=n1XABuk8745wwFiYSV1A0p 0uwWaRwyGRKSfjFryXWNrz8B6KA305fHhK3K+VJhq9Z82uYoZBw65w6yIPYKqKM0 YKdSy3c6g0jhnIp/ETefxFOxlonyOjiZXDP+1FxtIHcU3vrW0RKzjxAgV1kg3UZ5 BtVmjYUKHosSy44oDYPkwOKP7G0HIPnTZN2x/bseM0AR52k+Kyz+2rV1hBxWDRYG CwV8WWI3SDuL6Zzf+2H7s9kUomkgRgb3TNxIkMJ7rrhbO6oMN+v5+/NLOFhdOfLw ezXCciA8lzynz9XA2XPMUkDJku9yS7mtKrxFsCNX6L0xk5j8Dif9l+EdVZM9LJJQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdegvddgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucggtffrrghtth gvrhhnpedtffekkeefudffveegueejffejhfetgfeuuefgvedtieehudeuueekhfduheel teenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehiug hoshgthhesihguohhstghhrdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 28 Oct 2021 09:51:23 -0400 (EDT) Date: Thu, 28 Oct 2021 16:51:19 +0300 From: Ido Schimmel To: sundeep subbaraya Cc: Sunil Kovvuri Goutham , Jakub Kicinski , David Miller , "netdev@vger.kernel.org" , Hariprasad Kelam , Geethasowjanya Akula , Subbaraya Sundeep Bhatta , Rakesh Babu Saladi , Saeed Mahameed , "anthony.l.nguyen@intel.com" , Jesse Brandeburg , Andrew Lunn Subject: Re: [EXT] Re: [net-next PATCH 1/2] octeontx2-pf: Add devlink param to init and de-init serdes Message-ID: References: <1635330675-25592-1-git-send-email-sbhatta@marvell.com> <1635330675-25592-2-git-send-email-sbhatta@marvell.com> <20211027083808.27f39cb0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20211027100857.4d25544c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Oct 28, 2021 at 05:48:02PM +0530, sundeep subbaraya wrote: > Actually we also need a case where debugging is required when the > logical link is > up (so that packets flow from kernel to SerDes continuously) but the > physical link > is down. Can you explain the motivation for that? In the past we discussed use cases for forcing the operational state to down while the administrative state is up and couldn't find any. > We will change the commit description since it is giving the > wrong impression. > A command to change physical link up/down with no relation to ifconfig > is needed. So it is obvious that some drivers default to not shutting down the physical link upon admin down, but that some users want to change that. In addition, we have your use case to control the physical link without relation to the logical link. I wonder if it can all be solved with a new ethtool attribute (part of LINKINFO_{SET,GET} ?) that describes the physical link policy and has the following values: * auto: Physical link state is derived from logical link state * up: Physical link state is always up * down: Physical link state is always down IIUC, it should solve your problem and that of the "link-down-on-close" private flag. It also has the added benefit of allowing user space to query the default policy. The expectation is that it would be "auto", but in some scenarios it is "up".