From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
"David S . Miller" <davem@davemloft.net>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
Sekhar Nori <nsekhar@ti.com>, Kevin Hilman <khilman@kernel.org>,
David Lechner <david@lechnology.com>,
Andrew Lunn <andrew@lunn.ch>, Alban Bedel <albeu@free.fr>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Chen-Yu Tsai <wens@csie.org>,
linux-doc <linux-doc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH v2 13/16] nvmem: add support for cell lookups from machine code
Date: Mon, 10 Sep 2018 11:49:27 +0200 [thread overview]
Message-ID: <20180910114927.083e2de8@bbrezillon> (raw)
In-Reply-To: <CAMRc=Me0bYjdmaqqxKqFkRRSNdoOgDf1A==dASz0dJAtx9BDqg@mail.gmail.com>
On Mon, 10 Sep 2018 11:45:48 +0200
Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> 2018-09-10 10:55 GMT+02:00 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>:
> >
> >
> > On 10/09/18 09:23, Boris Brezillon wrote:
> >>
> >> Well, if we get rid of nvmem-machine.h, the cell-lookup stuff
> >> should go in nvmem-consumer.h not nvmem-provider.h. On the other hand,
> >> everything that is related to cell creation should be placed in
> >> nvmem-provider.h.
> >
> > Yes, this is how it should be!
> >
>
> Any actual reason for not putting these definitions into a separate
> 'machine' header? This approach is currently used by gpio, pinctrl,
> iio and regulator framework because most systems use either DT or ACPI
> and don't need to pull in any stuff aimed at board files.
I'm perfectly fine with the separate header file, all I'm saying is, if
Srinivas does not want nvmem-machine.h, definitions should be placed in
nvmem-provider.h or nvmem-consumer.h depending on who they're meant to
be used by (providers or consumers).
WARNING: multiple messages have this Message-ID (diff)
From: boris.brezillon@bootlin.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 13/16] nvmem: add support for cell lookups from machine code
Date: Mon, 10 Sep 2018 11:49:27 +0200 [thread overview]
Message-ID: <20180910114927.083e2de8@bbrezillon> (raw)
In-Reply-To: <CAMRc=Me0bYjdmaqqxKqFkRRSNdoOgDf1A==dASz0dJAtx9BDqg@mail.gmail.com>
On Mon, 10 Sep 2018 11:45:48 +0200
Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> 2018-09-10 10:55 GMT+02:00 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>:
> >
> >
> > On 10/09/18 09:23, Boris Brezillon wrote:
> >>
> >> Well, if we get rid of nvmem-machine.h, the cell-lookup stuff
> >> should go in nvmem-consumer.h not nvmem-provider.h. On the other hand,
> >> everything that is related to cell creation should be placed in
> >> nvmem-provider.h.
> >
> > Yes, this is how it should be!
> >
>
> Any actual reason for not putting these definitions into a separate
> 'machine' header? This approach is currently used by gpio, pinctrl,
> iio and regulator framework because most systems use either DT or ACPI
> and don't need to pull in any stuff aimed at board files.
I'm perfectly fine with the separate header file, all I'm saying is, if
Srinivas does not want nvmem-machine.h, definitions should be placed in
nvmem-provider.h or nvmem-consumer.h depending on who they're meant to
be used by (providers or consumers).
next prev parent reply other threads:[~2018-09-10 9:49 UTC|newest]
Thread overview: 86+ 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 ` Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 01/16] nvmem: remove unused APIs Bartosz Golaszewski
2018-09-07 10:07 ` Bartosz Golaszewski
2018-09-10 7:32 ` Srinivas Kandagatla
2018-09-10 7:32 ` Srinivas Kandagatla
2018-09-10 7:58 ` Bartosz Golaszewski
2018-09-10 7:58 ` Bartosz Golaszewski
2018-09-10 8:09 ` Srinivas Kandagatla
2018-09-10 8:09 ` Srinivas Kandagatla
2018-09-10 8:43 ` Bartosz Golaszewski
2018-09-10 8:43 ` Bartosz Golaszewski
2018-09-10 9:55 ` Srinivas Kandagatla
2018-09-10 9:55 ` Srinivas Kandagatla
2018-09-10 11:31 ` Bartosz Golaszewski
2018-09-10 11:31 ` Bartosz Golaszewski
2018-09-10 11:47 ` Srinivas Kandagatla
2018-09-10 11:47 ` Srinivas Kandagatla
2018-09-10 12:18 ` Boris Brezillon
2018-09-10 12:18 ` Boris Brezillon
2018-09-10 12:22 ` Bartosz Golaszewski
2018-09-10 12:22 ` Bartosz Golaszewski
2018-09-10 13:23 ` Srinivas Kandagatla
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 ` Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 03/16] nvmem: use kref Bartosz Golaszewski
2018-09-07 10:07 ` 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 ` Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 05/16] nvmem: sunxi_sid: " Bartosz Golaszewski
2018-09-07 10:07 ` Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 06/16] nvmem: mxs-ocotp: " Bartosz Golaszewski
2018-09-07 10:07 ` Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 07/16] nvmem: change the signature of nvmem_unregister() Bartosz Golaszewski
2018-09-07 10:07 ` Bartosz Golaszewski
2018-09-10 7:33 ` Srinivas Kandagatla
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 ` 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 ` Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 10/16] nvmem: add a notifier chain Bartosz Golaszewski
2018-09-07 10:07 ` Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 11/16] nvmem: add support for cell info Bartosz Golaszewski
2018-09-07 10:07 ` Bartosz Golaszewski
2018-09-10 7:32 ` Srinivas Kandagatla
2018-09-10 7:32 ` Srinivas Kandagatla
2018-09-10 7:36 ` Boris Brezillon
2018-09-10 7:36 ` Boris Brezillon
2018-09-10 8:53 ` Srinivas Kandagatla
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 ` Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 13/16] nvmem: add support for cell lookups from machine code Bartosz Golaszewski
2018-09-07 10:07 ` Bartosz Golaszewski
2018-09-10 7:32 ` Srinivas Kandagatla
2018-09-10 7:32 ` Srinivas Kandagatla
2018-09-10 8:17 ` Bartosz Golaszewski
2018-09-10 8:17 ` Bartosz Golaszewski
2018-09-10 8:23 ` Boris Brezillon
2018-09-10 8:23 ` Boris Brezillon
2018-09-10 8:55 ` Srinivas Kandagatla
2018-09-10 8:55 ` Srinivas Kandagatla
2018-09-10 9:45 ` Bartosz Golaszewski
2018-09-10 9:45 ` Bartosz Golaszewski
2018-09-10 9:49 ` Boris Brezillon [this message]
2018-09-10 9:49 ` Boris Brezillon
2018-09-10 9:50 ` Srinivas Kandagatla
2018-09-10 9:50 ` Srinivas Kandagatla
2018-09-10 11:26 ` Bartosz Golaszewski
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 ` Bartosz Golaszewski
2018-09-07 10:07 ` [PATCH v2 15/16] nvmem: use SPDX license identifiers Bartosz Golaszewski
2018-09-07 10:07 ` 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-07 10:07 ` 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 7:54 ` Srinivas Kandagatla
2018-09-10 8:24 ` Bartosz Golaszewski
2018-09-10 8:24 ` Bartosz Golaszewski
2018-09-10 10:02 ` Srinivas Kandagatla
2018-09-10 10:02 ` Srinivas Kandagatla
2018-09-10 14:58 ` Bartosz Golaszewski
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=20180910114927.083e2de8@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=akpm@linux-foundation.org \
--cc=albeu@free.fr \
--cc=andrew@lunn.ch \
--cc=arnd@arndb.de \
--cc=bgolaszewski@baylibre.com \
--cc=brgl@bgdev.pl \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=david@lechnology.com \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@bootlin.com \
--cc=mchehab+samsung@kernel.org \
--cc=nsekhar@ti.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=wens@csie.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.