linux-kernel - Re: [PATCH] interconnect: Disallow interconnect core to be built as a module

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]

Message-ID: <66c3d470-48e2-619a-dd95-6064a85161e0@linaro.org>
Date:   Fri, 15 May 2020 07:48:47 +0300
From:   Georgi Djakov <georgi.djakov@...aro.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Linux PM list <linux-pm@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Matthias Kaehlcke <mka@...omium.org>
Subject: Re: [PATCH] interconnect: Disallow interconnect core to be built as a
 module

On 9/12/19 19:33, Bjorn Andersson wrote:
> On Thu, Aug 29, 2019 at 1:07 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>>
>> Building individual drivers as modules is fine but allowing a core
>> framework to be built as a module makes it really complex and should be
>> avoided.
>>
>> Whatever uses the interconnect core APIs must also be built as a module
>> if interconnect core is built as module, else we will see compilation
>> failures.
>>
>> If another core framework (like cpufreq, clk, etc), that can't be built
>> as module, needs to use interconnect APIs then we will start seeing
>> compilation failures with allmodconfig configurations as the symbols
>> (like of_icc_get()) used in other frameworks will not be available in
>> the built-in image.
>>
>> Disallow the interconnect core to be built as a module to avoid all
>> these issues.

Hi Greg,

We had a discussion [1] a few months back about frameworks being built as
modules. IIUC, you initially expressed some doubts about this patch, so i
wanted to check with you again on this.

While i think that the possibility for a framework core to be a module is a
nice feature, and we should try to be as modular as possible, it seems that
handling dependencies between the different core frameworks becomes difficult
when one of them is tristate.

This of course affects the drivers which use it (every client should express
the dependency in Kconfig as a "depends on framework || !framework"), in order
to avoid build failures in the case when framework=m and client=y. However, this
is not a big issue.

But it gets more complex when another framework2 becomes a client of the modular
framework and especially when framework2 is "select"-ed in Kconfig by it's
users. When selects are used in Kconfig, it forces the option, without ever
visiting the dependencies. I am not sure what we should do in this case, maybe
we can continue and sprinkle more "depends on framework || !framework" also for
every single user which selects framework2.. But i believe that this is very
inconvenient.

Well, the above is not impossible, but other frameworks (regulator, clk, reset,
pinctrl, etc.) are solving this problem by just being bool, instead of tristate.
This makes life much easier for everyone. So i am wondering if it wouldn't be
more appropriate to use the same approach here too?

Thanks,
Georgi

[1] https://lore.kernel.org/linux-pm/20191107142111.GB109902@kroah.com/

>>
> 
> Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> 
>> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
>> ---
>>  drivers/interconnect/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
>> index bfa4ca3ab7a9..b6ea8f0a6122 100644
>> --- a/drivers/interconnect/Kconfig
>> +++ b/drivers/interconnect/Kconfig
>> @@ -1,6 +1,6 @@
>>  # SPDX-License-Identifier: GPL-2.0-only
>>  menuconfig INTERCONNECT
>> -       tristate "On-Chip Interconnect management support"
>> +       bool "On-Chip Interconnect management support"
>>         help
>>           Support for management of the on-chip interconnects.
>>
>> --
>> 2.21.0.rc0.269.g1a574e7a288b
>>