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
