Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2486450imm; Mon, 10 Sep 2018 01:46:12 -0700 (PDT) X-Google-Smtp-Source: ANB0VdarzaMTsCsqr5A7oS7krf7k4QZk+99DkiNc3PSJxEAvEMXuPw1saAbjbs92Q9lGzOpmEUlQ X-Received: by 2002:a62:be03:: with SMTP id l3-v6mr22453704pff.138.1536569172319; Mon, 10 Sep 2018 01:46:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536569172; cv=none; d=google.com; s=arc-20160816; b=cwfBeepfeygW8+KUUSXoPw7pYi21rEt4a7bTPAkNEuZArXZsCATCmpy/c/rie+4cOk oBJRTjOAaYt1W4TVAYh031TeAkE/s0udoYUiXRbfV1qXxAYKfBXJoQv1DBax3jnIasLt EXphFKMUMXclX5JQx6A9X8SGW9BWW455E/nrOrp/mFl/ScWDNluARM1X9E5J4+VmAVgL Y4wNy1Xx3EP8B/ABF3m15EjKFcSLd3OZzmd5wAXBYm8mMiIQRa6SWA/+b4Q5xB/0058b ZUoBla4uYZAaIBKbkaqmx0GK6C2tUJIm8PW29RGEUiK3yVoBrmey7WztDSoZ2Kdakkgc GGWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=vgB6GTrm+iJTbabFaj/clF7dRpCQRZyv/XEfU3sVYxQ=; b=Ha0Wo86scHD4G5Glx7/STE8uwDurLYJM8CtSXeheN6DzWsn9bCdgbyPsVj7LyJXTjY rNXeh1hX0F2ZMLn71Uo4kUDl9BsbWed3AhsK+kx1lj1Z4SjV8WlaqGBOeX15RIKS5d9Q T8/vfyUmXWDQRzGg06LdiA/v9Vd5/ZagvQTHrLSiWB9rlA/REsz0Vh0kLj69S2BVniUB ZHSdSpH5sVVw+Ai5pUXrzPPt3+uBVwRK//gLPb3Pu+6fo9ZPfTCKDfDUrJ/pY8uBW3MX 2T9e6XA4+V7A8Ssmi0qMOkzAjvUAK8/hg12YW4g/B66W4AiTef/hlJAvj8WvvlqlPa+c /uhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=VjZ04faa; 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 d27-v6si16221749pgd.223.2018.09.10.01.45.56; Mon, 10 Sep 2018 01:46:12 -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; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=VjZ04faa; 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 S1728072AbeIJNgy (ORCPT + 99 others); Mon, 10 Sep 2018 09:36:54 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:39436 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727976AbeIJNgy (ORCPT ); Mon, 10 Sep 2018 09:36:54 -0400 Received: by mail-it0-f65.google.com with SMTP id h1-v6so27633679itj.4 for ; Mon, 10 Sep 2018 01:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vgB6GTrm+iJTbabFaj/clF7dRpCQRZyv/XEfU3sVYxQ=; b=VjZ04faaAKpdMGrls6vDC/9Q9Oq2MxWbpMU/M9xL08k2Ly1l3bBguc1sg7mOoqijF6 wtLlZHj4vZhD5NE3w/Xtd8yj7hG60YixFatVR65KNhWPzOGZ3/2dkPi3yI1Y2+8v4ffC Bt6CX4lRqSJgLveavvbHMi6R5cIXePDwRh4/qzC631FGvfKzHP+e0aE5ZLf7Atg4UZhB RksDdFvPOoy/SbR5KME/hqdanIaf6rat5moQJFkLVBs+6ZtHBX+MJKxDQKi+iX6SHRaY ODpbfs6bTE+m7ReoiiEDHzWVOYNtf+XWOFEd93hXYRxBwZOjK6wNqh5H9cdyp/WQNIv3 u6rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vgB6GTrm+iJTbabFaj/clF7dRpCQRZyv/XEfU3sVYxQ=; b=qtZ11TroYhXoASKTWnt0NkwsKz6dohQZpeAGIH9EM2RecHb80sQv+ojT+QH29342jb ZpE1QBiNEbN6hEzolyGF42ZWvo6vMunex6rt/B6BttKq8ABSzwTj7AtQp36xdeyMCjEG M44CiwOg7aLrJF8Gogk0XS2FP3iMJanFCfmpVJNnl32fxiNOmPbzRnEt2Do42TN63jPD cCgwlZPFUadwtfGuVmMiREujBjBhg1VI62aPIIH/1vpNYpf4nlmJb3fPdnb24MvZZx0c yhtNJJ1SP/LSkmuTY/rHiisCDjnYi45aa0prtrKtbX5veH9zUEl9Y1x6FWxOC5PFCR7J 2fJg== X-Gm-Message-State: APzg51BpbKAjZIlP5+95Nqo8Ktc6AFe916/y5KFc18jbFje/ubq7ku4M nBNNW7M0T5Dhpv6T1bj9AAzG62qbW0CSbMWCce2Xiw== X-Received: by 2002:a02:5f44:: with SMTP id r65-v6mr17662391jab.34.1536569036758; Mon, 10 Sep 2018 01:43:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:1905:0:0:0:0:0 with HTTP; Mon, 10 Sep 2018 01:43:56 -0700 (PDT) In-Reply-To: <7e138142-8161-3646-4daf-619995baf395@linaro.org> References: <20180907100750.14564-1-brgl@bgdev.pl> <20180907100750.14564-2-brgl@bgdev.pl> <7e138142-8161-3646-4daf-619995baf395@linaro.org> From: Bartosz Golaszewski Date: Mon, 10 Sep 2018 10:43:56 +0200 Message-ID: Subject: Re: [PATCH v2 01/16] nvmem: remove unused APIs To: Srinivas Kandagatla Cc: "David S . Miller" , Mauro Carvalho Chehab , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , Jonathan Corbet , Sekhar Nori , Kevin Hilman , David Lechner , Boris Brezillon , Andrew Lunn , Alban Bedel , Maxime Ripard , Chen-Yu Tsai , linux-doc , Linux Kernel Mailing List , Linux ARM , Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-09-10 10:09 GMT+02:00 Srinivas Kandagatla : > > > On 10/09/18 08:58, Bartosz Golaszewski wrote: >> >> 2018-09-10 9:32 GMT+02:00 Srinivas Kandagatla >> : >>> >>> >>> >>> On 07/09/18 11:07, Bartosz Golaszewski wrote: >>>> >>>> >>>> From: Bartosz Golaszewski >>>> >>>> Remove all APIs dealing with nvmem_cell_info. There are no users and >>>> this part of the subsystem will be reworked. >>>> >>>> This patch temprarily disables support for non-DT users. >>>> >>>> Signed-off-by: Bartosz Golaszewski >>>> --- >>>> drivers/nvmem/core.c | 212 >>>> ++------------------------------- >>>> include/linux/nvmem-consumer.h | 26 ---- >>>> include/linux/nvmem-provider.h | 13 -- >>>> 3 files changed, 12 insertions(+), 239 deletions(-) >>> >>> >>> >>> This looks totally un-necessary, Other patches in this series adds them >>> back.. Consider updating these in those respective patches.! >>> >> >> While this may not be entirely necessary, it's very useful. There's > > Yes, thats exactly what am saying if it not necessary please do not do it. > >> almost nothing common between this API and the new one added later in > > There is more than 60%-70% of the code reused in new patches, which is > unnecessary churn to me! > Pretty much the only thing that is reused are the contents of nvmem_cell_info_to_nvmem_cell() and even they are placed in a different function. Also: this change allows us to add new APIs without having to update users at each step only to change them afterwards with one of subsequent patches. I would really prefer that this stay this way. If there are no users, then there's no breakage that would make your point valid. >> this series. Later patches are MUCH cleaner thanks to this removal and >> I believe it makes them easier for review. > > Am not sure about that, it definitely did not help me! > Why exactly? Aren't clean patches resulting from this removal easier to read then if they'd also have to take into account the burden of existing code that will be changes anyway later? I really don't see why you insist on removing this. Best regards, Bart > --srini >> >> >> Best regards, >> Bart >> >