On Wed, May 6, 2020 at 5:57 AM Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > 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. No, 'items' as a schema rather than a list applies to every element in 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. Yes. It's not a new direction though. The order was always supposed to be defined, it's just enforceable now. Rob
