All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Joachim Eastwood <manabian@gmail.com>,
	"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>,
	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 11/13] nvmem: add support for cell lookups from machine code
Date: Wed, 5 Sep 2018 16:59:45 +0200	[thread overview]
Message-ID: <20180905165945.6101d62e@bbrezillon> (raw)
In-Reply-To: <CAMRc=MfbiwRPP9=0e4P-8zYOPhXvT7kL8=W8C2E27HXuCE2Aew@mail.gmail.com>

On Wed, 5 Sep 2018 16:47:57 +0200
Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> 2018-09-05 16:21 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
> > On Wed, 5 Sep 2018 16:00:36 +0200
> > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >  
> >> 2018-09-05 15:57 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:  
> >> > On Wed,  5 Sep 2018 11:57:36 +0200
> >> > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >> >  
> >> >>
> >> >> +struct nvmem_cell_lookup {
> >> >> +     const char              *nvmem_name;
> >> >> +     const char              *dev_id;  
> >> >
> >> > Shouldn't we have a con_id here?
> >> >  
> >> >> +     const char              *cell_id;
> >> >> +     struct list_head        node;
> >> >> +};  
> >>
> >> I wanted to stay in line with the current API - nvmem_cell_get() takes
> >> as argument a string called cell_id. I wanted to reflect that here.  
> >
> > Actually, you need both. con_id is the name you would have in your DT
> > in the nvmem-cell-names property, cell_id is the name of the cell
> > you'd find under the nvmem device node.
> >
> > Let's take an example:
> >
> >         mydev {
> >                 #nvmem-cell-names = "mac-address", "revision";
> >                 #nvmem-cells = <&cell1>, <&cell2>;
> >         };
> >
> >         mynvmemdev {
> >                 #size-cells = <1>;
> >                 #address-cells = <1>;
> >
> >                 cell1: foo@0 {
> >                         reg = <0x0 0x6>;
> >                 };
> >
> >                 cell2: bar@6 {
> >                         reg = <0x6 0x10>;
> >                 };
> >         };
> >
> > this can be described the same way using a consumer lookup table:
> >
> > struct nvmem_cell_lookup_entry {
> >         const char *con_id;
> >         const char *nvmem_name;
> >         const char *cell_name;
> > };
> >
> > struct nvmem_cell_lookup_table {
> >         struct list_head node;
> >         const char *dev_id;
> >         unsigned int nentries;
> >         const struct nvmem_cell_lookup_entry *entries;
> > }
> >
> > static const struct nvmem_cell_lookup_entry mydev_nvmem_cells[] = {
> >         {
> >                 .con_id = "mac-address",
> >                 .nvmem_name = "mynvmemdev",
> >                 .cell_name = "foo",
> >         },
> >         {
> >                 .con_id = "revision",
> >                 .nvmem_name = "mynvmemdev",
> >                 .cell_name = "bar",
> >         },
> > }
> >
> > static const struct nvmem_cell_lookup_table mydev_nvmem_lookup = {
> >         .dev_id = "mydev.0",
> >         .nentries = ARRAY_SIZE(mydev_nvmem_cells),
> >         .entries = mydev_nvmem_cells,
> > };
> >
> >
> > ...
> >
> >         nvmem_add_cell_lookups(&mydev_nvmem_lookup);  
> 
> Ok I get it. Shouldn't we change the argument name of nvmem_cell_get()
> and friends from 'name' to 'con_id' or simply 'id' similarly to what
> other frameworks do to avoid such confusion?

I'll let Srinivas answer that one.

> 
> I also don't see a need for splitting the lookup into two structures
> here. Something like:
> 
> struct nvmem_cell_lookup {
>         const char *nvmem_name;
>         const char *cell_name;
>         const char *dev_id;
>         const char *con_id;
> };
> 
> Would be perfectly fine and would allow to register all lookups for
> given machine with a single call.

Yep, makes sense.

WARNING: multiple messages have this Message-ID (diff)
From: boris.brezillon@bootlin.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 11/13] nvmem: add support for cell lookups from machine code
Date: Wed, 5 Sep 2018 16:59:45 +0200	[thread overview]
Message-ID: <20180905165945.6101d62e@bbrezillon> (raw)
In-Reply-To: <CAMRc=MfbiwRPP9=0e4P-8zYOPhXvT7kL8=W8C2E27HXuCE2Aew@mail.gmail.com>

