Re: [PATCH 04/13] clk: amlogic: Add basic clock driver

[Krzysztof Kozlowski]

On 15/04/2026 13:40, Chuan Liu wrote:
> Hi Krzysztof,
> 
> 
> On 4/9/2026 2:12 PM, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On 08/04/2026 16:32, Chuan Liu wrote:
>>> Hi Krzysztof (& ALL),
>>> Thanks for review.
>>>
>>> On 2/9/2026 9:17 PM, Krzysztof Kozlowski wrote:
>>>> [ EXTERNAL EMAIL ]
>>>>
>>>> On 09/02/2026 06:48, Chuan Liu via B4 Relay wrote:
>>>>> From: Chuan Liu <chuan.liu@xxxxxxxxxxx>
>>>>>
>>>>> Implement core clock driver for Amlogic SoC platforms, supporting
>>>>
>>>> So how did all existing Amlogic SoC platforms work so far without basic
>>>> clock driver? Really, how?
>>>>
>>>> You are suppose to grow existing code, not add your completely new
>>>> "basic" driver just because you have it that way in downstream.
>>>>
>>>
>>> Firstly, apologies for the delayed response. I had intended to
>>> consolidate the V1 review feedback and come back with a clearer plan for
>>> V2 changes. In the meantime, Martin has provided many detailed and
>>> valuable suggestions - much appreciated.
>>>
>>> The original goal of optimizing the HW based on A9 and introducing a new
>>> clock driver is to reduce unnecessary complexity in the driver. On A9,
>>
>> Nah, you just don't care about upstream and it is easier for you to
>> duplicate new code.
> 
> Regarding the "duplicate new code": the ops implemented in clk-basic.c 
> are indeed based on the CCF components (clk-mux, clk-divider, clk-gate), 
> with the following enhancements:
>    - Register access via regmap (meson clock driver looks like this)
>    - Additional debug nodes to support Amlogic clock automated test 
> tools (in conjunction with clk-measure to verify hardware functionality 
> of each clock)
>    - Clock context save/restore support for STD/STR


Add all of these to existing drivers and stop pushing your downstream
approach. You received feedback already more than once from more than
one person. No means no. You are waiting one week with a reply and then
again pushing against feedback with ridiculous arguments of "objective
design" or "optimizing".

That pushing after receiving clear "no" means you value downstream or
vendor or corporate rules more than what community wants and that's
short way to get permanently PLONK-ed on all your submissions.

NAK

Best regards,
Krzysztof