linux-kernel - Re: [PATCH] [RFC] clk: sprd: fix compile-testing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 10 Apr 2020 19:27:26 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Chunyan Zhang <zhang.lyra@...il.com>,
        Sandeep Patil <sspatil@...roid.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Chunyan Zhang <chunyan.zhang@...soc.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        Orson Zhai <orson.zhai@...soc.com>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH] [RFC] clk: sprd: fix compile-testing

Quoting Chunyan Zhang (2020-04-09 20:45:16)
> We see this broken because I shouldn't leave clk Makefile a tristate
> compile [1] after changing ARCH_SPRD to be tristate.
> 
> If we will make ARCH_SPRD tristate-able in the future and you all
> aggree that, I would like to do it now, and pay more attention to
> Makefiles and dependencies.
> 
> I can also make a change like below:
> 
> diff --git a/drivers/clk/sprd/Kconfig b/drivers/clk/sprd/Kconfig
> index e18c80fbe804..9f7d9d8899a5 100644
> --- a/drivers/clk/sprd/Kconfig
> +++ b/drivers/clk/sprd/Kconfig
> @@ -2,6 +2,7 @@
>  config SPRD_COMMON_CLK
>         tristate "Clock support for Spreadtrum SoCs"
>         depends on ARCH_SPRD || COMPILE_TEST
> +       depends on m || ARCH_SPRD != m
>         default ARCH_SPRD
>         select REGMAP_MMIO
> 
> Arnd, Stephen, Sandeep, what do you think? Does that make sense?

Sorry, doesn't make any sense to me. The ARCH_FOO configs for various
platforms are intended to be used to limit the configuration space of
various other Kconfig symbols for the code that only matters to those
platforms. The usage of depends and default is correct here already. The
ARCH_FOO configs should always be bool. Any code bloat problems seen by
config symbols enabling because they're 'default ARCH_FOO' can be
resolved by explicitly disabling those configs.