[PATCH v2 3/4] dt-bindings: drm/bridge: ti-sn65dsi83: Add vcc supply bindings

[Sam Ravnborg]

> > > 
> > > That will not help validating that new DTs are compliant with the last
> > > version of the bindings.
> > > 
> > > We have one tool, and two needs. The tool should be extended to cover
> > > both, but today it can only support one. Which of these two is the most
> > > important:
> > > 
> > > - Documentating old behaviour, to helper driver authors on other
> > >   operating systems implement backward compatibility without having to
> > >   look at the history ?
> > > 
> > > - Validating all new device trees to ensure they implement the latest
> > >   recommended version of the bindings ?
> > > 
> > > I think the second one is much more frequent, and is also where most of
> > > the issues will arise.
> > 
> > I understand the drive for the latter, but we shouldn't be dropping the
> > former in the process, which has been what we've been doing for the last
> > decade or so.
> 
> That point is debatable :-) I've repeatedly asked during review of DT
> bindings for new properties to be made required, based on the above
> rationale. This is the first time I see a push back.
> 
> I believe we need to address both of the above problems. In the very
> short term, we have to pick which of the two we care about most, as we
> can't have both yet. I have made my personal preference clear, but I'll
> apply the official decision in further reviews. Maybe Rob could share
> his point of view ?

The bindings are there to make sure the device trees are OK, and the
bindings shall do their best to make sure the device trees are as
correct as possible.

This will break existing device trees when we realise something is
not correct in bindings files.

In such a case the ideal workflow would be to:
1) Fix the device tree files so they match the new and more correct
bindings
2) Update the bindings with the latest fixes

As we have different trees for device trees and for bindings this is a
bit difficult at the moment. But the above would be the ideal ways of
working IMO.

Compare this to updating a header file in the kernel that results in new
warnings/errors. The ways of working here is to fix the warnings/errors
before adding the change to the header file. (For example when adding a
must-check attribute).

My take - but then I seldom checks the device tree files as keeping the
bindings free of errors was the challenge in the past. Rob does a
fantastic jobs to keep the kernel error free here and I assume focus may
change to device trees soon.

	Sam