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

[Greg Kroah-Hartman]

On Fri, May 15, 2020 at 07:48:47AM +0300, Georgi Djakov wrote:
> On 9/12/19 19:33, Bjorn Andersson wrote:
> > On Thu, Aug 29, 2019 at 1:07 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> 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?

Ok, if it makes things easier, perhaps this is the best way to handle
it.

thanks,

greg k-h