On Wed, 5 Sep 2018 16:47:57 +0200
Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> 2018-09-05 16:21 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:
> > On Wed, 5 Sep 2018 16:00:36 +0200
> > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >  
> >> 2018-09-05 15:57 GMT+02:00 Boris Brezillon <boris.brezillon@bootlin.com>:  
> >> > On Wed,  5 Sep 2018 11:57:36 +0200
> >> > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >> >  
> >> >>
> >> >> +struct nvmem_cell_lookup {
> >> >> +     const char              *nvmem_name;
> >> >> +     const char              *dev_id;  
> >> >
> >> > Shouldn't we have a con_id here?
> >> >  
> >> >> +     const char              *cell_id;
> >> >> +     struct list_head        node;
> >> >> +};  
> >>
> >> I wanted to stay in line with the current API - nvmem_cell_get() takes
> >> as argument a string called cell_id. I wanted to reflect that here.  
> >
> > Actually, you need both. con_id is the name you would have in your DT
> > in the nvmem-cell-names property, cell_id is the name of the cell
> > you'd find under the nvmem device node.
> >
> > Let's take an example:
> >
> >         mydev {
> >                 #nvmem-cell-names = "mac-address", "revision";
> >                 #nvmem-cells = <&cell1>, <&cell2>;
> >         };
> >
> >         mynvmemdev {
> >                 #size-cells = <1>;
> >                 #address-cells = <1>;
> >
> >                 cell1: foo at 0 {
> >                         reg = <0x0 0x6>;
> >                 };
> >
> >                 cell2: bar at 6 {
> >                         reg = <0x6 0x10>;
> >                 };
> >         };
> >
> > this can be described the same way using a consumer lookup table:
> >
> > struct nvmem_cell_lookup_entry {
> >         const char *con_id;
> >         const char *nvmem_name;
> >         const char *cell_name;
> > };
> >
> > struct nvmem_cell_lookup_table {
> >         struct list_head node;
> >         const char *dev_id;
> >         unsigned int nentries;
> >         const struct nvmem_cell_lookup_entry *entries;
> > }
> >
> > static const struct nvmem_cell_lookup_entry mydev_nvmem_cells[] = {
> >         {
> >                 .con_id = "mac-address",
> >                 .nvmem_name = "mynvmemdev",
> >                 .cell_name = "foo",
> >         },
> >         {
> >                 .con_id = "revision",
> >                 .nvmem_name = "mynvmemdev",
> >                 .cell_name = "bar",
> >         },
> > }
> >
> > static const struct nvmem_cell_lookup_table mydev_nvmem_lookup = {
> >         .dev_id = "mydev.0",
> >         .nentries = ARRAY_SIZE(mydev_nvmem_cells),
> >         .entries = mydev_nvmem_cells,
> > };
> >
> >
> > ...
> >
> >         nvmem_add_cell_lookups(&mydev_nvmem_lookup);  
> 
> Ok I get it. Shouldn't we change the argument name of nvmem_cell_get()
> and friends from 'name' to 'con_id' or simply 'id' similarly to what
> other frameworks do to avoid such confusion?

I'll let Srinivas answer that one.

> 
> I also don't see a need for splitting the lookup into two structures
> here. Something like:
> 
> struct nvmem_cell_lookup {
>         const char *nvmem_name;
>         const char *cell_name;
>         const char *dev_id;
>         const char *con_id;
> };
> 
> Would be perfectly fine and would allow to register all lookups for
> given machine with a single call.

Yep, makes sense.

  reply	other threads:[~2018-09-05 14:59 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05  9:57 [PATCH 00/13] nvmem: rework of the subsystem for non-DT users Bartosz Golaszewski
2018-09-05  9:57 ` Bartosz Golaszewski
2018-09-05  9:57 ` [PATCH 01/13] nvmem: remove unused APIs Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-05  9:57 ` [PATCH 02/13] nvmem: remove the global cell list Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-05  9:57 ` [PATCH 03/13] nvmem: use kref Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-05  9:57 ` [PATCH 04/13] nvmem: lpc18xx_eeprom: use devm_nvmem_register() Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-05  9:57 ` [PATCH 05/13] nvmem: change the signature of nvmem_unregister() Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-07  4:48   ` kbuild test robot
2018-09-07  4:48     ` kbuild test robot
2018-09-07  4:57   ` kbuild test robot
2018-09-07  4:57     ` kbuild test robot
2018-09-05  9:57 ` [PATCH 06/13] nvmem: provide nvmem_dev_name() Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-05  9:57 ` [PATCH 07/13] nvmem: remove the name field from struct nvmem_device Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-05  9:57 ` [PATCH 08/13] nvmem: add a notifier chain Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-07  5:11   ` kbuild test robot
2018-09-07  5:11     ` kbuild test robot
2018-09-05  9:57 ` [PATCH 09/13] nvmem: add support for cell info Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-05  9:57 ` [PATCH 10/13] nvmem: resolve cells from DT at registration time Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-05  9:57 ` [PATCH 11/13] nvmem: add support for cell lookups from machine code Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-05 13:57   ` Boris Brezillon
2018-09-05 13:57     ` Boris Brezillon
2018-09-05 14:00     ` Bartosz Golaszewski
2018-09-05 14:00       ` Bartosz Golaszewski
2018-09-05 14:21       ` Boris Brezillon
2018-09-05 14:21         ` Boris Brezillon
2018-09-05 14:47         ` Bartosz Golaszewski
2018-09-05 14:47           ` Bartosz Golaszewski
2018-09-05 14:59           ` Boris Brezillon [this message]
2018-09-05 14:59             ` Boris Brezillon
2018-09-05  9:57 ` [PATCH 12/13] Documentation: nvmem: document cell tables and lookup entries Bartosz Golaszewski
2018-09-05  9:57   ` Bartosz Golaszewski
2018-09-05  9:57 ` [PATCH 13/13] nvmem: use SPDX license identifiers Bartosz Golaszewski
2018-09-05  9:57   ` 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=20180905165945.6101d62e@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=manabian@gmail.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=mchehab+samsung@kernel.org \
    --cc=nsekhar@ti.com \
    --cc=srinivas.kandagatla@linaro.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.