All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Eduardo Valentin <edubezval@gmail.com>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Kukjin Kim <kgene@kernel.org>, Zhang Rui <rui.zhang@intel.com>
Subject: Re: [PATCH 3/3] cpufreq: exynos: allow modular build
Date: Thu, 29 Jan 2015 11:01:16 +0100	[thread overview]
Message-ID: <2157802.ranbh8xTdL@wuerfel> (raw)
In-Reply-To: <CAKohpom9L4jiMRGn3OaWyYM7iR3Ame4-LKG144yuHmRxCJud3g@mail.gmail.com>

On Thursday 29 January 2015 09:09:03 Viresh Kumar wrote:
> On 29 January 2015 at 01:31, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> >>  config ARM_EXYNOS_CPUFREQ
> >> -     bool
> >> +     tristate "SAMSUNG EXYNOS CPUfreq Driver"
> >> +     depends on THERMAL
> >> +     default y
> >> +     help
> >> +       This adds the CPUFreq driver for Samsung EXYNOS platforms
> >> +
> >> +       If in doubt, say N.
> >
> > Now the option shows up on all systems that include Kconfig.arm,
> > in particular non-exynos machines that might not even be able
> > to build this.
> 
> I am sure I am wrong here, but want to know what I am missing.
> What about:
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index c3c3cf52d2d9..f3ee05067a69 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -27,7 +27,7 @@ config ARM_VEXPRESS_SPC_CPUFREQ
> 
>  config ARM_EXYNOS_CPUFREQ
>         tristate "SAMSUNG EXYNOS CPUfreq Driver"
> -       depends on THERMAL
> +       depends on THERMAL && ARCH_EXYNOS
>         default y
>         help
>           This adds the CPUFreq driver for Samsung EXYNOS platforms

That might be close enough to what we want. It would by default enable
ARM_EXYNOS_CPUFREQ for exynos based machines that do not use this driver
(e.g. 5440, which has a separate driver, or exynos3/exynos7), but that
can probably just be dealt with by disabling it in the user's defconfig.
If i'm reading exynos_cpufreq_probe right, it would actually compile
into an almost-empty file in this case and only kzalloc a few bytes
of memory and then print a warning message.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] cpufreq: exynos: allow modular build
Date: Thu, 29 Jan 2015 11:01:16 +0100	[thread overview]
Message-ID: <2157802.ranbh8xTdL@wuerfel> (raw)
In-Reply-To: <CAKohpom9L4jiMRGn3OaWyYM7iR3Ame4-LKG144yuHmRxCJud3g@mail.gmail.com>

On Thursday 29 January 2015 09:09:03 Viresh Kumar wrote:
> On 29 January 2015 at 01:31, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> >>  config ARM_EXYNOS_CPUFREQ
> >> -     bool
> >> +     tristate "SAMSUNG EXYNOS CPUfreq Driver"
> >> +     depends on THERMAL
> >> +     default y
> >> +     help
> >> +       This adds the CPUFreq driver for Samsung EXYNOS platforms
> >> +
> >> +       If in doubt, say N.
> >
> > Now the option shows up on all systems that include Kconfig.arm,
> > in particular non-exynos machines that might not even be able
> > to build this.
> 
> I am sure I am wrong here, but want to know what I am missing.
> What about:
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index c3c3cf52d2d9..f3ee05067a69 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -27,7 +27,7 @@ config ARM_VEXPRESS_SPC_CPUFREQ
> 
>  config ARM_EXYNOS_CPUFREQ
>         tristate "SAMSUNG EXYNOS CPUfreq Driver"
> -       depends on THERMAL
> +       depends on THERMAL && ARCH_EXYNOS
>         default y
>         help
>           This adds the CPUFreq driver for Samsung EXYNOS platforms

That might be close enough to what we want. It would by default enable
ARM_EXYNOS_CPUFREQ for exynos based machines that do not use this driver
(e.g. 5440, which has a separate driver, or exynos3/exynos7), but that
can probably just be dealt with by disabling it in the user's defconfig.
If i'm reading exynos_cpufreq_probe right, it would actually compile
into an almost-empty file in this case and only kzalloc a few bytes
of memory and then print a warning message.

	Arnd

  reply	other threads:[~2015-01-29 10:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 13:16 [PATCH 0/3] cpufreq: build fixes Arnd Bergmann
2015-01-28 13:16 ` Arnd Bergmann
2015-01-28 13:16 ` [PATCH 1/3] cpufreq: s3c: remove incorrect __init annotations Arnd Bergmann
2015-01-28 13:16   ` Arnd Bergmann
2015-01-29  3:23   ` Viresh Kumar
2015-01-29  3:23     ` Viresh Kumar
2015-01-28 13:16 ` [PATCH 2/3] cpufreq: s3c: remove last use of resume_clocks callback Arnd Bergmann
2015-01-28 13:16   ` Arnd Bergmann
2015-01-29  3:23   ` Viresh Kumar
2015-01-29  3:23     ` Viresh Kumar
2015-01-28 13:16 ` [PATCH 3/3] cpufreq: exynos: allow modular build Arnd Bergmann
2015-01-28 13:16   ` Arnd Bergmann
2015-01-28 17:22   ` Eduardo Valentin
2015-01-28 17:22     ` Eduardo Valentin
2015-01-28 20:01     ` Arnd Bergmann
2015-01-28 20:01       ` Arnd Bergmann
2015-01-29  3:39       ` Viresh Kumar
2015-01-29  3:39         ` Viresh Kumar
2015-01-29 10:01         ` Arnd Bergmann [this message]
2015-01-29 10:01           ` Arnd Bergmann
2015-01-29 10:10           ` Viresh Kumar
2015-01-29 10:10             ` Viresh Kumar
2015-01-29 12:42             ` Arnd Bergmann
2015-01-29 12:42               ` Arnd Bergmann
2015-01-29 22:21               ` Eduardo Valentin
2015-01-29 22:21                 ` Eduardo Valentin
2015-01-30 21:24                 ` Arnd Bergmann
2015-01-30 21:24                   ` Arnd Bergmann
2015-01-30 21:51                   ` Eduardo Valentin
2015-01-30 21:51                     ` Eduardo Valentin
2015-01-31 22:37                     ` Arnd Bergmann
2015-01-31 22:37                       ` Arnd Bergmann
2015-01-30  0:58 ` [PATCH 0/3] cpufreq: build fixes Rafael J. Wysocki
2015-01-30  0:58   ` Rafael J. Wysocki

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=2157802.ranbh8xTdL@wuerfel \
    --to=arnd@arndb.de \
    --cc=edubezval@gmail.com \
    --cc=kgene@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rui.zhang@intel.com \
    --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.