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

[Laurent Pinchart]

Hi Rob,

Could you please share your opinion on this ?

On Tue, Oct 19, 2021 at 09:39:15PM +0200, Sam Ravnborg wrote:
> > > > 
> > > > 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.

-- 
Regards,

Laurent Pinchart