All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>, Wei Xu <xuwei5@hisilicon.com>,
	Rob Herring <robh+dt@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Collabora Kernel ML <kernel@collabora.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFT PATCH 5/5] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
Date: Wed, 6 May 2020 13:57:05 +0300	[thread overview]
Message-ID: <20200506105705.GA5946@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20200506082332.57ptj42mkrrn4ceo@rcn-XPS-13-9360>

On Wed, May 06, 2020 at 10:23:32AM +0200, Ricardo Cañuelo wrote:
> Hi Geert,
> 
> Thanks for reviewing the patches. Some comments below,
> 
> On mié 06-05-2020 09:44:19, Geert Uytterhoeven wrote: 
> > Can't you avoid the need for patches
> > [RFT PATCH 1/5] arm64: dts: draak: Reorder hdmi-encoder@39 reg and
> > reg-names properties
> > [RFT PATCH 2/5] ARM: dts: wheat: reorder reg and reg-names properties
> > in hdmi bridges
> > 
> > by using
> > 
> >     items:
> >       enum:
> >         - main
> >         - edid
> >         - cec
> >         - packet
> > 
> > instead?
> 
> Not really, because that defines a scalar property that can take any of
> those values (if I'm not mistaken), and the core schema enforces that
> reg-names must be an array.
> 
> I think the closest I can get to what you mean would be something like
> this:
> 
>     items:
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
> 
> But then that wouldn't prevent anyone from defining duplicate reg-names
> (eg. "main", "cec", edid", "cec"), which is even worse IMO.

The direction DT bindings are taking is to enfore a particular order. It
will cause DT validation errors for old device trees, but it won't break
backward compatibility as the order won't be enforced at runtime, so I
think that's fine. Tidying up the existing DT sources to use a
consistent order seems best to me.

-- 
Regards,

Laurent Pinchart

_______________________________________________
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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Collabora Kernel ML <kernel@collabora.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Rob Herring <robh+dt@kernel.org>, Wei Xu <xuwei5@hisilicon.com>
Subject: Re: [RFT PATCH 5/5] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
Date: Wed, 6 May 2020 13:57:05 +0300	[thread overview]
Message-ID: <20200506105705.GA5946@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20200506082332.57ptj42mkrrn4ceo@rcn-XPS-13-9360>

On Wed, May 06, 2020 at 10:23:32AM +0200, Ricardo Cañuelo wrote:
> Hi Geert,
> 
> Thanks for reviewing the patches. Some comments below,
> 
> On mié 06-05-2020 09:44:19, Geert Uytterhoeven wrote: 
> > Can't you avoid the need for patches
> > [RFT PATCH 1/5] arm64: dts: draak: Reorder hdmi-encoder@39 reg and
> > reg-names properties
> > [RFT PATCH 2/5] ARM: dts: wheat: reorder reg and reg-names properties
> > in hdmi bridges
> > 
> > by using
> > 
> >     items:
> >       enum:
> >         - main
> >         - edid
> >         - cec
> >         - packet
> > 
> > instead?
> 
> Not really, because that defines a scalar property that can take any of
> those values (if I'm not mistaken), and the core schema enforces that
> reg-names must be an array.
> 
> I think the closest I can get to what you mean would be something like
> this:
> 
>     items:
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
> 
> But then that wouldn't prevent anyone from defining duplicate reg-names
> (eg. "main", "cec", edid", "cec"), which is even worse IMO.

The direction DT bindings are taking is to enfore a particular order. It
will cause DT validation errors for old device trees, but it won't break
backward compatibility as the order won't be enforced at runtime, so I
think that's fine. Tidying up the existing DT sources to use a
consistent order seems best to me.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2020-05-06 10:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-01  8:32 [RFT PATCH 0/5] Convert adi,adv7511.txt DT bindings to yaml Ricardo Cañuelo
2020-05-01  8:32 ` Ricardo Cañuelo
2020-05-01  8:32 ` [RFT PATCH 1/5] arm64: dts: draak: Reorder hdmi-encoder@39 reg and reg-names properties Ricardo Cañuelo
2020-05-01  8:32   ` Ricardo Cañuelo
2020-05-01  8:32 ` [RFT PATCH 2/5] ARM: dts: wheat: reorder reg and reg-names properties in hdmi bridges Ricardo Cañuelo
2020-05-01  8:32   ` Ricardo Cañuelo
2020-05-01  8:32 ` [RFT PATCH 3/5] ARM: dts: zynq: add port definitions to hdmi-tx@39 Ricardo Cañuelo
2020-05-01  8:32   ` Ricardo Cañuelo
2020-05-01  8:32 ` [RFT PATCH 4/5] arm64: dts: hisilicon: hikey960: add missing hdmi bridge properties Ricardo Cañuelo
2020-05-01  8:32   ` Ricardo Cañuelo
2020-05-01  8:32 ` [RFT PATCH 5/5] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml Ricardo Cañuelo
2020-05-01  8:32   ` [RFT PATCH 5/5] dt-bindings: drm: bridge: adi,adv7511.txt: " Ricardo Cañuelo
2020-05-05 18:56   ` Rob Herring
2020-05-05 18:56     ` Rob Herring
2020-05-06 13:10     ` Ricardo Cañuelo
2020-05-06 13:10       ` Ricardo Cañuelo
2020-05-06 18:43       ` Rob Herring
2020-05-06 18:43         ` Rob Herring
2020-05-06  7:44   ` Geert Uytterhoeven
2020-05-06  7:44     ` Geert Uytterhoeven
2020-05-06  8:23     ` Ricardo Cañuelo
2020-05-06  8:23       ` Ricardo Cañuelo
2020-05-06 10:57       ` Laurent Pinchart [this message]
2020-05-06 10:57         ` Laurent Pinchart
2020-05-06 12:59         ` Rob Herring
2020-05-06 12:59           ` Rob Herring

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=20200506105705.GA5946@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=kernel@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=ricardo.canuelo@collabora.com \
    --cc=robh+dt@kernel.org \
    --cc=xuwei5@hisilicon.com \
    /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.