Re: [PATCH v3 1/3] dt-bindings: clock: rockchip: Add RK3572 CRU

["Heiko Stübner" <heiko@sntech.de>]

Am Dienstag, 27. Oktober 2026, 12:07:12 Mitteleuropäische Normalzeit schrieb Krzysztof Kozlowski:
> On 27/10/2026 11:43, Heiko Stübner wrote:
> > Am Dienstag, 27. Oktober 2026, 11:17:08 Mitteleuropäische Normalzeit schrieb Krzysztof Kozlowski:
> > 
> > With code originating in the vendor kernel, it is nice to know what changed,
> > but I guess there is a tradeoff between brevity and more details.
> 
> Honestly I disagree :). Vendor kernel commits and their messages are
> irrelevant per se. They are only useful as source of knowledge, but what
> was exactly written there does not matter. Quality is dubious, coding
> practices are terrible. We want to extract the knowledge, the important
> details, but not the exact commit. We do not care what changed from
> downstream to upstream, because we know that downstream sucks so much
> that we don't even want to touch it.

Here I partially disagree :-) .

We trained Rockchip somewhat well over the years in that for example
the per-soc clock drivers fit quiet nicely into the upstream framework,
as both sides follow the mainline driver structure I did in 2013
(which is still surprising that that mostly holds).

But you're right for other parts like the whole graphics stack, which
diverted so much from mainline that things can't get transplanted at all.


> > I guess this could be shorted to something less verbose, like
> > 
> > +++++++++++++
> > Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> > [adapted to mainline rockchip clock and reset handling (xin24m input,
> >   don't introduce CLK_NR_CLKS, etc ]
> > Signed-off-by: Cunhao Lu <1579567540@qq.com>
> > +++++++++++++
> 
> Yes, if this brings anything useful. For example removal of CLK_NR_CLKS
> is completely pointless to mention. How does it explain the hardware or
> design choices? How does it explain why this driver was written that or
> other way?
> 
> Just take the authorship of downstream commits and send them as your
> own. Both GPL and DCO allow this and if downstream did not bother to
> upstream that stuff, they do not deserve credits.

So personally I do believe in giving credit where credit is due and
trying to make them better citizens instead of just telling the vendor
"your code sucks" ;-) .


The authorship question is likely not as relevant for the binding, but
for example for the clock driver itself, where Elaine did most of the
work matching the hardware- description to the clock structure, I  really
believe that Elaine should get credit for that.


Heiko