| Message ID | 20160902014012.9383-1-chris.brandt@renesas.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 969244f9c72057b2c32b650b2d75a04d612c603c |
| Delegated to: | Simon Horman |
| Headers | show |
Thanks Chris, I have queued up this and the following 2 patches for v4.9 (nothing more for you to do unless something goes wrong in which case I'll let you know). For future submissions please consider: 1. Supplying a cover letter (git format-patch has a --cover-letter option) for patch-sets comprising more than one patch. This allows you to describe an overview of what the series as a whole achieves. And is also convenient for maintainers to reply to when accepting your patches. 2. Starting a new thread for each new version of a patch/patch-set. Different maintainers have different preferences. The above are mine.
On 9/2/2016, Simon Horman wrote: > For future submissions please consider: > 1. Supplying a cover letter (git format-patch has a --cover-letter option) > for patch-sets comprising more than one patch. This allows you to describe > an overview of what the series as a whole achieves. And is also > convenient for maintainers to reply to when accepting your patches. OK. I can do that. > 2. Starting a new thread for each new version of a patch/patch-set. Does that mean to NOT use --in-reply-to= when submitting a v2,v3,etc... ???? One more question: Can I submit a patches series now that just adds all the MSTP clock nodes that I'll be working on for the next couple weeks? (USB, SDHI, MMC) Or, do I have to wait till I have the drivers working? Or, better yet, can I add all the MSTP clocks that will probably get used at some point (basically, everything that we're using today in our 3.14 BSP). Chris
On Fri, Sep 02, 2016 at 12:50:39PM +0000, Chris Brandt wrote: > On 9/2/2016, Simon Horman wrote: > > For future submissions please consider: > > 1. Supplying a cover letter (git format-patch has a --cover-letter option) > > for patch-sets comprising more than one patch. This allows you to describe > > an overview of what the series as a whole achieves. And is also > > convenient for maintainers to reply to when accepting your patches. > > OK. I can do that. > > > > 2. Starting a new thread for each new version of a patch/patch-set. > > Does that mean to NOT use --in-reply-to= when submitting a v2,v3,etc... ???? I think so. > One more question: > Can I submit a patches series now that just adds all the MSTP clock nodes that I'll be working on for the next couple weeks? (USB, SDHI, MMC) > Or, do I have to wait till I have the drivers working? > Or, better yet, can I add all the MSTP clocks that will probably get used at some point (basically, everything that we're using today in our 3.14 BSP). I think that would be ok. I would slightly prefer that MSTP patches are added in such a way that they can be tested. But in this case I'm not sure anyone would test them :^)
diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi index e8e2a5d7..6d29e8f 100644 --- a/arch/arm/boot/dts/r7s72100.dtsi +++ b/arch/arm/boot/dts/r7s72100.dtsi @@ -108,6 +108,15 @@ clock-output-names = "scif0", "scif1", "scif2", "scif3", "scif4", "scif5", "scif6", "scif7"; }; + mstp7_clks: mstp7_clks@fcfe0430 { + #clock-cells = <1>; + compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks"; + reg = <0xfcfe0430 4>; + clocks = <&p0_clk>; + clock-indices = <R7S72100_CLK_ETHER>; + clock-output-names = "ether"; + }; + mstp9_clks: mstp9_clks@fcfe0438 { #clock-cells = <1>; compatible = "renesas,r7s72100-mstp-clocks", "renesas,cpg-mstp-clocks"; diff --git a/include/dt-bindings/clock/r7s72100-clock.h b/include/dt-bindings/clock/r7s72100-clock.h index 5128f4d..3cd8138 100644 --- a/include/dt-bindings/clock/r7s72100-clock.h +++ b/include/dt-bindings/clock/r7s72100-clock.h @@ -25,6 +25,9 @@ #define R7S72100_CLK_SCIF6 1 #define R7S72100_CLK_SCIF7 0 +/* MSTP7 */ +#define R7S72100_CLK_ETHER 4 + /* MSTP9 */ #define R7S72100_CLK_I2C0 7 #define R7S72100_CLK_I2C1 6