All of lore.kernel.org
 help / color / mirror / Atom feed
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
Date: Thu, 10 Nov 2016 11:15:06 +0100	[thread overview]
Message-ID: <20161110111506.02842cbd@free-electrons.com> (raw)
In-Reply-To: <87wpgbekwg.fsf@free-electrons.com>

Hello,

On Thu, 10 Nov 2016 10:36:47 +0100, Gregory CLEMENT wrote:

> >> -		bootrom {
> >> +		bootrom at 0 {
> >>  			compatible = "marvell,bootrom";
> >>  			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;  
> >
> > I am still not sure whether this "0" unit address is correct compared
> > to the reg property being passed.  
> 
> I chose to use the adress register inside the window memory.

Which I think is bogus, as my example below highlighted.

> > A good example of why I'm worried is the sa-sram case:
> >
> > +		crypto_sram0: sa-sram0 at 0 {
> >  			compatible = "mmio-sram";
> >  			reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
> >
> > +		crypto_sram1: sa-sram1 at 0 {
> >  			compatible = "mmio-sram";
> >  			reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
> >
> > The node names should be just "sram" without a number. Indeed for UARTs
> > for example, you use uart at XYZ, uart at ABC and not uart0 at XYZ and
> > uart1 at ABC. But then, if you do that, with your scheme, you end up with
> > both nodes named sa-sram at 0.
> >
> > Which clearly shows that the way you set this unit-address is not
> > correct: those two devices are mapped at completely different
> > locations, but you end up with an identical unit address.
> >
> > I have no idea what is the rule for setting the unit address in this
> > case, but I'm pretty sure the rule you've chosen is not good.  
> 
> I don't know if there is an existing rules for this case. But I see your
> concern. What I propose then is to expose the memory windows ID by
> adding the target and the attributes like this:
> 
> 		crypto_sram0: sa-sram at 09_09_0 {
>  			compatible = "mmio-sram";
>   			reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
> 
> 
> 		crypto_sram1: sa-sram at 09_05_0 {
>   			compatible = "mmio-sram";
>   			reg = <MBUS_ID(0x09, 0x05) 0 0x800>;

I have no idea if 09_05_0 is considered a valid unit address. Indeed
the _ character in an address looks a bit weird.

I guess we need guidance from the DT binding maintainers on this, since
it's really a matter of interpreting what "unit address" means in
relation to the value of the "reg" property.

Rob, Mark?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Gregory CLEMENT
	<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
	Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>,
	Sebastian Hesselbarth
	<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
Date: Thu, 10 Nov 2016 11:15:06 +0100	[thread overview]
Message-ID: <20161110111506.02842cbd@free-electrons.com> (raw)
In-Reply-To: <87wpgbekwg.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

Hello,

On Thu, 10 Nov 2016 10:36:47 +0100, Gregory CLEMENT wrote:

> >> -		bootrom {
> >> +		bootrom@0 {
> >>  			compatible = "marvell,bootrom";
> >>  			reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;  
> >
> > I am still not sure whether this "0" unit address is correct compared
> > to the reg property being passed.  
> 
> I chose to use the adress register inside the window memory.

Which I think is bogus, as my example below highlighted.

> > A good example of why I'm worried is the sa-sram case:
> >
> > +		crypto_sram0: sa-sram0@0 {
> >  			compatible = "mmio-sram";
> >  			reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
> >
> > +		crypto_sram1: sa-sram1@0 {
> >  			compatible = "mmio-sram";
> >  			reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
> >
> > The node names should be just "sram" without a number. Indeed for UARTs
> > for example, you use uart@XYZ, uart@ABC and not uart0@XYZ and
> > uart1@ABC. But then, if you do that, with your scheme, you end up with
> > both nodes named sa-sram@0.
> >
> > Which clearly shows that the way you set this unit-address is not
> > correct: those two devices are mapped at completely different
> > locations, but you end up with an identical unit address.
> >
> > I have no idea what is the rule for setting the unit address in this
> > case, but I'm pretty sure the rule you've chosen is not good.  
> 
> I don't know if there is an existing rules for this case. But I see your
> concern. What I propose then is to expose the memory windows ID by
> adding the target and the attributes like this:
> 
> 		crypto_sram0: sa-sram@09_09_0 {
>  			compatible = "mmio-sram";
>   			reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
> 
> 
> 		crypto_sram1: sa-sram@09_05_0 {
>   			compatible = "mmio-sram";
>   			reg = <MBUS_ID(0x09, 0x05) 0 0x800>;

I have no idea if 09_05_0 is considered a valid unit address. Indeed
the _ character in an address looks a bit weird.

I guess we need guidance from the DT binding maintainers on this, since
it's really a matter of interpreting what "unit address" means in
relation to the value of the "reg" property.

Rob, Mark?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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

  reply	other threads:[~2016-11-10 10:15 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-10  0:09 [PATCH 00/14] Various Armada 375 DT warning fixup Gregory CLEMENT
2016-11-10  0:09 ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 01/14] ARM: dts: armada-375: Add node labels Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 02/14] ARM: dts: armada-375: Use the " Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 03/14] ARM: dts: armada-375: Fixup mdio DT warning Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom " Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  8:22   ` Thomas Petazzoni
2016-11-10  8:22     ` Thomas Petazzoni
2016-11-10  9:36     ` Gregory CLEMENT
2016-11-10  9:36       ` Gregory CLEMENT
2016-11-10 10:15       ` Thomas Petazzoni [this message]
2016-11-10 10:15         ` Thomas Petazzoni
2016-11-10 10:43         ` Gregory CLEMENT
2016-11-10 10:43           ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 05/14] ARM: dts: armada-375: Fixup devbus " Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 06/14] ARM: dts: armada-375: Fixup sa-ram " Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 07/14] ARM: dts: armada-375: Fixup pcie DT warnings Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 08/14] " Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:22   ` Gregory CLEMENT
2016-11-10  0:22     ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 09/14] ARM: dts: armada-375: Fixup pinctrl " Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 10/14] ARM: dts: armada-375: Fixup soc DT warning Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 11/14] ARM: dts: armada-375: Fixup internal-regs " Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 12/14] ARM: dts: armada-375: Remove skeleton.dtsi Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:09 ` [PATCH 13/14] ARM: dts: armada-375: Fixup memory DT warning Gregory CLEMENT
2016-11-10  0:09   ` Gregory CLEMENT
2016-11-10  0:10 ` [PATCH 14/14] ARM: dts: armada-375: Fixup ethernet child " Gregory CLEMENT
2016-11-10  0:10   ` Gregory CLEMENT

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=20161110111506.02842cbd@free-electrons.com \
    --to=thomas.petazzoni@free-electrons.com \
    --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.