From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A802637F for ; Sat, 26 Aug 2023 00:54:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCC56C433C8; Sat, 26 Aug 2023 00:54:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693011298; bh=/yywbGq6ACHFhnVK1HEPC1x6NEHvjwMXNT4AE6QpBpc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TeWq8O4es9uTN7wHQKmtKLZwe41v4hN/Yrigp2WZf+YdtRtAkvpx+lCIkdJ6DWI4w 4SoI9qSjI0htVCG97rEOx2Q9EDFJGrVIgAtJ55IA+v2TQIKIS87jMQGfe56DAQ/ZBS TKKIfmiDlD2ca3U65flk4CUWZmzx6s2ya6dfGt18eKdHpG4NNFA0lzlwXlEiHi8/aK ALCxB4Ot3xFqCu5zaK60qeIygX4zimv17ukrTDXw87qPUXdJ5ssl1dtzXHojB2xQuD U2x7nyJk3PlMEEepqJeGXjFghAbpd6JierHd1P9vgQc6JUi4mTzh3HxiPoWtw10dwL lC3qhVSTYfuNw== Date: Fri, 25 Aug 2023 17:54:56 -0700 From: Jakub Kicinski To: "Drewek, Wojciech" Cc: "intel-wired-lan@lists.osuosl.org" , "netdev@vger.kernel.org" , "Kitszel, Przemyslaw" , "idosch@nvidia.com" Subject: Re: [PATCH iwl-next v2] ice: Disable Cage Max Power override Message-ID: <20230825175456.44051773@kernel.org> In-Reply-To: References: <20230824085459.35998-1-wojciech.drewek@intel.com> <20230824083201.79f79513@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 25 Aug 2023 11:01:07 +0000 Drewek, Wojciech wrote: > > Can you say more? We have ETHTOOL_MSG_MODULE_GET / SET, sounds like > > something we could quite easily get ethtool to support? > > So you're suggesting that ethtool could support setting the maximum power in the cage? > Something like: > - new "--set-module" parameter called "power-max" > - new "--get-module" parameters: "power-max-allowed", > "power-min-allowed" indicating limitations reported by the HW. Yup. Oh, nice you even CCed Ido already :) > About the patch itself, it's only about restoration of the default > settings upon port split. Those might be overwritten by Intel's > external tools. I guess, the thing that sent me down the path of putting the control in hands of the user more directly was the question of "why do we need to reset on port split"? Why is that a policy the driver is supposed to follow?