On 14/02/2023 19:11, Andre Przywara wrote: > On Tue, 14 Feb 2023 13:37:20 +0100 > Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > Hi Krzysztof, > >> On 14/02/2023 10:45, Wilken Gottwalt wrote: >>> On Tue, 14 Feb 2023 00:19:29 +0100 >>> Bastian Germann <bage@xxxxxxxxxx> wrote: >>> >>>> The allwinner,sun6i-a31-hwspinlock.yaml binding needs clock-names >>>> and reset-names set to "ahb" as required by the driver. >>> >>> Hmm, this one is a bit odd. If you look into my earlier versions of the >>> patchset, you may notice, that I actually included these bindings and they >>> were refused. I think the argumentation was like >>> "there is only one bus = no need for it". >>> >>> If it gets accepted now, I really like to know why. (It was some trouble >>> back then to get the documentation properly done and accepted.) >> >> The clock names and resent names are not correct. They should have never >> been added. If you got comments about this and did not update driver, >> that's not nice. You just shoved incomplete bindings. :( >> >> So indeed to avoid precedence - people pushing fake bindings and >> avoiding review - NAK on this. > > Maybe it's just me, but I don't think this tone is necessary. > > Wilken's original submission was correct. Later there was a comment just > on the binding patch, to remove the not needed clock-names and reset-names > properties. But there was not a word in there that the driver requires > changing as well, and I don't think it's fair to blame Wilken on this, or > somewhat even implying intention. There were several patch revisions after > this was raised, and this just slipped through review. But surely no one > wanted this or pushed for that. I would say it is quite obvious. Otherwise you could remove entire binding and still submit the driver, right? Isn't the entire point of the binding to match what the driver is doing, as it is the description of interface used by driver towards DTS? > > If anything, it tells us that we should be more careful when merging > drivers without users: if there would have been a DT patch, possibly even > a consumer, this would have been flagged by dtbs_check. Sure. To me it tells - this patch is a no-go and driver should be fixed. Best regards, Krzysztof
