All of lore.kernel.org
 help / color / mirror / Atom feed
From: srinivas.kandagatla@linaro.org (Srinivas Kandagatla)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support
Date: Wed, 24 Jun 2015 10:34:43 +0100	[thread overview]
Message-ID: <558A79B3.1010205@linaro.org> (raw)
In-Reply-To: <20150624083529.GY2266@lukather>



On 24/06/15 09:35, Maxime Ripard wrote:
> Hi,
>
> On Tue, Jun 23, 2015 at 07:14:57PM +0530, Sanchayan Maity wrote:
>> +static struct nvmem_config ocotp_config = {
>> +	.name = "soc_id",
>> +};
>> +
>> +static struct nvmem_config rom_config = {
>> +	.name = "rom_rev",
>> +};
>
> Srinivas, shouldn't we use the DT to setup these names, just like
> clock-output-names does for example?
These are the provider names, which would not change per board, I think. :-)

On the other hand if we are going to use generic drivers like 
"simple-mmio-nvmem" then having name DT bindings makes sense.

IMO, clock-output-names are analogous to nvmem consumers, which are 
obviously getting there names from cell node name ATM.


>
> This is very likely to change from one board to another, and defining
> a new compatible and/or driver for each board seems a bit fishy.
>
Do you have any particular example in mind, where the provider names 
would change per board?

--srini

> Maxime
>

WARNING: multiple messages have this Message-ID (diff)
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Maxime Ripard <maxime.ripard@free-electrons.com>,
	Sanchayan Maity <maitysanchayan@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org, arnd@arndb.de,
	linux-kernel@vger.kernel.org, stefan@agner.ch,
	kernel@pengutronix.de, shawn.guo@linaro.org
Subject: Re: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support
Date: Wed, 24 Jun 2015 10:34:43 +0100	[thread overview]
Message-ID: <558A79B3.1010205@linaro.org> (raw)
In-Reply-To: <20150624083529.GY2266@lukather>



On 24/06/15 09:35, Maxime Ripard wrote:
> Hi,
>
> On Tue, Jun 23, 2015 at 07:14:57PM +0530, Sanchayan Maity wrote:
>> +static struct nvmem_config ocotp_config = {
>> +	.name = "soc_id",
>> +};
>> +
>> +static struct nvmem_config rom_config = {
>> +	.name = "rom_rev",
>> +};
>
> Srinivas, shouldn't we use the DT to setup these names, just like
> clock-output-names does for example?
These are the provider names, which would not change per board, I think. :-)

On the other hand if we are going to use generic drivers like 
"simple-mmio-nvmem" then having name DT bindings makes sense.

IMO, clock-output-names are analogous to nvmem consumers, which are 
obviously getting there names from cell node name ATM.


>
> This is very likely to change from one board to another, and defining
> a new compatible and/or driver for each board seems a bit fishy.
>
Do you have any particular example in mind, where the provider names 
would change per board?

--srini

> Maxime
>

  reply	other threads:[~2015-06-24  9:34 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-23 13:44 [RFC PATCH v6 0/2] Implement NVMEM/SoC bus support for Vybrid Sanchayan Maity
2015-06-23 13:44 ` Sanchayan Maity
2015-06-23 13:44 ` [RFC PATCH v6 1/2] ARM: dts: vfxxx: Add OCOTP and OCROM nodes Sanchayan Maity
2015-06-23 13:44   ` Sanchayan Maity
2015-06-23 13:44 ` [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support Sanchayan Maity
2015-06-23 13:44   ` Sanchayan Maity
2015-06-23 19:03   ` Srinivas Kandagatla
2015-06-23 19:03     ` Srinivas Kandagatla
2015-06-24  5:25     ` maitysanchayan at gmail.com
2015-06-24  5:25       ` maitysanchayan
2015-06-23 19:31   ` Stefan Wahren
2015-06-23 19:31     ` Stefan Wahren
2015-06-24  5:19     ` maitysanchayan at gmail.com
2015-06-24  5:19       ` maitysanchayan
2015-06-24  9:37       ` Srinivas Kandagatla
2015-06-24  9:37         ` Srinivas Kandagatla
2015-06-24  9:44         ` Sanchayan Maity
2015-06-24  9:44           ` Sanchayan Maity
2015-06-24  9:56       ` Stefan Wahren
2015-06-24  9:56         ` Stefan Wahren
2015-06-24 10:45         ` maitysanchayan at gmail.com
2015-06-24 10:45           ` maitysanchayan
2015-06-24 11:52           ` Stefan Wahren
2015-06-24 11:52             ` Stefan Wahren
2015-06-24 12:05             ` maitysanchayan at gmail.com
2015-06-24 12:05               ` maitysanchayan
2015-06-29 11:22             ` [RFC PATCH v6 0/3] Implement NVMEM/SoC bus support for Vybrid Sanchayan Maity
2015-06-29 11:22               ` Sanchayan Maity
2015-06-29 11:22               ` [RFC PATCH v6 1/3] clk: clk-vf610: Add clock for Vybrid OCOTP controller Sanchayan Maity
2015-06-29 11:22                 ` Sanchayan Maity
2015-06-29 11:22               ` [RFC PATCH v6 2/3] ARM: dts: vfxxx: Add OCOTP node Sanchayan Maity
2015-06-29 11:22                 ` Sanchayan Maity
2015-06-29 11:22               ` [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support Sanchayan Maity
2015-06-29 11:22                 ` Sanchayan Maity
2015-07-06 10:16                 ` Stefan Wahren
2015-07-06 10:16                   ` Stefan Wahren
2015-07-07  5:19                   ` maitysanchayan at gmail.com
2015-07-07  5:19                     ` maitysanchayan
2015-07-07 12:49                     ` Stefan Wahren
2015-07-07 12:49                       ` Stefan Wahren
2015-07-08  5:39                       ` maitysanchayan at gmail.com
2015-07-08  5:39                         ` maitysanchayan
2015-07-08 20:55                         ` Stefan Wahren
2015-07-08 20:55                           ` Stefan Wahren
2015-07-10 18:09                           ` maitysanchayan at gmail.com
2015-07-10 18:09                             ` maitysanchayan
2015-06-24 11:20         ` [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support Stefan Agner
2015-06-24 11:20           ` Stefan Agner
2015-06-24  8:35   ` Maxime Ripard
2015-06-24  8:35     ` Maxime Ripard
2015-06-24  9:34     ` Srinivas Kandagatla [this message]
2015-06-24  9:34       ` Srinivas Kandagatla
2015-06-25 17:49       ` Maxime Ripard
2015-06-25 17:49         ` Maxime Ripard

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=558A79B3.1010205@linaro.org \
    --to=srinivas.kandagatla@linaro.org \
    --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 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.