All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org,
	Ludovic Desroches <ludovic.desroches@microchip.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: dts: at91: Avoid colliding 'display' node and property names
Date: Tue, 16 Jul 2019 12:15:24 +0200	[thread overview]
Message-ID: <20190716101524.GM4732@piout.net> (raw)
In-Reply-To: <CAL_JsqK0piWGQBeqcOceF=fSX4vSW7_vyv0qAAxz-bg25qEVow@mail.gmail.com>

On 15/07/2019 15:45:24-0600, Rob Herring wrote:
> On Mon, May 20, 2019 at 8:58 AM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 16/05/2019 17:56:14-0500, Rob Herring wrote:
> > > While properties and child nodes with the same name are valid DT, the
> > > practice is not encouraged.
> >
> > I don't see anything mentioning that in the devicetree specification. I
> > think this is something you should add if you don't want that to happen
> > again.
> 
> I suppose, but I prefer tools to enforce it.
> 
> >
> > > Furthermore, the collision is problematic for
> > > YAML encoded DT. Let's just avoid the issue and rename the nodes.
> > >
> >
> > Or maybe you should fix the tool ;)
> 
> You mean the YAML and JSON specifications because the problem is it is
> not valid YAML? (I think YAML allowed it at one time, but it is
> deprecated) The only way to fix it in the tool would be to define some
> way to handle the collision like renaming properties and then undoing
> that.
> 
> > Do you plan to enforce it at some point? How close are you?
> 
> Soon as this patch is merged. There's a switch in parsing tools to
> disallow the collision, so it will be an error instead of a warning.
> 
> > > Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
> > > Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
> > > Cc: linux-arm-kernel@lists.infradead.org
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> >
> > Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> 
> Is someone going to apply this?
> 

I'll apply it for the next cycle, sorry about that.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org,
	Ludovic Desroches <ludovic.desroches@microchip.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: dts: at91: Avoid colliding 'display' node and property names
Date: Tue, 16 Jul 2019 12:15:24 +0200	[thread overview]
Message-ID: <20190716101524.GM4732@piout.net> (raw)
In-Reply-To: <CAL_JsqK0piWGQBeqcOceF=fSX4vSW7_vyv0qAAxz-bg25qEVow@mail.gmail.com>

On 15/07/2019 15:45:24-0600, Rob Herring wrote:
> On Mon, May 20, 2019 at 8:58 AM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 16/05/2019 17:56:14-0500, Rob Herring wrote:
> > > While properties and child nodes with the same name are valid DT, the
> > > practice is not encouraged.
> >
> > I don't see anything mentioning that in the devicetree specification. I
> > think this is something you should add if you don't want that to happen
> > again.
> 
> I suppose, but I prefer tools to enforce it.
> 
> >
> > > Furthermore, the collision is problematic for
> > > YAML encoded DT. Let's just avoid the issue and rename the nodes.
> > >
> >
> > Or maybe you should fix the tool ;)
> 
> You mean the YAML and JSON specifications because the problem is it is
> not valid YAML? (I think YAML allowed it at one time, but it is
> deprecated) The only way to fix it in the tool would be to define some
> way to handle the collision like renaming properties and then undoing
> that.
> 
> > Do you plan to enforce it at some point? How close are you?
> 
> Soon as this patch is merged. There's a switch in parsing tools to
> disallow the collision, so it will be an error instead of a warning.
> 
> > > Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
> > > Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
> > > Cc: linux-arm-kernel@lists.infradead.org
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> >
> > Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> 
> Is someone going to apply this?
> 

I'll apply it for the next cycle, sorry about that.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2019-07-16 10:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 22:56 [PATCH] ARM: dts: at91: Avoid colliding 'display' node and property names Rob Herring
2019-05-16 22:56 ` Rob Herring
2019-05-20  8:27 ` Nicolas.Ferre
2019-05-20  8:27   ` Nicolas.Ferre
2019-05-20 14:58 ` Alexandre Belloni
2019-05-20 14:58   ` Alexandre Belloni
2019-07-15 21:45   ` Rob Herring
2019-07-15 21:45     ` Rob Herring
2019-07-16 10:15     ` Alexandre Belloni [this message]
2019-07-16 10:15       ` Alexandre Belloni

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=20190716101524.GM4732@piout.net \
    --to=alexandre.belloni@bootlin.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=ludovic.desroches@microchip.com \
    --cc=robh@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.