> Ok, what is your suggestion on dt-schema check failure in that case as I > mentioned above? Shall we remove examples from yaml that we added? As Krzysztof keeps saying, Commit message. You have an unlimited amount of space to document why this SoC is special, how it is special, maybe include some ASCII art showing how it is special. Justify it being special. Once it is clear it is special, has dependencies which are real, we are likely to accept the patches. We know SoC vendors do weird things, and sometimes mainline processes just don't work. But you need to clear, upfront, and state, the process does not work because... in your commit message. Maybe put it below the ---. Something i often say to Mainline newbies. The code is easy, it is the processes which are hard. The commit message is part of the process. You want to try to anticipate all the questions Reviewers are going to ask and answer them in the commit message, before they ask them. It is process that you split patches by subsystem. It is process that binding changes and driver changes go together in the patchset. Your 'code review' should include all this, not just the lines of actual code. And to begin with, process is probably a lot more important than the actual code. So please concentrate on processes, get them right. Andrew
