On Tue, Oct 14, 2008 at 10:30:20AM +0200, Sven Wegener wrote:
> On Mon, 13 Oct 2008, David Miller wrote:
>
> > sparc64 allmodconfig started failing to build recently:
> >
> > MODPOST 1946 modules
> > ERROR: "cpufreq_gov_performance" [arch/sparc64/kernel/us3_cpufreq.ko] undefined!
> >
> > It seems to be caused by the following commit:
> >
> > commit c4d14bc0bb5d13e316890651ae4518b764c3344c
> > Author: Sven Wegener <sven.wegener@xxxxxxxxxxx>
> > Date: Sat Sep 20 16:50:08 2008 +0200
> >
> > [CPUFREQ] Don't export governors for default governor
> >
> > We don't need to export the governors for use as the default governor,
> > because the default governor will be built-in anyway and we can access
> > the symbol directly.
>
> Uhm, we could resolve this dependency with the patch below. Although we
> might as well revert the above commit or introduce an exported function
> that sets the default governor on a policy.
>
> Subject: [CPUFREQ] Fix build failure on sparc64
>
> Commit c4d14bc0bb5d13e316890651ae4518b764c3344c ("[CPUFREQ] Don't export
> governors for default governor") caused a build failure, because there are
> several architectures that have cpufreq code that can be built as a
> module, but the code also requires access to the default governor. Export
> the default governor so that it can be accessed by these module.
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -576,7 +576,9 @@ static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
> return 0;
> }
>
> -#ifndef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
> +#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
> +EXPORT_SYMBOL(cpufreq_gov_conservative);
> +#else
> static
> #endif
This is ugly, ugly.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
