All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Georgi Djakov <georgi.djakov@linaro.org>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [GIT PULL] interconnect changes for 5.5
Date: Sun, 10 Nov 2019 11:16:47 +0100	[thread overview]
Message-ID: <20191110101647.GA1441986@kroah.com> (raw)
In-Reply-To: <CAOCOHw4AFz2Rj3sLTrboA0pBOkL_5MbitJnFHgBYaVBbWyYATw@mail.gmail.com>

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

  reply	other threads:[~2019-11-10 10:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191110101647.GA1441986@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=georgi.djakov@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.