Hi Krzysztof, > Am 09.04.2022 um 13:07 schrieb Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>: > > On 08/04/2022 20:37, H. Nikolaus Schaller wrote: >> arch/mips/boot/dts/ingenic/ci20.dtb: cpu@0: clock-names does not match any of the regexes: pinctrl-[0-9]+ >> From schema: Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml >> arch/mips/boot/dts/ingenic/ci20.dtb: cpu@1: clock-names does not match any of the regexes: pinctrl-[0-9]+ >> From schema: Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml > > No need to put the same warning twice (cpu index really does not > matter). One warning is enough. Well, how can you as a reviewer see immediately that dtbscheck warns for both instances and that they are both really fixed by the complete patch? Assume there were only the first one mentioned and the second one forgotten to fix... If it is not included here (completely), you have to run dtbscheck yourself to see that there are two instances involved. Or deduce it from looking into the source file. In both cases much more work for you or other reviewers. This is why I have kept this redundancy. One commit hunk for every warning line. And it may only look redundant in the commit message, not in code where it would really hurt to have duplication. > > Fixing warnings is good, but what if the property should be there and > the bindings are not correct? If you know the answer, please add it to > the commit msg. It has of course been tested on real hardware. There was only one case where the bindings seem to be wrong (patch 13/18). And usually I simply assume such generic bindings are tested on many other platforms and therefore the reference. What are bindings and dtbscheck good for if we doubt them as DTS developers? > This applies to all your patches. Blind fixing of DTS warnings my > produce incorrect results. :( Every patch of this series has been tested on real hardware to have no negative side-effects. > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> > > > Best regards, > Krzysztof BR and thanks, Nikolaus
