Messages in this thread | | | Subject | Re: [PATCH 03/18] MIPS: DTS: jz4780: fix tcu timer as reported by dtbscheck | From | "H. Nikolaus Schaller" <> | Date | Sat, 9 Apr 2022 15:30:06 +0200 |
| |
> Am 09.04.2022 um 15:22 schrieb Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>: > > On 09/04/2022 15:18, H. Nikolaus Schaller wrote: >> >> Well, again, my assumption is that bindings and .yaml files formally describe the actual >> hardware components. And they have been reviewed. > > The bindings try to describe it. They are pretty often incomplete or > might have mistakes.
Indeed they have. But what If I have found that they are right. Why should I comment on that? It should at least be the default assumption.
> The true reason of doing a change is not that some > tool tells you "do like this". The true reason is because the change > properly describes hardware. > >> >> So they have a higher level of authority than any current driver or .dts implementation. >> Unless there is evidence that the bindings are wrong. > > This is just a tool, not an authority. > >> I.e. if the bindings feel right why is there a need to argue for that? > > Because doing things "just because bindings told me" hides the true > explanation and makes the code review, code management more difficult.
Well, I always wonder why schemas were done that way they were done since their introduction. If I would write down commetns every time nobody would be happy...
> Later person will look at this and wonder why this was done like this. > If you write "because some tool me" this is not a good help. But if you > write "because hardware is like this exactly" this is proper comment. > >> >> It is like test-driven development model. There you have to write code that passes >> the tests. Not argue against the tests. > > Again, don't focus on the tool... Tool is just a tool...
A tool I can't ignore because Rob's robot tells me it is "the truth"...
BR and thanks, Nikolaus
| |