Message ID | 20230213231931.6546-1-bage@debian.org |
---|---|
Headers | show |
Series | Enable hwlock on Allwinner A64 | expand |
On Tue, 14 Feb 2023 12:57:06 -0800 Bjorn Andersson <andersson@kernel.org> wrote: Hi Bjorn, > On Tue, 14 Feb 2023 00:19:27 +0100, Bastian Germann wrote: > > The allwinner,sun6i-a31-hwspinlock compatible driver can be used with > > the Allwinner A64 chip. Add the wiring required to enable it. > > > > The device tree schema needs some work to verify everything that is > > needed by the sun6i hwlock driver. > > > > The hwlock device was verified to be available with this series applied > > on a Pinebook. > > > > [...] > > Applied, thanks! > > [1/3] dt-bindings: hwlock: sun6i: Add missing #hwlock-cells > commit: 25d10262ed8aae71cd2f0b3c0a90d06a6b79fba2 as you might have seen, this was a bit premature, as the example is missing the newly required property, as pointed out by Rob[1]. Did you send a pull request including this patch already? Can you drop this patch still from your tree? The fix is rather trivial, but the patch is also not critical, since there is no DT user in the tree, and the remaining series won't make it into v6.3 anyway. Cheers, Andre [1] https://lore.kernel.org/linux-remoteproc/167638944701.3666.5425414440419322569.robh@kernel.org/
On 14/02/2023 19:11, Andre Przywara wrote: > On Tue, 14 Feb 2023 13:37:20 +0100 > Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > Hi Krzysztof, > >> On 14/02/2023 10:45, Wilken Gottwalt wrote: >>> On Tue, 14 Feb 2023 00:19:29 +0100 >>> Bastian Germann <bage@debian.org> 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