[PATCH v6 1/6] dt-bindings: soc: spacemit: define spacemit,k1-ccu resets
Krzysztof Kozlowski
krzk at kernel.org
Thu May 8 05:36:57 PDT 2025
On 08/05/2025 14:17, Alex Elder wrote:
> On 5/8/25 7:02 AM, Krzysztof Kozlowski wrote:
>> On 08/05/2025 00:35, Yixun Lan wrote:
>>>> + - if:
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + enum:
>>>> + - spacemit,k1-syscon-apbc
>>>> + - spacemit,k1-syscon-apmu
>>>> + - spacemit,k1-syscon-mpmu
>>>> + then:
>>>> + required:
>>>> + - clocks
>>>> + - clock-names
>>>> + - "#clock-cells"
>>>>
>>>> additionalProperties: false
>>>>
>>>> diff --git a/include/dt-bindings/clock/spacemit,k1-syscon.h b/include/dt-bindings/clock/spacemit,k1-syscon.h
>>>> index 35968ae982466..f5965dda3b905 100644
>>>> --- a/include/dt-bindings/clock/spacemit,k1-syscon.h
>>>> +++ b/include/dt-bindings/clock/spacemit,k1-syscon.h
>>> would it be better to move all reset definition to its dedicated dir?
>>> which like: include/dt-bindings/reset/spacemit,k1-syscon.h?
>>
>> Please kindly trim the replies from unnecessary context. It makes it
>> much easier to find new content.
>>
>>
>> I don't get why such comments are appearing so late - at v6. There was
>> nothing from you about this in v1, v2 and v3, which finally got reviewed.
>
> Stephen Boyd said "please rework this to use the auxiliary driver
> framework" on version 5 of the series; it was otherwise "done" at
> that point.
Stephen is a subsystem maintainer so his comments are fine or acceptable
to be late.
>
> Doing this meant there was a much clearer separation of the clock
> definitions from the reset definitions. And Yixun's suggestion
> came from viewing things in that context.
Weren't they applicable to v1 as well? How bindings could change with
change to auxiliary bus/driver?
>
> Given the rework, I considered sending this as v1 of a new series
> but did not.
Sorry but no. Bindings headers at v1 are exactly the same or almost the
same as now:
https://lore.kernel.org/lkml/20250321151831.623575-2-elder@riscstar.com/
so this idea could have been given at v1, v2, v3, v4, v5 (that would be
late).... but at some point this is just unnecessary late nitpicking.
So what then? Imagine that you prepare v7 and some other person gives
you different comment about bindings or bindings headers. Then you
prepare v8. And then someone comes with one more, different comment,
because that person did not bother to review between v1-v8 (that
imaginary future v8), so you need to prepare v9.
I don't think this process is correct.
Best regards,
Krzysztof
More information about the linux-riscv
mailing list