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-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
