All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: maitysanchayan@gmail.com
Cc: Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh@kernel.org>,
	Shawn Guo <shawnguo@kernel.org>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform
Date: Fri, 27 May 2016 10:28:45 -0700	[thread overview]
Message-ID: <475f53d2bb4c611bfe1c6652215b8626@agner.ch> (raw)
In-Reply-To: <20160527100817.GA8294@Sanchayan-Arch.localdomain>

On 2016-05-27 03:08, maitysanchayan@gmail.com wrote:
> On 16-05-27 10:31:55, Arnd Bergmann wrote:
>> On Friday, May 27, 2016 12:03:01 PM CEST maitysanchayan@gmail.com wrote:
>> >
>> > So if I understand correctly, the binding at the SoC level is fine.
>> > Keeping that but removing the additional made-up properties, viz. below
>> >
>> > rom-revision: phandle to the on-chip ROM node
>> > mscm: phandle to the MSCM CPU configuration node
>> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
>> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
>> >
>> > would be fine?
>> >
>> > We would have something similar to here
>> > http://www.spinics.net/lists/devicetree/msg80655.html
>> >
>> > but now with the DT binding under SoC bus.
>> >
>>
>>
>> You look up the OTP device as a syscon here, which seems odd since there
>> is already an nvmem driver for it. Shouldn't you use the nvmem API for
>> that?
>>
>> 	Arnd
> 
> I need the following 
> 
> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> to be able to use the NVMEM consumer API.

I did not tested it, but it seems the NVMEM consumer API has some kind
of non-DT fallback:
http://lxr.free-electrons.com/source/drivers/nvmem/core.c#L827

Right now, it seems to me that it does not handle the case where we have
a of_node but don't want to use it... You might need to add some extra
handling if there is a of_node without nvmem-cell-names/nvmem-cells, and
fall back to nvmem_cell_get_from_list.

--
Stefan

WARNING: multiple messages have this Message-ID (diff)
From: Stefan Agner <stefan@agner.ch>
To: maitysanchayan@gmail.com
Cc: Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh@kernel.org>,
	Shawn Guo <shawnguo@kernel.org>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform
Date: Fri, 27 May 2016 10:28:45 -0700	[thread overview]
Message-ID: <475f53d2bb4c611bfe1c6652215b8626@agner.ch> (raw)
In-Reply-To: <20160527100817.GA8294@Sanchayan-Arch.localdomain>

On 2016-05-27 03:08, maitysanchayan@gmail.com wrote:
> On 16-05-27 10:31:55, Arnd Bergmann wrote:
>> On Friday, May 27, 2016 12:03:01 PM CEST maitysanchayan@gmail.com wrote:
>> >
>> > So if I understand correctly, the binding at the SoC level is fine.
>> > Keeping that but removing the additional made-up properties, viz. below
>> >
>> > rom-revision: phandle to the on-chip ROM node
>> > mscm: phandle to the MSCM CPU configuration node
>> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
>> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
>> >
>> > would be fine?
>> >
>> > We would have something similar to here
>> > http://www.spinics.net/lists/devicetree/msg80655.html
>> >
>> > but now with the DT binding under SoC bus.
>> >
>>
>>
>> You look up the OTP device as a syscon here, which seems odd since there
>> is already an nvmem driver for it. Shouldn't you use the nvmem API for
>> that?
>>
>> 	Arnd
> 
> I need the following 
> 
> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> to be able to use the NVMEM consumer API.

I did not tested it, but it seems the NVMEM consumer API has some kind
of non-DT fallback:
http://lxr.free-electrons.com/source/drivers/nvmem/core.c#L827

Right now, it seems to me that it does not handle the case where we have
a of_node but don't want to use it... You might need to add some extra
handling if there is a of_node without nvmem-cell-names/nvmem-cells, and
fall back to nvmem_cell_get_from_list.

