| Message ID | 20200405025123.154688-7-sboyd@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Allow COMMON_CLK to be selectable | expand |
On Sun, Apr 5, 2020 at 4:51 AM Stephen Boyd <sboyd@kernel.org> wrote: > There's one snag with doing this, and that's making sure that randconfig > builds don't select this option when some architecture or platform > implements 'struct clk' outside of the common clk framework. Introduce a > new config option 'HAVE_LEGACY_CLK' to indicate those platforms that > haven't migrated to the common clk framework and therefore shouldn't be > allowed to select this new config option. Also add a note that we hope > one day to remove this config entirely. Good idea! I've looked through the individual ones and commented a bit on what I think may or may not happen with them. ralink SOC_MT7621 is the only one that I think you got wrong, as it already has common-clk support. > arch/arm/Kconfig | 2 ++ > arch/c6x/Kconfig | 1 + > arch/m68k/Kconfig.cpu | 2 +- > arch/mips/Kconfig | 6 ++++-- > arch/mips/loongson2ef/Kconfig | 2 +- > arch/sh/boards/Kconfig | 5 +++++ > arch/unicore32/Kconfig | 2 +- > drivers/clk/Kconfig | 17 +++++++++++++---- > 8 files changed, 28 insertions(+), 9 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index eeabdc5a3dd2..0606e1bbd7b6 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -364,6 +364,7 @@ config ARCH_EP93XX > select CPU_ARM920T > select GENERIC_CLOCKEVENTS > select GPIOLIB > + select HAVE_LEGACY_CLK > help > This enables support for the Cirrus EP93xx series of CPUs. > > @@ -522,6 +523,7 @@ config ARCH_OMAP1 > select GENERIC_IRQ_MULTI_HANDLER > select GPIOLIB > select HAVE_IDE > + select HAVE_LEGACY_CLK > select IRQ_DOMAIN > select NEED_MACH_IO_H if PCCARD > select NEED_MACH_MEMORY_H Ah nice, I thought there were more than two implementations left. I need to refresh the series for OMAP1 that I did last year and debug the regression that caused. I think Linus Walleij has looked into the ep93xx one at some point. > diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig > index e65e8d82442a..6444ebfd06a6 100644 > --- a/arch/c6x/Kconfig > +++ b/arch/c6x/Kconfig > @@ -11,6 +11,7 @@ config C6X > select ARCH_HAS_SYNC_DMA_FOR_CPU > select ARCH_HAS_SYNC_DMA_FOR_DEVICE > select CLKDEV_LOOKUP > + select HAVE_LEGACY_CLK > select GENERIC_ATOMIC64 > select GENERIC_IRQ_SHOW > select HAVE_ARCH_TRACEHOOK This was last touched in 2012 when TMS320C6678 support was added. It seems to be based on the original same code as omap1 and omap2 that eventually turned into the common clock subsystem, so it would clearly be possible to do a step-by-step conversion like I did for omap1, but I suspect we can wait for all of c6x-linux to become obsolete enough. > diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu > index 60ac1cd8b96f..bd2d29c22a10 100644 > --- a/arch/m68k/Kconfig.cpu > +++ b/arch/m68k/Kconfig.cpu > @@ -28,7 +28,7 @@ config COLDFIRE > select CPU_HAS_NO_MULDIV64 > select GENERIC_CSUM > select GPIOLIB > - select HAVE_CLK > + select HAVE_LEGACY_CLK > > endchoice The coldfire clock implementation looks rather simple compared to chips from the 2010s: most chips have only fixed clocks, and three of them have one of two registers of clock gates. It shouldn't be hard to convert, but enabling common-clk will cause a noticeable kernel size increase on the fairly limited hardware. Simply enabling COMMON_CLK in m5475evb_defconfig results in a 1.7% or 40KB growth in kernel size, plus there would be additional dynamic memory usage: text data bss dec hex filename 1934726 263616 83284 2281626 22d09a obj/vmlinux-before 1971989 266192 83308 2321489 236c51 obj/vmlinux-after > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index e53a8dd5c19b..fa02c715ab25 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -181,7 +181,7 @@ config AR7 > select SYS_SUPPORTS_ZBOOT_UART16550 > select GPIOLIB > select VLYNQ > - select HAVE_CLK > + select HAVE_LEGACY_CLK > help > Support for the Texas Instruments AR7 System-on-a-Chip > family: TNETD7100, 7200 and 7300. I suspect this platform is fairly dead, OpenWRT dropped support for it, and the known machines have at most 16MB of RAM, which limits the number of use cases that also want to build recent kernels. > @@ -296,9 +296,9 @@ config BCM63XX > select SYS_HAS_EARLY_PRINTK > select SWAP_IO_SPACE > select GPIOLIB > - select HAVE_CLK > select MIPS_L1_CACHE_SHIFT_4 > select CLKDEV_LOOKUP > + select HAVE_LEGACY_CLK > help > Support for BCM63XX based boards > > @@ -419,6 +419,7 @@ config LANTIQ > select SWAP_IO_SPACE > select BOOT_RAW > select CLKDEV_LOOKUP > + select HAVE_LEGACY_CLK > select USE_OF > select PINCTRL > select PINCTRL_LANTIQ > @@ -656,6 +657,7 @@ config RALINK > select SYS_SUPPORTS_MIPS16 > select SYS_HAS_EARLY_PRINTK > select CLKDEV_LOOKUP > + select HAVE_LEGACY_CLK > select ARCH_HAS_RESET_CONTROLLER > select RESET_CONTROLLER All three of these are older platforms that still have a number of machines supported in OpenWRT, so there is hope that someone would do the work to add common-clk support. Both Lantiq and Ralink have been converted to device tree not too long ago. I think the RALINK entry needs to be changed, as this includes SOC_MT7621, which already uses COMMON_CLK. > diff --git a/arch/mips/loongson2ef/Kconfig b/arch/mips/loongson2ef/Kconfig > index 595dd48e1e4d..c9ec43afde73 100644 > --- a/arch/mips/loongson2ef/Kconfig > +++ b/arch/mips/loongson2ef/Kconfig > @@ -46,7 +46,7 @@ config LEMOTE_MACH2F > select CSRC_R4K if ! MIPS_EXTERNAL_TIMER > select DMA_NONCOHERENT > select GENERIC_ISA_DMA_SUPPORT_BROKEN > - select HAVE_CLK > + select HAVE_LEGACY_CLK > select FORCE_PCI > select I8259 > select IRQ_MIPS_CPU For all I can tell, this driver only uses the clock interface for its cpufreq driver, and the actual API definition looks bogus. Half of it could be folded into the cpufreq driver, and the rest of it removed, along with arch/mips/include/asm/clock.h > diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig > index cee24c308337..fb0ca0c1efe1 100644 > --- a/arch/sh/boards/Kconfig > +++ b/arch/sh/boards/Kconfig > @@ -7,6 +7,11 @@ config SOLUTION_ENGINE > config SH_ALPHA_BOARD > bool > > +config SH_CUSTOM_CLK > + def_bool y > + depends on !SH_DEVICE_TREE > + select HAVE_LEGACY_CLK > + > config SH_DEVICE_TREE > bool > select OF It's going to be hard to find anyone willing to touch this, as the code is very large but has few users these days. drivers/sh/clk/ is basically a generic clk subsystem on its own, and there are at least 28 different arch/sh SoCs with drivers for it. Arnd
Hi Stephen,
I love your patch! Yet something to improve:
[auto build test ERROR on arm-soc/for-next]
[also build test ERROR on clk/clk-next arm/for-next linus/master v5.6 next-20200405]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Stephen-Boyd/Allow-COMMON_CLK-to-be-selectable/20200405-105253
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.3.0 make.cross ARCH=sparc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
sparc64-linux-ld: drivers/mmc/host/meson-mx-sdio.o: in function `meson_mx_mmc_remove':
>> meson-mx-sdio.c:(.text+0x70): undefined reference to `of_platform_device_destroy'
sparc64-linux-ld: drivers/mmc/host/meson-mx-sdio.o: in function `meson_mx_mmc_probe':
>> meson-mx-sdio.c:(.text+0x9e4): undefined reference to `of_platform_device_create'
>> sparc64-linux-ld: meson-mx-sdio.c:(.text+0xdd4): undefined reference to `of_platform_device_destroy'
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
On Mon, Apr 6, 2020 at 5:01 AM Stephen Boyd <sboyd@kernel.org> wrote: > > Quoting Arnd Bergmann (2020-04-05 05:45:20) > > On Sun, Apr 5, 2020 at 4:51 AM Stephen Boyd <sboyd@kernel.org> wrote: > > > There's one snag with doing this, and that's making sure that randconfig > > > builds don't select this option when some architecture or platform > > > implements 'struct clk' outside of the common clk framework. Introduce a > > > new config option 'HAVE_LEGACY_CLK' to indicate those platforms that > > > haven't migrated to the common clk framework and therefore shouldn't be > > > allowed to select this new config option. Also add a note that we hope > > > one day to remove this config entirely. > > > > Good idea! > > > > I've looked through the individual ones and commented a bit on > > what I think may or may not happen with them. > > > > ralink SOC_MT7621 is the only one that I think you got wrong, > > as it already has common-clk support. > > Ah I missed that it was inside a big if RALINK. Thanks. I suppose I > should just remove the select then for that config and not worry about > the duplication of clkdev and common clk configs. Won't that cause build failures in those configurations that have both implementations? According to the Makefile, the clk.c file is built whenever CONFIG_MIPS_GIC is unset, so I think we need select HAVE_LEGACY_CLK if !MIPS_GIC or maybe move the select into the per-chip configs that need it: RT288X, RT305X, RT3883, and MT7620. > > > diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu > > > index 60ac1cd8b96f..bd2d29c22a10 100644 > > > --- a/arch/m68k/Kconfig.cpu > > > +++ b/arch/m68k/Kconfig.cpu > > > > text data bss dec hex filename > > 1934726 263616 83284 2281626 22d09a obj/vmlinux-before > > 1971989 266192 83308 2321489 236c51 obj/vmlinux-after > > > > The coldfire clock implementation looks rather simple compared > > to chips from the 2010s: most chips have only fixed clocks, > > and three of them have one of two registers of clock gates. > > > > It shouldn't be hard to convert, but enabling common-clk will > > cause a noticeable kernel size increase on the fairly limited > > hardware. > > > > Simply enabling COMMON_CLK in m5475evb_defconfig > > results in a 1.7% or 40KB growth in kernel size, plus there > > would be additional dynamic memory usage: > There could certainly be some work done to reduce the code size of the > CCF. I haven't looked but perhaps we could save some memory by making > the basic types selectable too and then push a bunch of kconfig updates > through for that. Right, that might help. Another possibility would be to support both the common clk layer and the custom clk implementation on coldfire until we remove the other custom implementations, by which point even fewer people will care about coldfire. Let's see what Geert and Greg think would be the best path for coldfire, maybe the added 40KB is less of a problem after all. Arnd
Hi Arnd, Stephen On 6/4/20 5:35 pm, Arnd Bergmann wrote: > On Mon, Apr 6, 2020 at 5:01 AM Stephen Boyd <sboyd@kernel.org> wrote: >> Quoting Arnd Bergmann (2020-04-05 05:45:20) >>> On Sun, Apr 5, 2020 at 4:51 AM Stephen Boyd <sboyd@kernel.org> wrote: >>>> There's one snag with doing this, and that's making sure that randconfig >>>> builds don't select this option when some architecture or platform >>>> implements 'struct clk' outside of the common clk framework. Introduce a >>>> new config option 'HAVE_LEGACY_CLK' to indicate those platforms that >>>> haven't migrated to the common clk framework and therefore shouldn't be >>>> allowed to select this new config option. Also add a note that we hope >>>> one day to remove this config entirely. >>> >>> Good idea! >>> >>> I've looked through the individual ones and commented a bit on >>> what I think may or may not happen with them. >>> >>> ralink SOC_MT7621 is the only one that I think you got wrong, >>> as it already has common-clk support. >> >> Ah I missed that it was inside a big if RALINK. Thanks. I suppose I >> should just remove the select then for that config and not worry about >> the duplication of clkdev and common clk configs. > > Won't that cause build failures in those configurations that have > both implementations? > > According to the Makefile, the clk.c file is built whenever CONFIG_MIPS_GIC > is unset, so I think we need > > select HAVE_LEGACY_CLK if !MIPS_GIC > > or maybe move the select into the per-chip configs that need it: > RT288X, RT305X, RT3883, and MT7620. > >>>> diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu >>>> index 60ac1cd8b96f..bd2d29c22a10 100644 >>>> --- a/arch/m68k/Kconfig.cpu >>>> +++ b/arch/m68k/Kconfig.cpu >>> >>> text data bss dec hex filename >>> 1934726 263616 83284 2281626 22d09a obj/vmlinux-before >>> 1971989 266192 83308 2321489 236c51 obj/vmlinux-after >>> >>> The coldfire clock implementation looks rather simple compared >>> to chips from the 2010s: most chips have only fixed clocks, >>> and three of them have one of two registers of clock gates. >>> >>> It shouldn't be hard to convert, but enabling common-clk will >>> cause a noticeable kernel size increase on the fairly limited >>> hardware. >>> >>> Simply enabling COMMON_CLK in m5475evb_defconfig >>> results in a 1.7% or 40KB growth in kernel size, plus there >>> would be additional dynamic memory usage: >> There could certainly be some work done to reduce the code size of the >> CCF. I haven't looked but perhaps we could save some memory by making >> the basic types selectable too and then push a bunch of kconfig updates >> through for that. > > Right, that might help. Another possibility would be to support both > the common clk layer and the custom clk implementation on coldfire > until we remove the other custom implementations, by which point > even fewer people will care about coldfire. > > Let's see what Geert and Greg think would be the best path for coldfire, > maybe the added 40KB is less of a problem after all. Losing another 40k is not ideal, but not the end of the world. It would not stop me running it on any platforms I regularly run on. For sure some of the really old hardware just doesn't have the RAM to spare. Any way, I say we have to move forward and and move to using the common clock framework for ColdFire sooner than later. Regards Greg
Hi Greg, On Tue, Apr 7, 2020 at 6:57 AM Greg Ungerer <gerg@linux-m68k.org> wrote: > On 6/4/20 5:35 pm, Arnd Bergmann wrote: > > On Mon, Apr 6, 2020 at 5:01 AM Stephen Boyd <sboyd@kernel.org> wrote: > >> Quoting Arnd Bergmann (2020-04-05 05:45:20) > >>> On Sun, Apr 5, 2020 at 4:51 AM Stephen Boyd <sboyd@kernel.org> wrote: > >>>> There's one snag with doing this, and that's making sure that randconfig > >>>> builds don't select this option when some architecture or platform > >>>> implements 'struct clk' outside of the common clk framework. Introduce a > >>>> new config option 'HAVE_LEGACY_CLK' to indicate those platforms that > >>>> haven't migrated to the common clk framework and therefore shouldn't be > >>>> allowed to select this new config option. Also add a note that we hope > >>>> one day to remove this config entirely. > >>>> --- a/arch/m68k/Kconfig.cpu > >>>> +++ b/arch/m68k/Kconfig.cpu > >>> > >>> text data bss dec hex filename > >>> 1934726 263616 83284 2281626 22d09a obj/vmlinux-before > >>> 1971989 266192 83308 2321489 236c51 obj/vmlinux-after > >>> > >>> The coldfire clock implementation looks rather simple compared > >>> to chips from the 2010s: most chips have only fixed clocks, > >>> and three of them have one of two registers of clock gates. > >>> > >>> It shouldn't be hard to convert, but enabling common-clk will > >>> cause a noticeable kernel size increase on the fairly limited > >>> hardware. > >>> > >>> Simply enabling COMMON_CLK in m5475evb_defconfig > >>> results in a 1.7% or 40KB growth in kernel size, plus there > >>> would be additional dynamic memory usage: > >> There could certainly be some work done to reduce the code size of the > >> CCF. I haven't looked but perhaps we could save some memory by making > >> the basic types selectable too and then push a bunch of kconfig updates > >> through for that. > > > > Right, that might help. Another possibility would be to support both > > the common clk layer and the custom clk implementation on coldfire > > until we remove the other custom implementations, by which point > > even fewer people will care about coldfire. > > > > Let's see what Geert and Greg think would be the best path for coldfire, > > maybe the added 40KB is less of a problem after all. > > Losing another 40k is not ideal, but not the end of the world. > It would not stop me running it on any platforms I regularly > run on. For sure some of the really old hardware just doesn't > have the RAM to spare. > > Any way, I say we have to move forward and and move to using > the common clock framework for ColdFire sooner than later. Fine for me. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index eeabdc5a3dd2..0606e1bbd7b6 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -364,6 +364,7 @@ config ARCH_EP93XX select CPU_ARM920T select GENERIC_CLOCKEVENTS select GPIOLIB + select HAVE_LEGACY_CLK help This enables support for the Cirrus EP93xx series of CPUs. @@ -522,6 +523,7 @@ config ARCH_OMAP1 select GENERIC_IRQ_MULTI_HANDLER select GPIOLIB select HAVE_IDE + select HAVE_LEGACY_CLK select IRQ_DOMAIN select NEED_MACH_IO_H if PCCARD select NEED_MACH_MEMORY_H diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig index e65e8d82442a..6444ebfd06a6 100644 --- a/arch/c6x/Kconfig +++ b/arch/c6x/Kconfig @@ -11,6 +11,7 @@ config C6X select ARCH_HAS_SYNC_DMA_FOR_CPU select ARCH_HAS_SYNC_DMA_FOR_DEVICE select CLKDEV_LOOKUP + select HAVE_LEGACY_CLK select GENERIC_ATOMIC64 select GENERIC_IRQ_SHOW select HAVE_ARCH_TRACEHOOK diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu index 60ac1cd8b96f..bd2d29c22a10 100644 --- a/arch/m68k/Kconfig.cpu +++ b/arch/m68k/Kconfig.cpu @@ -28,7 +28,7 @@ config COLDFIRE select CPU_HAS_NO_MULDIV64 select GENERIC_CSUM select GPIOLIB - select HAVE_CLK + select HAVE_LEGACY_CLK endchoice diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index e53a8dd5c19b..fa02c715ab25 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -181,7 +181,7 @@ config AR7 select SYS_SUPPORTS_ZBOOT_UART16550 select GPIOLIB select VLYNQ - select HAVE_CLK + select HAVE_LEGACY_CLK help Support for the Texas Instruments AR7 System-on-a-Chip family: TNETD7100, 7200 and 7300. @@ -296,9 +296,9 @@ config BCM63XX select SYS_HAS_EARLY_PRINTK select SWAP_IO_SPACE select GPIOLIB - select HAVE_CLK select MIPS_L1_CACHE_SHIFT_4 select CLKDEV_LOOKUP + select HAVE_LEGACY_CLK help Support for BCM63XX based boards @@ -419,6 +419,7 @@ config LANTIQ select SWAP_IO_SPACE select BOOT_RAW select CLKDEV_LOOKUP + select HAVE_LEGACY_CLK select USE_OF select PINCTRL select PINCTRL_LANTIQ @@ -656,6 +657,7 @@ config RALINK select SYS_SUPPORTS_MIPS16 select SYS_HAS_EARLY_PRINTK select CLKDEV_LOOKUP + select HAVE_LEGACY_CLK select ARCH_HAS_RESET_CONTROLLER select RESET_CONTROLLER diff --git a/arch/mips/loongson2ef/Kconfig b/arch/mips/loongson2ef/Kconfig index 595dd48e1e4d..c9ec43afde73 100644 --- a/arch/mips/loongson2ef/Kconfig +++ b/arch/mips/loongson2ef/Kconfig @@ -46,7 +46,7 @@ config LEMOTE_MACH2F select CSRC_R4K if ! MIPS_EXTERNAL_TIMER select DMA_NONCOHERENT select GENERIC_ISA_DMA_SUPPORT_BROKEN - select HAVE_CLK + select HAVE_LEGACY_CLK select FORCE_PCI select I8259 select IRQ_MIPS_CPU diff --git a/arch/sh/boards/Kconfig b/arch/sh/boards/Kconfig index cee24c308337..fb0ca0c1efe1 100644 --- a/arch/sh/boards/Kconfig +++ b/arch/sh/boards/Kconfig @@ -7,6 +7,11 @@ config SOLUTION_ENGINE config SH_ALPHA_BOARD bool +config SH_CUSTOM_CLK + def_bool y + depends on !SH_DEVICE_TREE + select HAVE_LEGACY_CLK + config SH_DEVICE_TREE bool select OF diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig index 41fe944005f8..11ba1839d198 100644 --- a/arch/unicore32/Kconfig +++ b/arch/unicore32/Kconfig @@ -70,7 +70,7 @@ config ARCH_PUV3 def_bool y select CPU_UCV2 select GENERIC_CLOCKEVENTS - select HAVE_CLK + select HAVE_LEGACY_CLK select GPIOLIB # CONFIGs for ARCH_PUV3 diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index bcb257baed06..890bed62196d 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -7,8 +7,18 @@ config CLKDEV_LOOKUP config HAVE_CLK_PREPARE bool -config COMMON_CLK +config HAVE_LEGACY_CLK # TODO: Remove once all legacy users are migrated bool + select HAVE_CLK + help + Select this option when the clock API in <linux/clk.h> is implemented + by platform/architecture code. This method is deprecated. Modern + code should select COMMON_CLK instead and not define a custom + 'struct clk'. + +menuconfig COMMON_CLK + bool "Common Clock Framework" + depends on !HAVE_LEGACY_CLK select HAVE_CLK_PREPARE select CLKDEV_LOOKUP select SRCU @@ -20,8 +30,7 @@ config COMMON_CLK Architectures utilizing the common struct clk should select this option. -menu "Common Clock Framework" - depends on COMMON_CLK +if COMMON_CLK config COMMON_CLK_WM831X tristate "Clock driver for WM831x/2x PMICs" @@ -362,4 +371,4 @@ source "drivers/clk/ti/Kconfig" source "drivers/clk/uniphier/Kconfig" source "drivers/clk/zynqmp/Kconfig" -endmenu +endif
Enable build testing and configuration control of the common clk framework so that more code coverage and testing can be done on the common clk framework across various architectures. This also nicely removes the requirement that architectures must select the framework when they don't use it in architecture code. There's one snag with doing this, and that's making sure that randconfig builds don't select this option when some architecture or platform implements 'struct clk' outside of the common clk framework. Introduce a new config option 'HAVE_LEGACY_CLK' to indicate those platforms that haven't migrated to the common clk framework and therefore shouldn't be allowed to select this new config option. Also add a note that we hope one day to remove this config entirely. Based on a patch by Mark Brown <broonie@kernel.org>. Cc: Mark Brown <broonie@kernel.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Mark Salter <msalter@redhat.com> Cc: Aurelien Jacquiot <jacquiot.aurelien@gmail.com> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Guan Xuetao <gxt@pku.edu.cn> Cc: Russell King <linux@armlinux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Rich Felker <dalias@libc.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: <linux-mips@vger.kernel.org> Cc: <linux-c6x-dev@linux-c6x.org> Cc: <linux-m68k@lists.linux-m68k.org> Cc: <linux-arm-kernel@lists.infradead.org> Cc: <linux-sh@vger.kernel.org> Link: https://lore.kernel.org/r/1470915049-15249-1-git-send-email-broonie@kernel.org Signed-off-by: Stephen Boyd <sboyd@kernel.org> --- arch/arm/Kconfig | 2 ++ arch/c6x/Kconfig | 1 + arch/m68k/Kconfig.cpu | 2 +- arch/mips/Kconfig | 6 ++++-- arch/mips/loongson2ef/Kconfig | 2 +- arch/sh/boards/Kconfig | 5 +++++ arch/unicore32/Kconfig | 2 +- drivers/clk/Kconfig | 17 +++++++++++++---- 8 files changed, 28 insertions(+), 9 deletions(-)