Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5201969imm; Tue, 21 Aug 2018 07:54:53 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwLjHvJmraAw/15vbCIecOTzStthIwtJEJqPe645+9xvSfvTCtcmJ2yUvp+RwxzfoXBjE7w X-Received: by 2002:a63:9d83:: with SMTP id i125-v6mr19306367pgd.194.1534863293184; Tue, 21 Aug 2018 07:54:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534863293; cv=none; d=google.com; s=arc-20160816; b=kZ0+9Qx7PBRFHzU2F1xo9fsSpslWXqzc0F93hWvZQuLKScrw7TvJOq96LLqGcYr1KK mdSGrPILmmEmOvvqPUxOVpczis88y2izvKReig/W7Ezafq6S2w2oHsjKZeF0s2QwC3Gz 3FBB0WfTpHmLZj31EPhMZqMJb1bu02tupCIjfLs10w0Im0USw9CTP4JnnMjNoxfK125Z QZd8JEs9BZKJtMDS4ETLh5B380mlyLrH3fURbNvxhNa2FdKF1IiFKb3rAcq/gfVSzsBh c008Hqt+ERQ63HpRZomm8od8v1aBGNEaReuLRWwnHLqBLZeaEHCwKr5/2rKdcebSMQcu 3//Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=oCaZD8yG8lr15tAc//J2XvnDheE4acbykxYX06SN8Lo=; b=n3O9GjEBC6HTWHP8qUteKjqh/IH5CW52Rztxj1+RyCIsoDG6XiybavrJ8yi99BUpzR DYpPA8gdgp1lfnT5f723QuRGqGPVH7lozeDmuOCx7h/S+lH/7gowfPa9LiYCvh8DVdv1 VnjGogGSNhMQT7muR6kLiYkqV0TU2rZIuvS9HxGkWhVdBEujQkr+sZHblFv/ahZV7aYh vBs30OeKRrI26/WE21kHdTAP14HT63nkZLxJvLAkFajW/pYZ4/XJGNkdNJyLZ7UBVk8R C4+S9FDHu4cx3v8pkhd7NwF9px/rMBAXD/D/UT0BtDmsb4e3V9ZYYFPlI2Pr7EOUTxA1 hZWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 17-v6si12394152pgw.648.2018.08.21.07.54.38; Tue, 21 Aug 2018 07:54:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727573AbeHUSMv (ORCPT + 99 others); Tue, 21 Aug 2018 14:12:51 -0400 Received: from mx2.suse.de ([195.135.220.15]:42844 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726730AbeHUSMu (ORCPT ); Tue, 21 Aug 2018 14:12:50 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 1F574AEB5; Tue, 21 Aug 2018 14:52:21 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id 13A07A09F2; Tue, 21 Aug 2018 16:52:19 +0200 (CEST) Date: Tue, 21 Aug 2018 16:52:19 +0200 From: Michal Kubecek To: Andrew Lunn Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Jiri Pirko , David Miller , Florian Fainelli , Roopa Prabhu , Jakub Kicinski , "John W. Linville" Subject: Re: [RFC PATCH net-next v2 10/17] ethtool: implement GET_SETTINGS message Message-ID: <20180821145218.fuucfjlo3ejhofrx@unicorn.suse.cz> References: <67d3b68a50e95db9612cc96e42a52ce332f716a9.1532953989.git.mkubecek@suse.cz> <20180730185455.GJ2983@lunn.ch> <20180821093245.ktattosaduf6jvya@unicorn.suse.cz> <20180821141022.GD2985@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180821141022.GD2985@lunn.ch> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 21, 2018 at 04:10:22PM +0200, Andrew Lunn wrote: > On Tue, Aug 21, 2018 at 11:32:46AM +0200, Michal Kubecek wrote: > > I have prepared a patch converting 8390/etherh driver to use > > {g,s}et_link_ksettings and I'm going to submit it when net-next opens. > > Do you think we can then drop {g,s}et_settings callbacks completely > > (i.e. also from ioctl() code and ethtool_ops)? Do we care about > > unconverted out of tree drivers? > > We cannot break ethtool, the ABI it uses. But there is already code to > use get_link_ksettings() and only fall back to get_settings if it does > not exist. So we can clean up all the fallback code, remove the > ethtool_ops, etc. Yes, that's what I have in mind: keep the ethtool interface as is (both ETHTOOL_{G,S}SET and ETHTOOL_{G,S}LINKSETTINGS) but drop get_settings and set_settings from ethtool_ops and the code that falls back to them. This way both old and new versions of ethtool would still work and the only problem would be with out of tree drivers not converted to {s,g}et_link_ksettings (which won't build so that it won't be silent breakage). Michal Kubecek