All of lore.kernel.org
 help / color / mirror / Atom feed
From: maitysanchayan@gmail.com
To: Rob Herring <robh@kernel.org>
Cc: arnd@arndb.de, Shawn Guo <shawnguo@kernel.org>,
	Stefan Agner <stefan@agner.ch>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform
Date: Thu, 9 Jun 2016 16:08:17 +0530	[thread overview]
Message-ID: <20160609103817.GA14965@Sanchayan-Arch.localdomain> (raw)
In-Reply-To: <20160527100817.GA8294@Sanchayan-Arch.localdomain>

Hello Rob,

On 16-05-27 15:38:17, 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.
> 
> If I can put them at SoC node level then I certainly can use the NVMEM API.
> 

Would the following be acceptable at the SoC node level

> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"

Regards,
Sanchayan.
 

WARNING: multiple messages have this Message-ID (diff)
From: maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: arnd-r2nGTMty4D4@public.gmane.org,
	Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform
Date: Thu, 9 Jun 2016 16:08:17 +0530	[thread overview]
Message-ID: <20160609103817.GA14965@Sanchayan-Arch.localdomain> (raw)
In-Reply-To: <20160527100817.GA8294-2b/appYahYDPUjlVagVGR1Kr0EmMEXJSn9A1Ff6Mc9Q@public.gmane.org>

Hello Rob,

On 16-05-27 15:38:17, maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> On 16-05-27 10:31:55, Arnd Bergmann wrote:
> > On Friday, May 27, 2016 12:03:01 PM CEST maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 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.
> 
> If I can put them at SoC node level then I certainly can use the NVMEM API.
> 

Would the following be acceptable at the SoC node level

> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"

Regards,
Sanchayan.
 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: maitysanchayan@gmail.com (maitysanchayan at gmail.com)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 4/4] soc: Add SoC driver for Freescale Vybrid platform
Date: Thu, 9 Jun 2016 16:08:17 +0530	[thread overview]
Message-ID: <20160609103817.GA14965@Sanchayan-Arch.localdomain> (raw)
In-Reply-To: <20160527100817.GA8294@Sanchayan-Arch.localdomain>

Hello Rob,

On 16-05-27 15:38:17, 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.
> 
> If I can put them at SoC node level then I certainly can use the NVMEM API.
> 

Would the following be acceptable at the SoC node level

> nvmem-cells: phandles to two OCOTP child nodes ocotp_cfg0 and ocotp_cfg1
> nvmem-cell-names: should contain string names "cfg0" and "cfg1"

Regards,
Sanchayan.
 

  parent reply	other threads:[~2016-06-09 10:45 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
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 [this message]
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=20160609103817.GA14965@Sanchayan-Arch.localdomain \
    --to=maitysanchayan@gmail.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=stefan@agner.ch \
    /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.