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
