lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200603180943.GX11847@yoga>
Date:   Wed, 3 Jun 2020 11:09:43 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
Cc:     Jonathan Marek <jonathan@...ek.ca>, linux-arm-msm@...r.kernel.org,
        Andy Gross <agross@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-arm-msm-owner@...r.kernel.org
Subject: Re: [PATCH 08/10] clk: qcom: Add graphics clock controller driver
 for SM8250

On Thu 28 May 23:56 PDT 2020, Sai Prakash Ranjan wrote:

> Hi Bjorn,
> 
> On 2020-05-29 06:41, Bjorn Andersson wrote:
> > On Mon 25 May 02:47 PDT 2020, Sai Prakash Ranjan wrote:
> > 
> > > Hi Jonathan,
> > > 
> > > On 2020-05-25 02:36, Jonathan Marek wrote:
> > > > Add support for the graphics clock controller found on SM8250
> > > > based devices. This would allow graphics drivers to probe and
> > > > control their clocks.
> > > >
> > > > This is copied from the downstream kernel, adapted for upstream.
> > > > For example, GDSCs have been added.
> > > >
> > > > Signed-off-by: Jonathan Marek <jonathan@...ek.ca>
> > > 
> > > Since this is taken from downstream, maintain the original author's
> > > signed-off and add yourself as the co-developer if you have done
> > > any modifications. Same applies to all other patches.
> > > 
> > 
> > I disagree with this.
> > 
> > As expressed in the commit message, this patch is based on the
> > downstream driver, not the individual patch.  As such, the _patch_ is
> > prepared by Jonathan and by his Signed-off-by certifies the origin of
> > the contribution per section 11.a or 11.b of submitting-patches.rst.
> > 
> 
> I lost at the downstream driver vs the individual patch here. So the
> downstream driver is also an individual patch right or did I get
> something completely wrong.
> 

The downstream driver is the result of a series of patches, by various
people, whom all use their Signed-off-by to denote that what they add is
conforming to the given license and that they have permission to
contribute to the project.

> So if someone prepares a patch and includes a commit description
> saying it is taken from downstream, does it mean he is the author
> of that patch?

No, but I think the wording here is wrong. The patch is not taken from
downstream, it's based on downstream code.

> Shouldn't the author be included in  "From: Author"
> and his signed-off appear first before the submitter's(also a contributor)
> signed-off?

It should, in the case that what is contributed is the forwarding of a
patch found somewhere.

But as I said before, Jonathan does through his S-o-b state that his
patch is based on previous work that is covered under appropriate open
source license and that he has the right under that license to
contribute said work.

As such, his patch is meeting the requirements.


The other part is how to give credit to authors of the original work,
Jonathan does that by stating that it's based on work in the downstream
kernel - which is quite typical to how it's done.

> Or is it because these clock data is auto generated and it
> doesnt really matter?
> 

No. The author and s-o-b relates to license compliance, as such the
person who committed the auto generated work will sign off that the
content is license compliant and he/she is allowed to contribute it to
the project.

Regards,
Bjorn

> > 
> > Regarding co-developed-by; this should not be used when "forwarding" an
> > existing patch. Per section 11.c the contributor should add their
> > Signed-off-by to certify the origin of the patch. Any modifications
> > should be documented in immediately proceeding the s-o-b, as described
> > later in section 11.
> > 
> 
> Yes makes sense to not have co-developed-by for forwarding patch.
> 
> Thanks,
> Sai
> 
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