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

Hi Rob,

Could you please share your opinion on this ?

On Tue, Oct 19, 2021 at 09:39:15PM +0200, Sam Ravnborg wrote:

quoted

quoted

quoted

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