From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Kubecek Subject: Re: [PATCH ethtool] ethtool: support combinations of FEC modes Date: Wed, 19 Sep 2018 17:49:29 +0200 Message-ID: <20180919154929.GG3876@unicorn.suse.cz> References: <518b8b8b-0151-1053-3798-6009044ed53a@solarflare.com> <20180919144117.GF3876@unicorn.suse.cz> <20180919153338.GE17466@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Edward Cree , "John W. Linville" , netdev , Ganesh Goudar , Jakub Kicinski , Dustin Byford , Dirk van der Merwe To: Andrew Lunn Return-path: Received: from mx2.suse.de ([195.135.220.15]:48682 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732496AbeISV2D (ORCPT ); Wed, 19 Sep 2018 17:28:03 -0400 Content-Disposition: inline In-Reply-To: <20180919153338.GE17466@lunn.ch> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Sep 19, 2018 at 05:33:38PM +0200, Andrew Lunn wrote: > > One loosely related question: how sure can we be that we are never going > > to need more than 32 bits for FEC encodings? Is it something completely > > hypothetical or is it something that could happen in the future? > > > Hi Michal > > Hopefully we have moved to a netlink socket by that time :-) Actually, that's why I'm asking. :-) > I recently found that EEE still uses a u32 for advertise link modes. > We should fix that in the netlink API. For EEE it felt obvious that arbitrary length bitmap is the way to go so I used it (it's still u32 in ethtool_ops but that's easier to change when needed). For FEC I wasn't sure if it wouldn't be an overkill. Michal Kubecek