[PATCH] Fix problem with cpufreq_pndemand or cpufreq_conservative

[PATCH] Fix problem with cpufreq_pndemand or cpufreq_conservative

[Larry Finger]

Since commit 2aacdff entitled "cpufreq: Move common part from governors to 
separate file", whenever the drivers that depend on this new file 
(cpufreq_ondemand or cpufreq_conservative) are built as modules, a new module 
named cpufreq_governor is created. It seems that kmake is smart enough to create 
a separate module whenever more than one module includes the same object file. 
As drivers/cpufreq/cpufreq_governor.c contains no MODULE directives, the 
resulting module has no license specified, which results in logging of a "module 
license 'unspecified' taints kernel". In addition, a number of globals are 
exported GPL only, and are therefore not available.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---

This particular patch is the simplest possible; however, it hides the intent. I 
have prepared the longer version that makes the reason clearer by adding a new 
configuration variable that is dependent on the other two, and rearranges 
drivers/cpufreq/Makefile. That version could be submitted if that is what is 
desired. The changes to cpufreq_governor.c are the same as in this version.

Larry


       cpufreq_governor.c |    5 +++++
       1 file changed, 5 insertions(+)
---
Index: wireless-testing-new/drivers/cpufreq/cpufreq_governor.c
===================================================================
--- wireless-testing-new.orig/drivers/cpufreq/cpufreq_governor.c
+++ wireless-testing-new/drivers/cpufreq/cpufreq_governor.c
@@ -25,6 +25,7 @@
  #include <linux/tick.h>
  #include <linux/types.h>
  #include <linux/workqueue.h>
+#include <linux/module.h>

  #include "cpufreq_governor.h"

@@ -316,3 +317,7 @@ second_time:
  	return 0;
  }
  EXPORT_SYMBOL_GPL(cpufreq_governor_dbs);
+MODULE_AUTHOR("Alexander Clouter <alex@digriz.org.uk>");
+MODULE_DESCRIPTION("'cpufreq_governor' - A mini-module containing "
+		"common code for cpufreq_conservative and cpufreq_ondemand");
+MODULE_LICENSE("GPL");

Re: [PATCH] Fix problem with cpufreq_pndemand or cpufreq_conservative

[Rafael J. Wysocki]

On Friday, December 28, 2012 04:17:24 PM Larry Finger wrote:
> Since commit 2aacdff entitled "cpufreq: Move common part from governors to 
> separate file", whenever the drivers that depend on this new file 
> (cpufreq_ondemand or cpufreq_conservative) are built as modules, a new module 
> named cpufreq_governor is created. It seems that kmake is smart enough to create 
> a separate module whenever more than one module includes the same object file. 
> As drivers/cpufreq/cpufreq_governor.c contains no MODULE directives, the 
> resulting module has no license specified, which results in logging of a "module 
> license 'unspecified' taints kernel". In addition, a number of globals are 
> exported GPL only, and are therefore not available.
> 
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> 
> This particular patch is the simplest possible; however, it hides the intent. I 
> have prepared the longer version that makes the reason clearer by adding a new 
> configuration variable that is dependent on the other two, and rearranges 
> drivers/cpufreq/Makefile. That version could be submitted if that is what is 
> desired.

Yes, please.

> The changes to cpufreq_governor.c are the same as in this version.

I wonder if that's avoidable?  The intention is not to create an additional
module, clearly.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH] Fix problem with cpufreq_pndemand or cpufreq_conservative

[Larry Finger]

