From: Vadym Kochan <vadym.kochan@plvision.eu>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Maxime Ripard <maxime.ripard@free-electrons.com>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/3] nvmem: core: allow to register cells during nvmem registration
Date: Fri, 11 Sep 2020 19:59:02 +0300 [thread overview]
Message-ID: <20200911165902.GA20711@plvision.eu> (raw)
In-Reply-To: <20200904112310.GD10654@plvision.eu>
Hi Srinivas,
On Fri, Sep 04, 2020 at 02:23:10PM +0300, Vadym Kochan wrote:
> Hi Srinivas,
>
> On Fri, Sep 04, 2020 at 12:02:40PM +0100, Srinivas Kandagatla wrote:
> > Hi Vadym,
> >
> > Thanks for the patch,
> > On 31/08/2020 02:55, Vadym Kochan wrote:
> > > Add NVMEM_PRE_ADD notification step which is called before any cells
> > > binding - from lookup table or config, this allows to register cells
> > > in some specific layout (tlv) which should be parsed first and then
> > > registered. So there might be a cell parser driver which can register
> > > lookup table during this notification step.
> > >
> > This is going in right direction but totally not correct way to do it.
> >
> > 1> this is not scalable as any consumer that will register for this even
> > will have no idea of which what kind of parsing that provider needs.
> > It can work in your case but not really useful.
> >
> > 2> this is a consumer API, not the provider api.
> >
> > How about adding a "parse_cells" callback in struct nvmem_config along with
> > encoding type.
> >
> >
> > thanks,
> > srini
> >
>
> Looks like I missed main point here that this cells parser should be
> registered as nvmem provider. I will think on it.
>
> Thanks,
>
I am trying to re-work this approach, but still I need to clarify
something.
It looks strange that this cells parser should be a nvmem provider (or I
missed something) but I remember that you suggested about introducing
something like nvmem parser. And adding nvmem parser looks more clear
for me, because what it should do is just access the nvmem device during
its registration and provide list of cells, that's all:
struct nvmem_device *nvmem_register(const struct nvmem_config *config)
{
struct nvmem_cell_table table = { };
...
parser = find_nvmem_parser();
/* I think that cell lookups may be added on the parser's probe
statically */
parser->parse_cells(parser->priv, nvmem, &table);
...
}
/* here I used struct nvmem_config, not sure it is a right way to
mix nvmem's and parser's struct fields, so may be something like
struct nvmem_parser_config might be introduced or fill the struct
nvmem_parser directly by the driver and pass it to the registration func */
struct nvmem_parser *nvmem_parser_register(const struct nvmem_config *config)
{
...
}
void nvmem_parser_unregister(struct nvmem_parser *parser)
{
...
}
Regards,
Vadym Kochan
next prev parent reply other threads:[~2020-09-11 16:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 1:55 [PATCH v3 0/3] nvmem: add ONIE NVMEM cells provider Vadym Kochan
2020-08-31 1:55 ` [PATCH v3 1/3] nvmem: core: allow to register cells during nvmem registration Vadym Kochan
2020-09-04 11:02 ` Srinivas Kandagatla
2020-09-04 11:23 ` Vadym Kochan
2020-09-11 16:59 ` Vadym Kochan [this message]
2020-08-31 1:55 ` [PATCH v3 2/3] nvmem: add ONIE NVMEM cells support Vadym Kochan
2020-09-04 11:02 ` Srinivas Kandagatla
2020-08-31 1:55 ` [PATCH v3 3/3] misc: eeprom: at24: register nvmem only after eeprom is ready to use Vadym Kochan
2020-08-31 17:21 ` Bartosz Golaszewski
2020-08-31 17:24 ` Vadym Kochan
2020-09-01 8:06 ` 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=20200911165902.GA20711@plvision.eu \
--to=vadym.kochan@plvision.eu \
--cc=arnd@arndb.de \
--cc=bgolaszewski@baylibre.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@free-electrons.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 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).