Hi Dave,
After merging the cpufreq tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
drivers/cpufreq/Kconfig:67:warning: choice value used outside its choice group
drivers/cpufreq/Kconfig:75:warning: choice value used outside its choice group
drivers/cpufreq/Kconfig:84:warning: choice value used outside its choice group
drivers/cpufreq/Kconfig:93:warning: choice value used outside its choice group
drivers/cpufreq/Kconfig:105:warning: choice value used outside its choice group
I am not sure what has caused this. The only change in the cpufreq tree
to that file is commit e002ba3328a2 ("[CPUFREQ] Move x86 cpufreq drivers
to drivers/cpufreq/") which rearranged a few things but nothing obvious.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Wed, Apr 27, 2011 at 11:10:24AM +1000, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the cpufreq tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> drivers/cpufreq/Kconfig:67:warning: choice value used outside its choice group
> drivers/cpufreq/Kconfig:75:warning: choice value used outside its choice group
> drivers/cpufreq/Kconfig:84:warning: choice value used outside its choice group
> drivers/cpufreq/Kconfig:93:warning: choice value used outside its choice group
> drivers/cpufreq/Kconfig:105:warning: choice value used outside its choice group
>
> I am not sure what has caused this. The only change in the cpufreq tree
> to that file is commit e002ba3328a2 ("[CPUFREQ] Move x86 cpufreq drivers
> to drivers/cpufreq/") which rearranged a few things but nothing obvious.
As the commit message suggests, per-arch cpufreq drivers are moving to drivers/cpufreq/
So far, I've only moved the x86 ones. As a side-effect of this, the
source "drivers/cpufreq/Kconfig" is no longer a per-arch thing, as it now gets
included from kernel/power/Kconfig.
I suspect the warnings are happening because on the unconverted archs, drivers/cpufreq/Kconfig
is now getting included twice. If you kill the 'source' line in kernel/power/Kconfig,
does this make things go back to normal ? (Check that cpufreq still shows up in
the resulting config afterwards)
If so, I'll make that change after all archs have moved their drivers.
Dave
Hi Dave,
On Tue, 26 Apr 2011 21:32:17 -0400 Dave Jones <[email protected]> wrote:
>
> As the commit message suggests, per-arch cpufreq drivers are moving to drivers/cpufreq/
> So far, I've only moved the x86 ones. As a side-effect of this, the
> source "drivers/cpufreq/Kconfig" is no longer a per-arch thing, as it now gets
> included from kernel/power/Kconfig.
>
> I suspect the warnings are happening because on the unconverted archs, drivers/cpufreq/Kconfig
> is now getting included twice. If you kill the 'source' line in kernel/power/Kconfig,
> does this make things go back to normal ? (Check that cpufreq still shows up in
> the resulting config afterwards)
Removing the source line in kernel/power/Kconfig makes the warnings go
away and the only change in the generated config file is this:
@@ -465,10 +465,6 @@
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
-
-#
-# CPU Frequency scaling
-#
CONFIG_SECCOMP=y
CONFIG_ISA_DMA_API=y
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Wed, Apr 27, 2011 at 11:54:27AM +1000, Stephen Rothwell wrote:
> Removing the source line in kernel/power/Kconfig makes the warnings go
> away and the only change in the generated config file is this:
>
> @@ -465,10 +465,6 @@
> # CONFIG_PM_RUNTIME is not set
> CONFIG_PM=y
> # CONFIG_PM_DEBUG is not set
> -
> -#
> -# CPU Frequency scaling
> -#
> CONFIG_SECCOMP=y
> CONFIG_ISA_DMA_API=y
Ok, thanks for testing. I'll fix something up.
Dave
On Wed, Apr 27, 2011 at 11:54:27AM +1000, Stephen Rothwell wrote:
> Hi Dave,
>
> On Tue, 26 Apr 2011 21:32:17 -0400 Dave Jones <[email protected]> wrote:
> >
> > As the commit message suggests, per-arch cpufreq drivers are moving to drivers/cpufreq/
> > So far, I've only moved the x86 ones. As a side-effect of this, the
> > source "drivers/cpufreq/Kconfig" is no longer a per-arch thing, as it now gets
> > included from kernel/power/Kconfig.
> >
> > I suspect the warnings are happening because on the unconverted archs, drivers/cpufreq/Kconfig
> > is now getting included twice. If you kill the 'source' line in kernel/power/Kconfig,
> > does this make things go back to normal ? (Check that cpufreq still shows up in
> > the resulting config afterwards)
>
> Removing the source line in kernel/power/Kconfig makes the warnings go
> away and the only change in the generated config file is this:
I've moved this work onto a separate move-drivers branch. Could you track that in next too please?
(Apply after fixes & next)
I'm hoping this branch will be fairly short-lived, but it depends how quickly
other architecture maintainers move their drivers over too.
thanks,
Dave
Hi Dave,
On Fri, 29 Apr 2011 16:12:42 -0400 Dave Jones <[email protected]> wrote:
>
> I've moved this work onto a separate move-drivers branch. Could you track that in next too please?
> (Apply after fixes & next)
>
> I'm hoping this branch will be fairly short-lived, but it depends how quickly
> other architecture maintainers move their drivers over too.
I have added that new branch starting today. I called it cpufreq-move.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
[email protected]
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.