From mboxrd@z Thu Jan 1 00:00:00 1970 From: Edward Cree Subject: Re: [PATCH ethtool] ethtool: support combinations of FEC modes Date: Wed, 19 Sep 2018 16:38:27 +0100 Message-ID: <613d954c-d88c-fa20-f436-75625f11a2ae@solarflare.com> References: <518b8b8b-0151-1053-3798-6009044ed53a@solarflare.com> <20180919144117.GF3876@unicorn.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Cc: "John W. Linville" , netdev , Ganesh Goudar , "Jakub Kicinski" , Dustin Byford , Dirk van der Merwe To: Michal Kubecek Return-path: Received: from dispatch1-us1.ppe-hosted.com ([67.231.154.164]:49558 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732255AbeISVRD (ORCPT ); Wed, 19 Sep 2018 17:17:03 -0400 In-Reply-To: <20180919144117.GF3876@unicorn.suse.cz> Content-Language: en-GB Sender: netdev-owner@vger.kernel.org List-ID: On 19/09/18 15:41, Michal Kubecek wrote: > I'm sorry I didn't notice this before the patch was accepted but as it's > not in a release yet, maybe it's still not too late. > > Could I suggest to make the syntax consistent with other options? I didn't realise ethtool had any patterns to be consistent with ;) > I mean rather than a comma separated list to use either > > ethtool --set-fec encoding enc1 enc2 ... but yes this looks fine to me, as long as we're reasonably confident that  we won't want to add new parameters (that might require determining  whether enc2 is an encoding or a parameter name) in the future, because  while the parsing wouldn't be impossible it might get ugly. I'll rustle up an RFC patch. -Ed