All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Darren Hart <dvhart@infradead.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Andy Shevchenko <andy@infradead.org>,
	platform-driver-x86@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: intel_turbo_max_3 non-modularity
Date: Fri, 28 Apr 2017 10:40:10 +0200	[thread overview]
Message-ID: <20170428104010.2fc36751@endymion> (raw)
In-Reply-To: <1493335126.69096.481.camel@linux.intel.com>

Hi Darren and Srinivas,

Thanks a lot for stepping in.

On Thu, 27 Apr 2017 16:18:46 -0700, Srinivas Pandruvada wrote:
> On Thu, 2017-04-27 at 14:48 -0700, Darren Hart wrote:
> > Reverting Paul's non-module patch and adding "tristate" "default m",
> > it builds cleanly, but fails modpost:

This was on my to-do list, thanks for saving me some time :-)

For the record, Paul's patch also added a few missing includes, which
should be preserved.

> > ERROR: "sched_set_itmt_core_prio"
> > [drivers/platform/x86/intel_turbo_max_3.ko] undefined!
> > ERROR: "sched_set_itmt_support"
> > [drivers/platform/x86/intel_turbo_max_3.ko] undefined!
> > 
> > Peter, Google is failing me for a statement from you on EXPORT_SYMBOL'ing sched_
> > functions, so can you weigh in here? Have you and Srinivas already discussed
> > this and determined it was unacceptable to export the two sched itmt related
> > functions above?
>
> Before to this patch, only intel_pstate driver called these two
> sched_xx() functions. intel_pstate can be only be built-in, so no
> effort was made to export these functions when they were developed to
> add ITMT support.

By the way, is there any fundamental reason why intel_pstate could not
be modularized? Or was it just another instance of needing functions
which were not exported yet? I know that the intel_pstate driver is
widely used nowadays, but still, this is a CPU-specific driver that
not all x86 users need, and it isn't slim. It would be nice to be able
to build it as a module too.

> But turbo_max_3 driver driver will only load on a subset of non HWP
> Broadwell systems, making module is not a bad idea. To do that we can

It was also my understanding that the scope of this driver was limited,
which is why I was worried that it could only be built-in.

> export these two sched_xx() functions as they are only related to ITMT
> function anyway.
> If Peter agrees, I can send a patch to change this.

That would be great.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

  parent reply	other threads:[~2017-04-28  8:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24  9:31 intel_turbo_max_3 non-modularity Jean Delvare
2017-04-24 14:02 ` Paul Gortmaker
2017-04-27 21:48   ` Darren Hart
2017-04-27 23:18     ` Srinivas Pandruvada
2017-04-28  7:55       ` Peter Zijlstra
2017-04-28 13:20         ` Jean Delvare
2017-04-28 13:46           ` Peter Zijlstra
2017-04-28 15:49             ` Darren Hart
2017-04-28 16:34               ` Peter Zijlstra
2017-04-28 20:58                 ` Darren Hart
2017-04-28 21:39                   ` Peter Zijlstra
2017-04-28  8:40       ` Jean Delvare [this message]
2017-04-28 20:35         ` Srinivas Pandruvada
2017-04-28  7:49   ` Jean Delvare
2017-04-28 17:44     ` Paul Gortmaker
2017-04-28 20:49       ` Darren Hart
2017-04-28 21:34         ` Peter Zijlstra
2017-04-28 22:51           ` Darren Hart

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=20170428104010.2fc36751@endymion \
    --to=jdelvare@suse.de \
    --cc=andy@infradead.org \
    --cc=dvhart@infradead.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=peterz@infradead.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    /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.