mbox series

[0/3] Enable hwlock on Allwinner A64

Message ID 20230213231931.6546-1-bage@debian.org
Headers show
Series Enable hwlock on Allwinner A64 | expand

Message

Bastian Germann Feb. 13, 2023, 11:19 p.m. UTC
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.

Bastian Germann (3):
  dt-bindings: hwlock: sun6i: Add missing #hwlock-cells
  dt-bindings: hwlock: sun6i: Add missing names
  arm64: dts: allwinner: a64: Add hwspinlock node

 .../hwlock/allwinner,sun6i-a31-hwspinlock.yaml     | 14 ++++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      | 10 ++++++++++
 2 files changed, 24 insertions(+)

Comments

Andre Przywara Feb. 15, 2023, 10:31 p.m. UTC | #1
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/
Krzysztof Kozlowski Feb. 16, 2023, 8:15 a.m. UTC | #2
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