From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760042AbcAUSpZ (ORCPT ); Thu, 21 Jan 2016 13:45:25 -0500 Received: from shards.monkeyblade.net ([149.20.54.216]:46098 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759617AbcAUSpY (ORCPT ); Thu, 21 Jan 2016 13:45:24 -0500 Date: Thu, 21 Jan 2016 10:45:20 -0800 (PST) Message-Id: <20160121.104520.110588445425253600.davem@davemloft.net> To: sakiwit@gmail.com Cc: julia.lawall@lip6.fr, shuahkhan@gmail.com, bh74.an@samsung.com, ks.giri@samsung.com, vipul.pandya@samsung.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, shuahkh@osg.samsung.com Subject: Re: question about samsung/sxgbe/sxgbe_xpcs.c From: David Miller In-Reply-To: <20160121051056.GA4373@mail.gmail.com> References: <20160119.143628.432983847877790677.davem@davemloft.net> <20160121051056.GA4373@mail.gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-7 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 21 Jan 2016 10:45:23 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u0LIjWZk001370 From: Jåan Sacren Date: Wed, 20 Jan 2016 22:10:56 -0700 > From: David Miller > Date: Tue, 19 Jan 2016 14:36:28 -0500 >> >> From: Julia Lawall >> Date: Tue, 19 Jan 2016 19:54:20 +0100 (CET) > > [...] > >> > I just wondered. I was looking at dependencies between networking files. >> > This one stands out because nothing is dependenton it, even the files it >> > is compiled with, and it doesn't contain the usual functions, >> > register_netdev, etc. >> >> Even with that explanation, this is a bogus situation. >> >> There are no in-tree callers of this code. It should be removed until there >> are in-tree users. >> >> Nobody can figure out if the interface for this is done properly without seeing >> the call sites and how they work. It is therefore impossible to review this >> code and judge it's design. >> >> If someone doesn't send me a removal patch, I will remove this code myself. > > I have the patch ready. > > Do you want me to submit it now during the merge window or wait till > net-next opens up again? This is rediculous. No, you cannot submit patches for new features now. Yes, you will submit to me a patch to remove the unused code. Am I being clear enough now?