[6/9] clk: Allow the common clk framework to be selectable
diff mbox series

Message ID 20200405025123.154688-7-sboyd@kernel.org
State New, archived
Headers show
Series
  • Allow COMMON_CLK to be selectable
Related show

Commit Message

Stephen Boyd April 5, 2020, 2:51 a.m. UTC
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(-)

Comments

Arnd Bergmann April 5, 2020, 12:45 p.m. UTC | #1
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
kernel test robot April 5, 2020, 2:27 p.m. UTC | #2
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
Arnd Bergmann April 6, 2020, 7:35 a.m. UTC | #3
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
Greg Ungerer April 7, 2020, 4:57 a.m. UTC | #4
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
Geert Uytterhoeven April 7, 2020, 7:07 a.m. UTC | #5
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

Patch
diff mbox series

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