Messages in this thread |  | | Date | Sun, 10 Nov 2019 11:16:47 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: [GIT PULL] interconnect changes for 5.5 |
| |
On Sat, Nov 09, 2019 at 12:27:29PM -0800, Bjorn Andersson wrote: > On Sat, Nov 9, 2019 at 12:48 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > On Fri, Nov 08, 2019 at 05:36:46PM -0800, Bjorn Andersson wrote: > > > On Fri, Nov 8, 2019 at 2:39 AM Greg Kroah-Hartman > > > <gregkh@linuxfoundation.org> wrote: > > > > > > > > On Thu, Nov 07, 2019 at 05:42:13PM +0200, Georgi Djakov wrote: > > > > > Hi Greg, > > > > > > > > > > On 11/7/19 16:21, Greg Kroah-Hartman wrote: > > > > > > On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote: > > > > > >> Hi Greg, > > > > > >> > > > > > >> This is a pull request with interconnect patches for the 5.5 merge window. > > > > > >> All patches have been for a while in linux-next without reported issues. The > > > > > >> details are in the signed tag. Please consider pulling into char-misc-next. > > > > > > > > > > > > I don't know about > > > > > > 0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here. > > > > > > Shouldn't you just fix up the dependancies of subsystems that rely on > > > > > > this? We are moving more and more to kernels that "just work" with > > > > > > everything as modules, even on arm64 systems. So forbiding the > > > > > > interconnect code from being able to be built as a module does not feel > > > > > > good to me at all. > > > > > > > > > > Thank you for commenting on this! The initial idea was to keep everything as > > > > > modular as possible. The reasons behind this change is that other core > > > > > frameworks like cpufreq (and possibly others) want to call the interconnect > > > > > APIs. Some of these frameworks are built-in only and it would be easier to > > > > > handle dependencies if interconnect core built-in too. Now each user that > > > > > can be built-in has to specify in Kconfig that it depends on INTERCONNECT || > > > > > !INTERCONNECT. > > > > > > > > That's fine, when those subsystems start to use those apis, that > > > > dependency needs to be added. Nothing new here, and you forcing it to > > > > either be "on or off" isn't going to change that. Let's do it correctly > > > > please. > > > > > > > > > > Please no! > > > > > > Making our frameworks tristate means that we can no longer rely on > > > include file stubs (as framework=m, client=y will fail), so every > > > single client must add the "depends on framework || framework=n" - in > > > contrast to nothing the framework itself is bool. > > > > What's wrong with a single "depends on framework"? If your code relies > > on this framework, you should depend on it, right? > > As your question shows, everyone gets this wrong and the build breaks > all the time (it's not "depends on framework", it's "depends on > framework || framework=n" - and everyone you'll talk to will be > puzzled as to why this is).
Ah, now I get it. Yeah, that sucks. We need a "shortcut" in Kconfig to express that type of dependancy.
thanks,
greg k-h
|  |