Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2701097imm; Mon, 10 Sep 2018 05:20:29 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZSZOCHcA066eSplim5TEfp7W3ATDcpKTz5Y5p8LadliSdazlMCBGu8Z2BEChvi1WtukF3B X-Received: by 2002:a17:902:3081:: with SMTP id v1-v6mr21862542plb.58.1536582029742; Mon, 10 Sep 2018 05:20:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536582029; cv=none; d=google.com; s=arc-20160816; b=lmECSixlWOfT34SmoooFMih9nyTkvifaCQdfy8outogpa7dNdwKlUAICboLzEvrVxj 6x1ig0pX5w9zBFgvImhWz/n0ZgaaGvCLiUPXchbn28hg7XUQ7NO8Ofi6O2uwStD16zQV BolBm5fMrWgsQu4reEIqJMg/mxkWynSOU/xrRzUWK7Bt5WaIqIo55Tw+Qgu2pvkdq2TV dnMko0pvL14NdrDQJCWrEtZ4ULRo9DfOh/TblnG4IYrAH63eoe75eJGaAFykQ6dvljJp om86pIAvk/LfXY7aqdVfpZU5yPqYtlNGmipBH8YzaXdCMs0hwyCsDZFlirmPW5YAQ//d w5eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=BQHnmoDAQjoHpI2Zco4fc2Geb1KAxs8M/BKI8BCX3WU=; b=gOd/MepRdcLY24ph3NL+0GW4rFQUQY8xa4ARHNHimFI/UpPpgEpuXnY5LMfkpyf+wY eCn623zG2z3T3k95EvbSE9V9euskIE9gR3Bnk3SEa6TRDJHlKTy5ch83fQuwlw2PR/PT JgN063dhZsaHP3WMQFpbow7oD9Y0Fd2gwnEyHnt/KA1B6fMUyectZlD54rOJNOCO53AY Tw2G8rCykGN3WBIkQyivvZK1t/70NKWaddLJsEOm5yLupoVMWmNSPraEFciLtDs2SpBf h/YMDKEx9s8dKHTAK6ZeXJSPMDo+08QtuMVnhiitjJPgjsvRKNCkG3a+F6ZAm6mqEKGJ 9x9Q== 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 7-v6si15951627pll.369.2018.09.10.05.20.14; Mon, 10 Sep 2018 05:20:29 -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 S1728561AbeIJRMM (ORCPT + 99 others); Mon, 10 Sep 2018 13:12:12 -0400 Received: from mail.bootlin.com ([62.4.15.54]:37311 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727649AbeIJRMM (ORCPT ); Mon, 10 Sep 2018 13:12:12 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 018382074F; Mon, 10 Sep 2018 14:18:23 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (AAubervilliers-681-1-30-219.w90-88.abo.wanadoo.fr [90.88.15.219]) by mail.bootlin.com (Postfix) with ESMTPSA id 7F99E206EE; Mon, 10 Sep 2018 14:18:22 +0200 (CEST) Date: Mon, 10 Sep 2018 14:18:20 +0200 From: Boris Brezillon To: Srinivas Kandagatla Cc: Bartosz Golaszewski , "David S . Miller" , Mauro Carvalho Chehab , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , Jonathan Corbet , Sekhar Nori , Kevin Hilman , David Lechner , Andrew Lunn , Alban Bedel , Maxime Ripard , Chen-Yu Tsai , linux-doc , Linux Kernel Mailing List , Linux ARM , Bartosz Golaszewski Subject: Re: [PATCH v2 01/16] nvmem: remove unused APIs Message-ID: <20180910141820.6c715895@bbrezillon> In-Reply-To: References: <20180907100750.14564-1-brgl@bgdev.pl> <20180907100750.14564-2-brgl@bgdev.pl> <7e138142-8161-3646-4daf-619995baf395@linaro.org> <3dbd65e5-c948-a784-0362-930fc41b840e@linaro.org> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Srinivas, On Mon, 10 Sep 2018 12:47:19 +0100 Srinivas Kandagatla wrote: > On 10/09/18 12:31, Bartosz Golaszewski wrote: > > About that: there are no users of nvmem_device_cell_read/write() > > currently and with the new API I'm not sure this is still needed. Are > > you alright with removing those two? > > Why do you want to remove them? Other than reason of no users. I'm just sharing my (and probably other maintainers/developers) PoV here, so please don't take this as an attempt to force you to change your mind, but rather an attempt at explaining why APIs usually stay private when they have no users. Kernel maintainers tend to reject APIs that have no users because adding something that nobody needs yet is hard to get right. I mean, you can design an API on what you think will be needed/appropriate, and then, when people actually start needing this feature, they realize it does not quite match what they need, and they have to adjust/rework this API. > > All it boils down to if we support device based apis using cell info or > not? But it looks like nobody is actually using it, and the first potential user (Bart) proposed a different approach with the nvmem cell table declaration. > IMO, I see no harm in leaving these apis as it is, unless there is a > strong reason to do so. It's harmless, but it's also unused. If people start using it and you realize the API is not working for some use cases, then you'll have to patch all existing users. All this being said, it's your call to make, and if you think it makes sense to keep these functions around for any reason, then be it. Regards, Boris