linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vadym Kochan <vadym.kochan@plvision.eu>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Taras Chornyi <taras.chornyi@plvision.eu>
Subject: Re: [PATCH v2 2/2] nvmem: add ONIE NVMEM cells support
Date: Fri, 5 Jun 2020 13:53:51 +0300	[thread overview]
Message-ID: <20200605105351.GA1118@plvision.eu> (raw)
In-Reply-To: <20200601102749.GA25323@plvision.eu>

Hi Srinivas,

On Mon, Jun 01, 2020 at 01:27:49PM +0300, Vadym Kochan wrote:
> On Mon, Jun 01, 2020 at 10:13:05AM +0100, Srinivas Kandagatla wrote:
> > 
> > 
> > On 01/06/2020 10:03, Vadym Kochan wrote:
> > > > > +
> > > > > +	nvmem = of_nvmem_device_get(np, NULL);
> > > > > +	if (IS_ERR(nvmem))
> > > > > +		return PTR_ERR(nvmem);
> > > > > +
> > > > TBH, this looks completely incorrect way to do this and misuse of nvmem
> > > > consumer interface.
> > > > 
> > > > Ideally nvmem provider driver should populate "cells" in struct nvmem_config
> > > > after decoding them and then register nvmem provider.
> > > > 
> > > > That should just work!
> > > > 
> > > > 
> > > > --srini
> > > But this is not nvmem provider but just describes the cells for any
> > > nvmem device, because ONIE uses special TLV structure on the nvmem
> > > device. So from the nvmem device point it is a consumer but provides the cells
> > > for the given device.
> > 
> > That still falls under nvmem providers responsibility to parse these cells
> > before registering it.
> OK, I thought that it is legal to have separate nvmem driver which
> provides access to the device itself, and other driver which describes the
> layout of the cells which might be applicable to any nvmem.
> 
> > 
> > BTW, where is the provider driver for this in kernel ?
> > 
> > 
> > --srini
> > 
> > > 
> One of the example is atmel eeprom (at24), but there might be different
> devices.
> 
> But can you please explain what is the technical/conceptual issue with
> this approach ?
> 
> Thanks,

I just I'd like to clarify if there is a way it can be acceptable. The
problem is that there is TLV format which  might be used on any nvmem
device which contains for example mac address which needs to be exposed
as nvmem cell. If to populate cells via nvmem_config then anyway I need
to parse these cells from the "target" nvmem device.

Thanks,

  reply	other threads:[~2020-06-05 10:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 23:04 [PATCH v2 0/2] nvmem: add ONIE NVMEM cells provider Vadym Kochan
2020-05-29 23:04 ` [PATCH v2 1/2] nvmem: core: allow to register cells for existing device Vadym Kochan
2020-05-29 23:04 ` [PATCH v2 2/2] nvmem: add ONIE NVMEM cells support Vadym Kochan
2020-06-01  8:50   ` Srinivas Kandagatla
2020-06-01  9:03     ` Vadym Kochan
2020-06-01  9:13       ` Srinivas Kandagatla
2020-06-01 10:27         ` Vadym Kochan
2020-06-05 10:53           ` Vadym Kochan [this message]
2020-06-15 11:06             ` Srinivas Kandagatla
2020-08-14 11:56               ` Vadym Kochan

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=20200605105351.GA1118@plvision.eu \
    --to=vadym.kochan@plvision.eu \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=taras.chornyi@plvision.eu \
    /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).