Skip to contentSkip to conversation

sh and mach-shmobile struct sh_clk_ops rename

PATCH In review Magnus Damm 3 participants 6 messages Feb 29, 2012 – Mar 7, 2012 SuperH

lore
Share & tools
lore
#0 lore raw

cover sh and mach-shmobile struct sh_clk_ops rename

sh and mach-shmobile struct sh_clk_ops rename

[PATCH 01/17] sh: introduce sh_clk_ops in parallel with clk_ops [PATCH 02/17] sh: convert cpg code to sh_clk_ops [PATCH 03/17] ARM: mach-shmobile: sh7367 sh_clk_ops rename [PATCH 04/17] ARM: mach-shmobile: sh7377 sh_clk_ops rename [PATCH 05/17] ARM: mach-shmobile: sh7372 sh_clk_ops rename [PATCH 06/17] ARM: mach-shmobile: sh73a0 sh_clk_ops rename [PATCH 07/17] ARM: mach-shmobile: r8a7740 sh_clk_ops rename [PATCH 08/17] ARM: mach-shmobile: r8a7779 sh_clk_ops rename [PATCH 09/17] sh: sh header sh_clk_ops rename
[PATCH 10/17] sh: sh2 sh_clk_ops rename
[PATCH 11/17] sh: sh2a sh_clk_ops rename
[PATCH 12/17] sh: sh3 sh_clk_ops rename
[PATCH 13/17] sh: sh4 sh_clk_ops rename
[PATCH 14/17] sh: sh4a sh_clk_ops rename
[PATCH 15/17] sh: sh5 sh_clk_ops rename
[PATCH 16/17] sh: board sh_clk_ops rename
[PATCH 17/17] sh: remove clk_ops

This patch series renames struct clk_ops to struct sh_clk_ops across arch/sh, arch/arm/mach-shmobile and drivers/sh. The reason for this is to avoid name space collision with the common struct clk patches.

Merge order wise across the different trees, [PATCH 01/17] needs to be first and [PATCH 17/17] last. In between any order is ok.

All SoCs with ARM, sh2, sh3, sh4 and sh4a are known to compile. sh2a and sh5 are not compiled but survive basic grep testing.

---

 arch/arm/mach-shmobile/clock-r8a7740.c |    6 +++---
 arch/arm/mach-shmobile/clock-r8a7779.c |    2 +-
 arch/arm/mach-shmobile/clock-sh7367.c  |    6 +++---
 arch/arm/mach-shmobile/clock-sh7372.c  |    8 ++++----
 arch/arm/mach-shmobile/clock-sh7377.c  |    6 +++---
 arch/arm/mach-shmobile/clock-sh73a0.c  |   12 ++++++------
 arch/sh/boards/mach-highlander/setup.c |    2 +-
 arch/sh/boards/mach-sdk7786/setup.c    |    2 +-
 arch/sh/include/asm/clock.h            |    2 +-
 arch/sh/kernel/cpu/sh2/clock-sh7619.c  |   12 ++++++------
 arch/sh/kernel/cpu/sh2a/clock-sh7201.c |   12 ++++++------
 arch/sh/kernel/cpu/sh2a/clock-sh7203.c |   12 ++++++------
 arch/sh/kernel/cpu/sh2a/clock-sh7206.c |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh3.c     |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh7705.c  |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh7706.c  |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh7709.c  |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh7710.c  |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh7712.c  |   10 +++++-----
 arch/sh/kernel/cpu/sh4/clock-sh4-202.c |    6 +++---
 arch/sh/kernel/cpu/sh4/clock-sh4.c     |   12 ++++++------
 arch/sh/kernel/cpu/sh4a/clock-sh7343.c |    4 ++--
 arch/sh/kernel/cpu/sh4a/clock-sh7366.c |    4 ++--
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c |    4 ++--
 arch/sh/kernel/cpu/sh4a/clock-sh7723.c |    4 ++--
 arch/sh/kernel/cpu/sh4a/clock-sh7724.c |    6 +++---
 arch/sh/kernel/cpu/sh4a/clock-sh7757.c |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7763.c |   14 +++++++-------
 arch/sh/kernel/cpu/sh4a/clock-sh7770.c |   12 ++++++------
 arch/sh/kernel/cpu/sh4a/clock-sh7780.c |   14 +++++++-------
 arch/sh/kernel/cpu/sh4a/clock-sh7785.c |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7786.c |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-shx3.c   |    2 +-
 arch/sh/kernel/cpu/sh5/clock-sh5.c     |   12 ++++++------
 drivers/sh/clk/cpg.c                   |   16 ++++++++--------
 include/linux/sh_clk.h                 |    7 ++++---
 36 files changed, 144 insertions(+), 143 deletions(-)
