[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52A10431.6070306@wwwdotorg.org>
Date: Thu, 05 Dec 2013 15:54:41 -0700
From: Stephen Warren <swarren@...dotorg.org>
To: Bill Huang <bilhuang@...dia.com>, rjw@...ysocki.net,
viresh.kumar@...aro.org, thierry.reding@...il.com
CC: linux-kernel@...r.kernel.org, cpufreq@...r.kernel.org,
linux-pm@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v3 1/2] cpufreq: tegra: Call tegra_cpufreq_init() specifically
in machine code
On 12/05/2013 12:44 AM, Bill Huang wrote:
> Move the call from module_init to Tegra machine codes so it won't be
> called in a multi-platform kernel running on non-Tegra SoCs.
> diff --git a/include/linux/tegra-soc.h b/include/linux/tegra-soc.h
It might be better to create <linux/tegra-cpufreq.h> for the interface
to the cpufreq driver; tegra-soc.h is for the interface to core Tegra
code *from* other drivers.
> +#ifdef CONFIG_ARM_TEGRA_CPUFREQ
> +int tegra_cpufreq_init(void);
> +#else
> +static inline int tegra_cpufreq_init(void)
> +{
> + return -EINVAL;
> +}
> +#endif
Probably best to "return 0" from the !CONFIG_ARM_TEGRA_CPUFREQ case; the
whole point is to isolate callers from having to care whether
CONFIG_ARM_TEGRA_CPUFREQ is enabled, and making the function act like it
worked OK is part of that isolation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists