From: boris.brezillon@bootlin.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 01/16] nvmem: remove unused APIs
Date: Mon, 10 Sep 2018 14:18:20 +0200 [thread overview]
Message-ID: <20180910141820.6c715895@bbrezillon> (raw)
In-Reply-To: <ec2ba4af-46cf-2025-1670-cbed366d0f15@linaro.org>
Hi Srinivas,
On Mon, 10 Sep 2018 12:47:19 +0100
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> 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
next prev parent reply other threads:[~2018-09-10 12:18 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-07 10:07 [PATCH v2 00/16] nvmem: rework of the subsystem for non-DT users Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 01/16] nvmem: remove unused APIs Bartosz Golaszewski
2018-09-10 7:32 ` Srinivas Kandagatla
2018-09-10 7:58 ` Bartosz Golaszewski
2018-09-10 8:09 ` Srinivas Kandagatla
2018-09-10 8:43 ` Bartosz Golaszewski
2018-09-10 9:55 ` Srinivas Kandagatla
2018-09-10 11:31 ` Bartosz Golaszewski
2018-09-10 11:47 ` Srinivas Kandagatla
2018-09-10 12:18 ` Boris Brezillon [this message]
2018-09-10 12:22 ` Bartosz Golaszewski
2018-09-10 13:23 ` Srinivas Kandagatla
2018-09-07 10:07 ` [PATCH v2 02/16] nvmem: remove the global cell list Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 03/16] nvmem: use kref Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 04/16] nvmem: lpc18xx_eeprom: use devm_nvmem_register() Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 05/16] nvmem: sunxi_sid: " Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 06/16] nvmem: mxs-ocotp: " Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 07/16] nvmem: change the signature of nvmem_unregister() Bartosz Golaszewski
2018-09-10 7:33 ` Srinivas Kandagatla
2018-09-07 10:07 ` [PATCH v2 08/16] nvmem: provide nvmem_dev_name() Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 09/16] nvmem: remove the name field from struct nvmem_device Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 10/16] nvmem: add a notifier chain Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 11/16] nvmem: add support for cell info Bartosz Golaszewski
2018-09-10 7:32 ` Srinivas Kandagatla
2018-09-10 7:36 ` Boris Brezillon
2018-09-10 8:53 ` Srinivas Kandagatla
2018-09-07 10:07 ` [PATCH v2 12/16] nvmem: resolve cells from DT at registration time Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 13/16] nvmem: add support for cell lookups from machine code Bartosz Golaszewski
2018-09-10 7:32 ` Srinivas Kandagatla
2018-09-10 8:17 ` Bartosz Golaszewski
2018-09-10 8:23 ` Boris Brezillon
2018-09-10 8:55 ` Srinivas Kandagatla
2018-09-10 9:45 ` Bartosz Golaszewski
2018-09-10 9:49 ` Boris Brezillon
2018-09-10 9:50 ` Srinivas Kandagatla
2018-09-10 11:26 ` Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 14/16] Documentation: nvmem: document cell tables and lookup entries Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 15/16] nvmem: use SPDX license identifiers Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 16/16] nvmem: make the naming of arguments in nvmem_cell_get() consistent Bartosz Golaszewski
2018-09-10 7:54 ` [PATCH v2 00/16] nvmem: rework of the subsystem for non-DT users Srinivas Kandagatla
2018-09-10 8:24 ` Bartosz Golaszewski
2018-09-10 10:02 ` Srinivas Kandagatla
2018-09-10 14:58 ` Bartosz Golaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180910141820.6c715895@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).