#1 lore raw

Hi,

Quoted 24 lines · Magnus Damm

sh and mach-shmobile struct sh_clk_ops rename

[PATCH 01/17] sh: introduce sh_clk_ops in parallel with clk_ops [PATCH 02/17] sh: convert cpg code to sh_clk_ops [PATCH 03/17] ARM: mach-shmobile: sh7367 sh_clk_ops rename [PATCH 04/17] ARM: mach-shmobile: sh7377 sh_clk_ops rename [PATCH 05/17] ARM: mach-shmobile: sh7372 sh_clk_ops rename [PATCH 06/17] ARM: mach-shmobile: sh73a0 sh_clk_ops rename [PATCH 07/17] ARM: mach-shmobile: r8a7740 sh_clk_ops rename [PATCH 08/17] ARM: mach-shmobile: r8a7779 sh_clk_ops rename [PATCH 09/17] sh: sh header sh_clk_ops rename
[PATCH 10/17] sh: sh2 sh_clk_ops rename
[PATCH 11/17] sh: sh2a sh_clk_ops rename
[PATCH 12/17] sh: sh3 sh_clk_ops rename
[PATCH 13/17] sh: sh4 sh_clk_ops rename
[PATCH 14/17] sh: sh4a sh_clk_ops rename
[PATCH 15/17] sh: sh5 sh_clk_ops rename
[PATCH 16/17] sh: board sh_clk_ops rename
[PATCH 17/17] sh: remove clk_ops

This patch series renames struct clk_ops to struct sh_clk_ops across arch/sh, arch/arm/mach-shmobile and drivers/sh. The reason for this is to avoid name space collision with the common struct clk patches.

Quoted 7 lines

Merge order wise across the different trees, [PATCH 01/17] needs to be first and [PATCH 17/17] last. In between any order is ok.

All SoCs with ARM, sh2, sh3, sh4 and sh4a are known to compile. sh2a and sh5 are not compiled but survive basic grep testing.

Well, this is a hard one, because it has a potential to create many dependencies and I think some other patchsets already posted depend on it right?

I'd handle that by creating a separate branch, based on the Linus' current, that will contain all of the patches in the $subject series and may be merged into other branches by me or Paul as needed.

What do you think?

Rafael

Quoted 45 lines

---

 arch/arm/mach-shmobile/clock-r8a7740.c |    6 +++---
 arch/arm/mach-shmobile/clock-r8a7779.c |    2 +-
 arch/arm/mach-shmobile/clock-sh7367.c  |    6 +++---
 arch/arm/mach-shmobile/clock-sh7372.c  |    8 ++++----
 arch/arm/mach-shmobile/clock-sh7377.c  |    6 +++---
 arch/arm/mach-shmobile/clock-sh73a0.c  |   12 ++++++------
 arch/sh/boards/mach-highlander/setup.c |    2 +-
 arch/sh/boards/mach-sdk7786/setup.c    |    2 +-
 arch/sh/include/asm/clock.h            |    2 +-
 arch/sh/kernel/cpu/sh2/clock-sh7619.c  |   12 ++++++------
 arch/sh/kernel/cpu/sh2a/clock-sh7201.c |   12 ++++++------
 arch/sh/kernel/cpu/sh2a/clock-sh7203.c |   12 ++++++------
 arch/sh/kernel/cpu/sh2a/clock-sh7206.c |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh3.c     |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh7705.c  |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh7706.c  |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh7709.c  |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh7710.c  |   12 ++++++------
 arch/sh/kernel/cpu/sh3/clock-sh7712.c  |   10 +++++-----
 arch/sh/kernel/cpu/sh4/clock-sh4-202.c |    6 +++---
 arch/sh/kernel/cpu/sh4/clock-sh4.c     |   12 ++++++------
 arch/sh/kernel/cpu/sh4a/clock-sh7343.c |    4 ++--
 arch/sh/kernel/cpu/sh4a/clock-sh7366.c |    4 ++--
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c |    4 ++--
 arch/sh/kernel/cpu/sh4a/clock-sh7723.c |    4 ++--
 arch/sh/kernel/cpu/sh4a/clock-sh7724.c |    6 +++---
 arch/sh/kernel/cpu/sh4a/clock-sh7757.c |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7763.c |   14 +++++++-------
 arch/sh/kernel/cpu/sh4a/clock-sh7770.c |   12 ++++++------
 arch/sh/kernel/cpu/sh4a/clock-sh7780.c |   14 +++++++-------
 arch/sh/kernel/cpu/sh4a/clock-sh7785.c |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7786.c |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-shx3.c   |    2 +-
 arch/sh/kernel/cpu/sh5/clock-sh5.c     |   12 ++++++------
 drivers/sh/clk/cpg.c                   |   16 ++++++++--------
 include/linux/sh_clk.h                 |    7 ++++---
 36 files changed, 144 insertions(+), 143 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