WARNING: multiple messages have this Message-ID (diff)
From: stefan@agner.ch (Stefan Agner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform
Date: Fri, 27 May 2016 10:28:45 -0700	[thread overview]
Message-ID: <475f53d2bb4c611bfe1c6652215b8626@agner.ch> (raw)
In-Reply-To: <20160527100817.GA8294@Sanchayan-Arch.localdomain>

On 2016-05-27 03:08, maitysanchayan at gmail.com wrote:
> On 16-05-27 10:31:55, Arnd Bergmann wrote:
>> On Friday, May 27, 2016 12:03:01 PM CEST maitysanchayan at gmail.com wrote:
>> >
>> > So if I understand correctly, the binding at the SoC level is fine.
>> > Keeping that but removing the additional made-up properties, viz. below
>> >
>> > rom-revision: phandle to the on-chip ROM node
>> > mscm: phandle to the MSCM CPU configuration node
>> > nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
>> > nvmem-cell-names: should contain string names "cfg0" and "cfg1"
>> >
>> > would be fine?
>> >
>> > We would have something similar to here
>> > http://www.spinics.net/lists/devicetree/msg80655.html
>> >
>> > but now with the DT binding under SoC bus.
>> >
>>
>>
>> You look up the OTP device as a syscon here, which seems odd since there
>> is already an nvmem driver for it. Shouldn't you use the nvmem API for
>> that?
>>
>> 	Arnd
> 
> I need the following 
> 
> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"
> 
> to be able to use the NVMEM consumer API.

I did not tested it, but it seems the NVMEM consumer API has some kind
of non-DT fallback:
http://lxr.free-electrons.com/source/drivers/nvmem/core.c#L827

Right now, it seems to me that it does not handle the case where we have
a of_node but don't want to use it... You might need to add some extra
handling if there is a of_node without nvmem-cell-names/nvmem-cells, and
fall back to nvmem_cell_get_from_list.

--
Stefan

  reply	other threads:[~2016-05-27 17:32 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-20 10:02 [PATCH v3 0/4] Implement SoC driver for Vybrid Sanchayan Maity
2016-05-20 10:02 ` Sanchayan Maity
2016-05-20 10:02 ` Sanchayan Maity
2016-05-20 10:02 ` [PATCH v3 1/4] ARM: dts: vfxxx: Add device tree node for OCOTP Sanchayan Maity
2016-05-20 10:02   ` Sanchayan Maity
2016-05-20 10:02   ` Sanchayan Maity
2016-05-20 10:02 ` [PATCH v3 2/4] ARM: dts: vfxxx: Add On-Chip ROM node for Vybrid Sanchayan Maity
2016-05-20 10:02   ` Sanchayan Maity
2016-05-20 10:02   ` Sanchayan Maity
2016-05-20 10:02 ` [PATCH v3 3/4] ARM: dts: vfxxx: Add device tree node required by Vybrid SoC driver Sanchayan Maity
2016-05-20 10:02   ` Sanchayan Maity
2016-05-20 10:02   ` Sanchayan Maity
2016-05-20 10:02 ` [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform Sanchayan Maity
2016-05-20 10:02   ` Sanchayan Maity
2016-05-23 21:18   ` Rob Herring
2016-05-23 21:18     ` Rob Herring
2016-05-24  4:14     ` maitysanchayan
2016-05-24  4:14       ` maitysanchayan at gmail.com
2016-05-24 17:09       ` Rob Herring
2016-05-24 17:09         ` Rob Herring
2016-05-24 17:09         ` Rob Herring
2016-05-25 15:18         ` Arnd Bergmann
2016-05-25 15:18           ` Arnd Bergmann
2016-05-25 15:18           ` Arnd Bergmann
2016-05-27  6:33         ` maitysanchayan
2016-05-27  6:33           ` maitysanchayan at gmail.com
2016-05-27  6:33           ` maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w
2016-05-27  8:31           ` Arnd Bergmann
2016-05-27  8:31             ` Arnd Bergmann
2016-05-27  8:31             ` Arnd Bergmann
2016-05-27 10:08             ` maitysanchayan
2016-05-27 10:08               ` maitysanchayan at gmail.com
2016-05-27 10:08               ` maitysanchayan
2016-05-27 17:28               ` Stefan Agner [this message]
2016-05-27 17:28                 ` Stefan Agner
2016-05-27 17:28                 ` Stefan Agner
2016-05-27 17:56                 ` maitysanchayan
2016-05-27 17:56                   ` maitysanchayan at gmail.com
2016-06-09 10:38               ` maitysanchayan
2016-06-09 10:38                 ` maitysanchayan at gmail.com
2016-06-09 10:38                 ` maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w

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=475f53d2bb4c611bfe1c6652215b8626@agner.ch \
    --to=stefan@agner.ch \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maitysanchayan@gmail.com \
    --cc=robh@kernel.org \
    --cc=shawnguo@kernel.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.