Date:	Fri, 9 Jan 2015 20:52:31 +0000 (UTC)
From:	Paul Walmsley <paul@...an.com>
To:	Thierry Reding <thierry.reding@...il.com>
cc:	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org,
	Alexandre Courbot <gnurou@...il.com>,
	Prashant Gaikwad <pgaikwad@...dia.com>,
	Mike Turquette <mturquette@...aro.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	Bill Huang <bilhuang@...dia.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Allen Martin <amartin@...dia.com>,
	Paul Walmsley <pwalmsley@...dia.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 4/4] clk: tegra: Add support for the Tegra132 CAR IP
 block

Hi Thierry

On Fri, 9 Jan 2015, Thierry Reding wrote:

> On Tue, Dec 16, 2014 at 12:38:29PM -0800, Paul Walmsley wrote:
> > 
> > This patch is based on several patches from others:
> > 
> > 1. a  patch from Peter De Schrijver:
> > 
> > http://lkml.iu.edu/hypermail/linux/kernel/1407.1/06094.html
> > 
> > 2. a patch from Bill Huang ("clk: tegra: enable cclk_g at boot on
> > Tegra132"), and
> > 
> > 3. a patch from Allen Martin ("clk: Enable tegra clock driver for
> > tegra132").
> 
> Doesn't this technically require Signed-off-bys from each of the above,
> then?

I don't think so.  Documentation/SubmittingPatches states:

---
The rules are pretty simple: if you can certify the below:

        Developer's Certificate of Origin 1.1

        By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

	(d) I understand and agree that this project and the contribution
	    are public and that a record of the contribution (including 
	    all personal information I submit with it, including my sign-off) 
	    is maintained indefinitely and may be redistributed consistent 
	    with this project or the open source license(s) involved.
---

My Signed-off-by: is based on paragraphs (a), (b), and (d).

The intention of my statement is to ensure that credit is appropriately 
provided to everyone who I drew significant inspiration or code from, and 
that such credit makes it into the official commits (e.g., is not dropped 
when the patches are applied.)  However, the patch that I sent is 
differs from the patches that I reviewed while preparing it.

Of course, if anyone would like to add Acked-by or Reviewed-by tags, etc., 
or comment if I've misunderstood something technically etc., that's 
definitely welcome.

> > diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
> [...]
> > +/**
> > + * tegra124_132_clock_init_pre - clock initialization preamble for T124/T132
> > + * @np: struct device_node * of the DT node for the SoC CAR IP block
> > + *
> > + * Register most of the clocks controlled by the CAR IP block, along
> > + * with a few clocks controlled by the PMC IP block.  Everything in
> > + * this function should be common to Tegra124 and Tegra132.  XXX The
> > + * PMC clock initialization should probably be moved to PMC-specific
> > + * driver code.  No return value.
> > + */
> > +static void __init tegra124_132_clock_init_pre(struct device_node *np)
> 
> I would've personally named this tegra124_clock_init_pre(). In the past
> we've named these functions after the first chip that needed them and if
> later chips remained compatible they would simply use the one from an
> earlier chip. That's consistent with the naming of compatible strings
> and doesn't require changes to the function names if yet another SoC
> generation were to need the same functionality.

Yes, I agree it's unwieldy.  It would be nice to find some concise way to 
refer to "the family of NVIDIA SoCs that includes T124 and T132".  Maybe 
tegra124_family_clock_init_pre() might be a better choice...


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists