Re: [PATCH v2 2/3] clk: qcom: dispcc-eliza: Add Eliza display clock controller support

[Dmitry Baryshkov]

On Wed, Mar 18, 2026 at 03:33:56PM +0100, Krzysztof Kozlowski wrote:
> On 18/03/2026 14:46, Dmitry Baryshkov wrote:
> > On Wed, Mar 18, 2026 at 12:36:24PM +0100, Krzysztof Kozlowski wrote:
> >> On 18/03/2026 12:32, Konrad Dybcio wrote:
> >>> On 3/18/26 12:13 PM, Krzysztof Kozlowski wrote:
> >>>> On 18/03/2026 11:48, Konrad Dybcio wrote:
> >>>>> On 3/18/26 11:39 AM, Krzysztof Kozlowski wrote:
> >>>>>> Add a driver for the display clock controller on Qualcomm Eliza SoC,
> >>>>>> which is copied from SM8750 driver plus changes:
> >>>>>>
> >>>>>> 1. Additional DT_HDMI_PHY_PLL_CLK clock input,
> >>>>>> 2. Eight new HDMI clocks,
> >>>>>> 3. Different PLLs (lucid and pongo).
> >>>>>>
> >>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxxxxx>
> >>>>>> ---
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>
> >>>>>> +// SPDX-License-Identifier: GPL-2.0-only
> >>>>>> +/*
> >>>>>> + * Copyright (c) 2021, The Linux Foundation. All rights reserved.
> >>>>>> + * Copyright (c) 2023-2024, Linaro Ltd.
> >>>>>> + * Copyright (c) 2024-2025, Qualcomm Innovation Center, Inc. All rights reserved.
> >>>>>
> >>>>> -> Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> >>>>
> >>>> That's the copyright I found in the downstream code I used in few places
> >>>> here (with modifications) and I am not touching them. I also don't care
> >>>> about these and I am surprised this keeps popping in community review...
> >>>
> >>> You may not care, but our legal department does..
> >>
> >> And your task as community maintainer is to care about community and
> >> Linux kernel, not about legal department.
> >>
> >> Legal department can comment here, if they care. You as maintainer have
> >> rather responsibilities regardless of that legal department.
> >>
> >> Don't bring corpo legal stuff to the community.
> > 
> > Then please follow the internal company guidelines as outlined in the
> > legal&marketing documents.
> 
> That's not your task to instruct people what internal stuff should they
> follow or not.

Well... For me it's not different from your comments telling other
submitters to follow "internal guidelines" when submitting patches. Or
not to follow them.

I don't want to argue about the corporate guidelines. If you think they
are incorrect, please change them.

> 
> Especially not implied by previous comment "Then".
> 
> > 
> > JFYI, several other Qualcomm maintainers also enforce use of copyright
> > headers for Qualcomm-provided patches. Konrad is not unique here.
> 
> I already objected to one of them, so I know.
> 
> You do understand that this is completely broken review process? As
> every contributor, I can object to that comment with arguments (and I
> did in the past), however you as reviewer do not bring any
> counter-arguments for that all. You just refer "follow legal internal
> stuff". No, this does not work for that.
> 
> If you bring review comment you must be able to justify it, when it is
> being discussed. You cannot refer "but legal team said".

If you want to put it that way, sure. As a Qualcomm employee you have a
set of internal rules you have to adhere to. One of them is this
copyright string. I'd rather not have legal department pre-review all
our contributions. Been there (in another company), thanks, but no.

In my opinion, the maintainers and reviewers should ensure correctness
of the patch. Correct legal header is one of those. Consider someone
submitting patches which has copyright strings such as "(c) qwalkomm" or
"(c) lunix foundacion". They would be questioned for correctness.
Likewise when somebody from Qualcomm submits a patch with "(c) QuIC",
they were asked to change it to the current form. It doesn't concern
non-Qualcomm employees, because they cannot change the copyright of the
material.

> 
> Otherwise look for comments for your contributions where you are going
> to receive review "please remove all boilerplate because my legal team
> told me that and I am not going to provide actual arguments why".

In this case there is one. "Because I assume that you have a requirement
to do so from your company". If I were reviewing patches for e.g.
Mediatek driver, if I knew the guideline for the patches and if I saw
any of the guidelines to be breached, I'd have reacted in exactly the
same way.

-- 
With best wishes
Dmitry