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.ku...@linaro.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?
Ok, if it makes things easier, perhaps this is the best way to handle it. thanks, greg k-h