On 12/28/2012 05:01 PM, Rafael J. Wysocki wrote:
> On Friday, December 28, 2012 04:17:24 PM Larry Finger wrote:
>> Since commit 2aacdff entitled "cpufreq: Move common part from governors to
>> separate file", whenever the drivers that depend on this new file
>> (cpufreq_ondemand or cpufreq_conservative) are built as modules, a new module
>> named cpufreq_governor is created. It seems that kmake is smart enough to create
>> a separate module whenever more than one module includes the same object file.
>> As drivers/cpufreq/cpufreq_governor.c contains no MODULE directives, the
>> resulting module has no license specified, which results in logging of a "module
>> license 'unspecified' taints kernel". In addition, a number of globals are
>> exported GPL only, and are therefore not available.
>>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>>
>> This particular patch is the simplest possible; however, it hides the intent. I
>> have prepared the longer version that makes the reason clearer by adding a new
>> configuration variable that is dependent on the other two, and rearranges
>> drivers/cpufreq/Makefile. That version could be submitted if that is what is
>> desired.
>
> Yes, please.

I'll send it shortly.

>> The changes to cpufreq_governor.c are the same as in this version.
>
> I wonder if that's avoidable?  The intention is not to create an additional
> module, clearly.

It appears not to be possible. I don't know enough about to kmake to understand 
why it is forcing a new module. Perhaps some expert knows what Kconfig or 
Makefile magic will prevent that.

Larry

Re: [PATCH] Fix problem with cpufreq_pndemand or cpufreq_conservative

[Fabio Baltieri]

On Fri, Dec 28, 2012 at 05:45:54PM -0600, Larry Finger wrote:
> >I wonder if that's avoidable?  The intention is not to create an additional
> >module, clearly.
> 
> It appears not to be possible. I don't know enough about to kmake to
> understand why it is forcing a new module. Perhaps some expert knows
> what Kconfig or Makefile magic will prevent that.

kbuild is building an additional module just because the makefile is
adding the new objects in the obj-m list directly, as in:

obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)     += cpufreq_ondemand.o cpufreq_governor.o
obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative.o cpufreq_governor.o

To build just two modules the Makefile would have to be modified [1]
into something into something like:

obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)     += cpufreq_ondemand_mod.o
cpufreq_ondemand_mod-y                  := cpufreq_ondemand.o cpufreq_governor.o
obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative_mod.o
cpufreq_conservative_mod-y              := cpufreq_conservative.o cpufreq_governor.o

so that only two .o are added to obj-m, but that's not correct either as
you end up with cpufreq_governor symbols exported twice.

I think the only way would be to force cpufreq_governor as builtin with
an automatic Kconfig option.

Fabio

1. http://lxr.linux.no/#linux+v3.7.1/Documentation/kbuild/makefiles.txt#L191

-- 
Fabio Baltieri

Re: [PATCH] Fix problem with cpufreq_pndemand or cpufreq_conservative

[Larry Finger]

On 12/28/2012 06:33 PM, Fabio Baltieri wrote:
> On Fri, Dec 28, 2012 at 05:45:54PM -0600, Larry Finger wrote:
>>> I wonder if that's avoidable?  The intention is not to create an additional
>>> module, clearly.
>>
>> It appears not to be possible. I don't know enough about to kmake to
>> understand why it is forcing a new module. Perhaps some expert knows
>> what Kconfig or Makefile magic will prevent that.
>
> kbuild is building an additional module just because the makefile is
> adding the new objects in the obj-m list directly, as in:
>
> obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)     += cpufreq_ondemand.o cpufreq_governor.o
> obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative.o cpufreq_governor.o
>
> To build just two modules the Makefile would have to be modified [1]
> into something into something like:
>
> obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)     += cpufreq_ondemand_mod.o
> cpufreq_ondemand_mod-y                  := cpufreq_ondemand.o cpufreq_governor.o
> obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative_mod.o
> cpufreq_conservative_mod-y              := cpufreq_conservative.o cpufreq_governor.o
>
> so that only two .o are added to obj-m, but that's not correct either as
> you end up with cpufreq_governor symbols exported twice.
>
> I think the only way would be to force cpufreq_governor as builtin with
> an automatic Kconfig option.
>
> Fabio
>
> 1. http://lxr.linux.no/#linux+v3.7.1/Documentation/kbuild/makefiles.txt#L191

Fabio,

Thanks for the explanation. Now I think I know how to do it.

V3 follows.

Larry