* [GIT PULL] interconnect changes for 5.5 @ 2019-11-07 12:46 Georgi Djakov 2019-11-07 14:21 ` Greg Kroah-Hartman 0 siblings, 1 reply; 13+ messages in thread From: Georgi Djakov @ 2019-11-07 12:46 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: Linux PM list, linux-kernel 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. Thanks, Georgi The following changes since commit 4f5cafb5cb8471e54afdc9054d973535614f7675: Linux 5.4-rc3 (2019-10-13 16:37:36 -0700) are available in the Git repository at: https://git.linaro.org/people/georgi.djakov/linux.git tags/icc-5.5-rc1 for you to fetch changes up to 0bf9146d94a00c7759a30241eeabd3e2b28c5f15: docs: driver-api: make interconnect title quieter (2019-11-02 04:04:35 +0200) ---------------------------------------------------------------- interconnect patches for 5.5 Here are the interconnect updates for the 5.5-rc1 merge window. - Disallow the interconnect core to be built as a module, as this will bring more complexity when this API is called from other frameworks that are built-in only. - New interconnect driver for msm8974 platforms. - Change the initcall level of a driver, so it is available earlier to other dependent drivers. - Minor clean-up and a tiny documentation fix. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> ---------------------------------------------------------------- Brian Masney (2): dt-bindings: interconnect: qcom: add msm8974 bindings interconnect: qcom: add msm8974 driver Georgi Djakov (1): interconnect: Add locking in icc_set_tag() Jordan Crouse (2): interconnect: Move interconnect drivers to core_initcall interconnect: Remove unused module exit code from core Leonard Crestez (1): interconnect: qcom: Fix icc_onecell_data allocation Louis Taylor (1): docs: driver-api: make interconnect title quieter Viresh Kumar (1): interconnect: Disallow interconnect core to be built as a module Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml | 62 + Documentation/driver-api/interconnect.rst | 2 +- drivers/interconnect/Kconfig | 2 +- drivers/interconnect/core.c | 11 +- drivers/interconnect/qcom/Kconfig | 9 + drivers/interconnect/qcom/Makefile | 2 + drivers/interconnect/qcom/msm8974.c | 796 ++++++++ drivers/interconnect/qcom/qcs404.c | 17 +- drivers/interconnect/qcom/sdm845.c | 16 +- include/dt-bindings/interconnect/qcom,msm8974.h | 146 ++ 10 files changed, 1051 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,msm8974.yaml create mode 100644 drivers/interconnect/qcom/msm8974.c create mode 100644 include/dt-bindings/interconnect/qcom,msm8974.h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-07 12:46 [GIT PULL] interconnect changes for 5.5 Georgi Djakov @ 2019-11-07 14:21 ` Greg Kroah-Hartman 2019-11-07 15:42 ` Georgi Djakov 0 siblings, 1 reply; 13+ messages in thread From: Greg Kroah-Hartman @ 2019-11-07 14:21 UTC (permalink / raw) To: Georgi Djakov; +Cc: Linux PM list, linux-kernel 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. Same for 0007-interconnect-Remove-unused-module-exit-code-from-cor.patch, we are adding module_init/exit() calls to modules, do not remove them! Can you drop those two patches and resend? Or I can just take these out of the pull request and apply the rest as patches for now, if that's easier for you to handle. thanks, greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-07 14:21 ` Greg Kroah-Hartman @ 2019-11-07 15:42 ` Georgi Djakov 2019-11-08 10:39 ` Greg Kroah-Hartman 0 siblings, 1 reply; 13+ messages in thread From: Georgi Djakov @ 2019-11-07 15:42 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Linux PM list, linux-kernel, Viresh Kumar, Bjorn Andersson 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. > > Same for > 0007-interconnect-Remove-unused-module-exit-code-from-cor.patch, we are > adding module_init/exit() calls to modules, do not remove them! > > > Can you drop those two patches and resend? Or I can just take these out > of the pull request and apply the rest as patches for now, if that's > easier for you to handle. Ok, will drop them for now and re-send! Thanks, Georgi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-07 15:42 ` Georgi Djakov @ 2019-11-08 10:39 ` Greg Kroah-Hartman 2019-11-08 11:44 ` Georgi Djakov 2019-11-09 1:36 ` Bjorn Andersson 0 siblings, 2 replies; 13+ messages in thread From: Greg Kroah-Hartman @ 2019-11-08 10:39 UTC (permalink / raw) To: Georgi Djakov; +Cc: Linux PM list, linux-kernel, Viresh Kumar, Bjorn Andersson 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. thanks, greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-08 10:39 ` Greg Kroah-Hartman @ 2019-11-08 11:44 ` Georgi Djakov 2019-11-09 1:36 ` Bjorn Andersson 1 sibling, 0 replies; 13+ messages in thread From: Georgi Djakov @ 2019-11-08 11:44 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Linux PM list, linux-kernel, Viresh Kumar, Bjorn Andersson On 8.11.19 г. 12:39 ч., Greg Kroah-Hartman 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. Alright! That matches with what we do today. Thanks for the guidance! BR, Georgi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-08 10:39 ` Greg Kroah-Hartman 2019-11-08 11:44 ` Georgi Djakov @ 2019-11-09 1:36 ` Bjorn Andersson 2019-11-09 8:48 ` Greg Kroah-Hartman 1 sibling, 1 reply; 13+ messages in thread From: Bjorn Andersson @ 2019-11-09 1:36 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Georgi Djakov, Linux PM list, linux-kernel, Viresh Kumar 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. An example of this is that there's almost 500 files referencing the regulator api and all Kconfig entries referencing these files must be updated with a "depends on REGULATOR || REGULATOR=n" if we're going to start tristating frameworks. For individual drivers behind these frameworks, definitely tristate. But the only thing you're going to get out of making the frameworks tristate is more build failures. Regards, Bjorn ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-09 1:36 ` Bjorn Andersson @ 2019-11-09 8:48 ` Greg Kroah-Hartman 2019-11-09 20:27 ` Bjorn Andersson 0 siblings, 1 reply; 13+ messages in thread From: Greg Kroah-Hartman @ 2019-11-09 8:48 UTC (permalink / raw) To: Bjorn Andersson; +Cc: Georgi Djakov, Linux PM list, linux-kernel, Viresh Kumar 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? Include file stubs feels odd for a core functionality, if you can live without that functionality, then sure, don't depend on it and all should be just fine. thanks, greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-09 8:48 ` Greg Kroah-Hartman @ 2019-11-09 20:27 ` Bjorn Andersson 2019-11-10 10:16 ` Greg Kroah-Hartman 0 siblings, 1 reply; 13+ messages in thread From: Bjorn Andersson @ 2019-11-09 20:27 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Georgi Djakov, Linux PM list, linux-kernel, Viresh Kumar 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). But consistently introducing this for clocks, regulators, pinctrl, resets, etc should be a task so large that people will come out educated from it - or whatever it is that one feels after fixing thousands of Kconfig entries. > Include file stubs > feels odd for a core functionality, if you can live without that > functionality, then sure, don't depend on it and all should be just > fine. > Odd or not, it's what we have in all these frameworks. Regards, Bjorn > thanks, > > greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-09 20:27 ` Bjorn Andersson @ 2019-11-10 10:16 ` Greg Kroah-Hartman 2019-11-11 4:54 ` Viresh Kumar 2019-11-14 8:41 ` Viresh Kumar 0 siblings, 2 replies; 13+ messages in thread From: Greg Kroah-Hartman @ 2019-11-10 10:16 UTC (permalink / raw) To: Bjorn Andersson; +Cc: Georgi Djakov, Linux PM list, linux-kernel, Viresh Kumar 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-10 10:16 ` Greg Kroah-Hartman @ 2019-11-11 4:54 ` Viresh Kumar 2019-11-11 5:26 ` Greg Kroah-Hartman 2019-11-14 8:41 ` Viresh Kumar 1 sibling, 1 reply; 13+ messages in thread From: Viresh Kumar @ 2019-11-11 4:54 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Bjorn Andersson, Georgi Djakov, Linux PM list, linux-kernel On 10-11-19, 11:16, Greg Kroah-Hartman wrote: > Ah, now I get it. Yeah, that sucks. We need a "shortcut" in Kconfig to > express that type of dependancy. So we are going to merge this patch for now ? @Bjorn, thanks for replying while I was away :) -- viresh ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-11 4:54 ` Viresh Kumar @ 2019-11-11 5:26 ` Greg Kroah-Hartman 0 siblings, 0 replies; 13+ messages in thread From: Greg Kroah-Hartman @ 2019-11-11 5:26 UTC (permalink / raw) To: Viresh Kumar; +Cc: Bjorn Andersson, Georgi Djakov, Linux PM list, linux-kernel On Mon, Nov 11, 2019 at 10:24:23AM +0530, Viresh Kumar wrote: > On 10-11-19, 11:16, Greg Kroah-Hartman wrote: > > Ah, now I get it. Yeah, that sucks. We need a "shortcut" in Kconfig to > > express that type of dependancy. > > So we are going to merge this patch for now ? I did not, sorry. greg k-h ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-10 10:16 ` Greg Kroah-Hartman 2019-11-11 4:54 ` Viresh Kumar @ 2019-11-14 8:41 ` Viresh Kumar 2019-11-14 12:59 ` Georgi Djakov 1 sibling, 1 reply; 13+ messages in thread From: Viresh Kumar @ 2019-11-14 8:41 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Bjorn Andersson, Georgi Djakov, Linux PM list, linux-kernel On 10-11-19, 11:16, Greg Kroah-Hartman wrote: > On Sat, Nov 09, 2019 at 12:27:29PM -0800, Bjorn Andersson wrote: > > 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. Maybe we can use depends on framework != m -- viresh ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [GIT PULL] interconnect changes for 5.5 2019-11-14 8:41 ` Viresh Kumar @ 2019-11-14 12:59 ` Georgi Djakov 0 siblings, 0 replies; 13+ messages in thread From: Georgi Djakov @ 2019-11-14 12:59 UTC (permalink / raw) To: Viresh Kumar, Greg Kroah-Hartman Cc: Bjorn Andersson, Linux PM list, linux-kernel On 11/14/19 10:41, Viresh Kumar wrote: > On 10-11-19, 11:16, Greg Kroah-Hartman wrote: >> On Sat, Nov 09, 2019 at 12:27:29PM -0800, Bjorn Andersson wrote: >>> 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. > > Maybe we can use > > depends on framework != m That won't work in the case where framework=m, provider=m and consumer=m. Today this is supported by having each consumer to: depends on framework || !framework So again, the problem is that we need to add something to Kconfig, even a "shortcut", in order to express this dependency. If we convert the framework from tristate to bool, there will be no need to touch Kconfig, as we have the include stubs. Keeping the modular support comes at the cost of adding a dependency to Kconfig for each user. Thanks, Georgi ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-11-14 12:59 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-07 12:46 [GIT PULL] interconnect changes for 5.5 Georgi Djakov 2019-11-07 14:21 ` Greg Kroah-Hartman 2019-11-07 15:42 ` Georgi Djakov 2019-11-08 10:39 ` Greg Kroah-Hartman 2019-11-08 11:44 ` Georgi Djakov 2019-11-09 1:36 ` Bjorn Andersson 2019-11-09 8:48 ` Greg Kroah-Hartman 2019-11-09 20:27 ` Bjorn Andersson 2019-11-10 10:16 ` Greg Kroah-Hartman 2019-11-11 4:54 ` Viresh Kumar 2019-11-11 5:26 ` Greg Kroah-Hartman 2019-11-14 8:41 ` Viresh Kumar 2019-11-14 12:59 ` Georgi Djakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).