In reply to Magnus Damm
Quoted 7 lines · Rafael J. Wysocki
Quoted 1 line · Magnus Damm

sh and mach-shmobile struct sh_clk_ops rename

Well, this is a hard one, because it has a potential to create many dependencies and I think some other patchsets already posted depend on it right?

Quoted 6 lines

I'd handle that by creating a separate branch, based on the Linus' current, that will contain all of the patches in the $subject series and may be merged into other branches by me or Paul as needed.

What do you think?

There are a few ways to do this I suppose. A common topic branch that we can pull in to either the SH or ARM side makes sense. We can do the entire series in one topic branch that gets merged twice and we just make sure that no rebasing takes place, or we can do patches 1-2 on a common branch, then 3-8 on an rmobile branch based on the common on, 9-16 on an sh one, and then leave 17 for the end of the merge window.

Ultimately it depends on how much more work there is going to be done built on top of this. The sh changes are minimal, so I'm not too worried about merge conflicts even if we just keep all of these batched together.

#3 lore raw
In reply to Magnus Damm
Quoted 21 lines · Paul Mundt
Quoted 7 lines · Rafael J. Wysocki
Quoted 1 line · Magnus Damm

sh and mach-shmobile struct sh_clk_ops rename

Well, this is a hard one, because it has a potential to create many dependencies and I think some other patchsets already posted depend on it right?

Quoted 6 lines

I'd handle that by creating a separate branch, based on the Linus' current, that will contain all of the patches in the $subject series and may be merged into other branches by me or Paul as needed.

What do you think?

There are a few ways to do this I suppose. A common topic branch that we can pull in to either the SH or ARM side makes sense. We can do the entire series in one topic branch that gets merged twice and we just make sure that no rebasing takes place, or we can do patches 1-2 on a common branch, then 3-8 on an rmobile branch based on the common on, 9-16 on an sh one, and then leave 17 for the end of the merge window.

Quoted 3 lines

Ultimately it depends on how much more work there is going to be done built on top of this. The sh changes are minimal, so I'm not too worried about merge conflicts even if we just keep all of these batched together.

OK, so would you mind if I created a clk_ops-rename branch in the renesas tree at git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git
and put the whole $subject series into it?

Rafael

#4 lore raw
In reply to Magnus Damm
Quoted 8 lines · Rafael J. Wysocki
Quoted 7 lines · Paul Mundt

There are a few ways to do this I suppose. A common topic branch that we can pull in to either the SH or ARM side makes sense. We can do the entire series in one topic branch that gets merged twice and we just make sure that no rebasing takes place, or we can do patches 1-2 on a common branch, then 3-8 on an rmobile branch based on the common on, 9-16 on an sh one, and then leave 17 for the end of the merge window.

Quoted 8 lines
Quoted 3 lines

Ultimately it depends on how much more work there is going to be done built on top of this. The sh changes are minimal, so I'm not too worried about merge conflicts even if we just keep all of these batched together.

OK, so would you mind if I created a clk_ops-rename branch in the renesas tree at git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git
and put the whole $subject series into it?

Sounds fine to me.

#5 lore raw
In reply to Magnus Damm
Quoted 13 lines · Paul Mundt
Quoted 12 lines · Rafael J. Wysocki
Quoted 10 lines · Paul Mundt

There are a few ways to do this I suppose. A common topic branch that we can pull in to either the SH or ARM side makes sense. We can do the entire series in one topic branch that gets merged twice and we just make sure that no rebasing takes place, or we can do patches 1-2 on a common branch, then 3-8 on an rmobile branch based on the common on, 9-16 on an sh one, and then leave 17 for the end of the merge window.

Ultimately it depends on how much more work there is going to be done built on top of this. The sh changes are minimal, so I'm not too worried about merge conflicts even if we just keep all of these batched together.

Quoted 5 lines
Quoted 4 lines

OK, so would you mind if I created a clk_ops-rename branch in the renesas tree at git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git
and put the whole $subject series into it?

Sounds fine to me.

Done.

Thanks,
Rafael