[PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Mark Brown]

Some header change has removed an implicit include of module.h, breaking
the build due to the use of THIS_MODULE. Fix that.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 drivers/cpufreq/s3c64xx-cpufreq.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c
index b8d1d20..3475f65 100644
--- a/drivers/cpufreq/s3c64xx-cpufreq.c
+++ b/drivers/cpufreq/s3c64xx-cpufreq.c
@@ -15,6 +15,7 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/regulator/consumer.h>
+#include <linux/module.h>
 
 static struct clk *armclk;
 static struct regulator *vddarm;
-- 
1.7.5.4

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Dave Jones]

On Fri, Jul 29, 2011 at 03:26:58PM +0100, Mark Brown wrote:
 > Some header change has removed an implicit include of module.h, breaking
 > the build due to the use of THIS_MODULE. Fix that.

is this dependant on the module.h changes that just got merged in -next
from Paul Gortmaker ?  If so, it should probably get merged as part of that set.

	Dave 

 > Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
 > ---
 >  drivers/cpufreq/s3c64xx-cpufreq.c |    1 +
 >  1 files changed, 1 insertions(+), 0 deletions(-)
 > 
 > diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c
 > index b8d1d20..3475f65 100644
 > --- a/drivers/cpufreq/s3c64xx-cpufreq.c
 > +++ b/drivers/cpufreq/s3c64xx-cpufreq.c
 > @@ -15,6 +15,7 @@
 >  #include <linux/clk.h>
 >  #include <linux/err.h>
 >  #include <linux/regulator/consumer.h>
 > +#include <linux/module.h>
 >  
 >  static struct clk *armclk;
 >  static struct regulator *vddarm;
 > -- 
 > 1.7.5.4

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Mark Brown]

On Fri, Jul 29, 2011 at 10:48:02AM -0400, Dave Jones wrote:
> On Fri, Jul 29, 2011 at 03:26:58PM +0100, Mark Brown wrote:
>  > Some header change has removed an implicit include of module.h, breaking
>  > the build due to the use of THIS_MODULE. Fix that.

> is this dependant on the module.h changes that just got merged in -next
> from Paul Gortmaker ?  If so, it should probably get merged as part of that set.

Possibly, but there were a bunch of other failures in the Samsung
specific stuff not related to module.h which appeared today. I did run
into another non-samsung module.h failure, though.  Mostly I was just
surprised stuff like this was showing up so late in the merge window, I
didn't spend a lot of time investigating what broke.

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Dave Jones]

On Fri, Jul 29, 2011 at 04:01:44PM +0100, Mark Brown wrote:
 > On Fri, Jul 29, 2011 at 10:48:02AM -0400, Dave Jones wrote:
 > > On Fri, Jul 29, 2011 at 03:26:58PM +0100, Mark Brown wrote:
 > >  > Some header change has removed an implicit include of module.h, breaking
 > >  > the build due to the use of THIS_MODULE. Fix that.
 > 
 > > is this dependant on the module.h changes that just got merged in -next
 > > from Paul Gortmaker ?  If so, it should probably get merged as part of that set.
 > 
 > Possibly, but there were a bunch of other failures in the Samsung
 > specific stuff not related to module.h which appeared today. I did run
 > into another non-samsung module.h failure, though.  Mostly I was just
 > surprised stuff like this was showing up so late in the merge window, I
 > didn't spend a lot of time investigating what broke.

wait, confused. Were you building Linus' tree, or -next ?

	Dave

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Mark Brown]

On Fri, Jul 29, 2011 at 11:08:51AM -0400, Dave Jones wrote:
> On Fri, Jul 29, 2011 at 04:01:44PM +0100, Mark Brown wrote:

>  > Possibly, but there were a bunch of other failures in the Samsung
>  > specific stuff not related to module.h which appeared today. I did run
>  > into another non-samsung module.h failure, though.  Mostly I was just
>  > surprised stuff like this was showing up so late in the merge window, I
>  > didn't spend a lot of time investigating what broke.

> wait, confused. Were you building Linus' tree, or -next ?

-next (given that the merge window is still open it should be emptying
out other than bug fixes...).

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Dave Jones]

On Fri, Jul 29, 2011 at 04:13:24PM +0100, Mark Brown wrote:
 > On Fri, Jul 29, 2011 at 11:08:51AM -0400, Dave Jones wrote:
 > > On Fri, Jul 29, 2011 at 04:01:44PM +0100, Mark Brown wrote:
 > 
 > >  > Possibly, but there were a bunch of other failures in the Samsung
 > >  > specific stuff not related to module.h which appeared today. I did run
 > >  > into another non-samsung module.h failure, though.  Mostly I was just
 > >  > surprised stuff like this was showing up so late in the merge window, I
 > >  > didn't spend a lot of time investigating what broke.
 > 
 > > wait, confused. Were you building Linus' tree, or -next ?
 > 
 > -next (given that the merge window is still open it should be emptying
 > out other than bug fixes...).

Ok, I'll let Stephen and/or Paul grab this one then.

	Dave

[PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Mark Brown]

Some header change has removed an implicit include of module.h, breaking
the build due to the use of THIS_MODULE. Fix that.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 drivers/cpufreq/s3c64xx-cpufreq.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c
index b8d1d20..3475f65 100644
--- a/drivers/cpufreq/s3c64xx-cpufreq.c
+++ b/drivers/cpufreq/s3c64xx-cpufreq.c
@@ -15,6 +15,7 @@
 #include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/regulator/consumer.h>
+#include <linux/module.h>
 
 static struct clk *armclk;
 static struct regulator *vddarm;
-- 
1.7.5.4

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Paul Gortmaker]

On 11-07-29 11:19 AM, Mark Brown wrote:
> Some header change has removed an implicit include of module.h, breaking
> the build due to the use of THIS_MODULE. Fix that.

Thanks, I'll apply it to the module.h cleanup branch that is soaking
in linux-next.

P.

> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>  drivers/cpufreq/s3c64xx-cpufreq.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c
> index b8d1d20..3475f65 100644
> --- a/drivers/cpufreq/s3c64xx-cpufreq.c
> +++ b/drivers/cpufreq/s3c64xx-cpufreq.c
> @@ -15,6 +15,7 @@
>  #include <linux/clk.h>
>  #include <linux/err.h>
>  #include <linux/regulator/consumer.h>
> +#include <linux/module.h>
>  
>  static struct clk *armclk;
>  static struct regulator *vddarm;

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Mark Brown]

On Sat, Jul 30, 2011 at 01:44:25PM -0400, Paul Gortmaker wrote:
> On 11-07-29 11:19 AM, Mark Brown wrote:

> > Some header change has removed an implicit include of module.h, breaking
> > the build due to the use of THIS_MODULE. Fix that.

> Thanks, I'll apply it to the module.h cleanup branch that is soaking
> in linux-next.

There's a bunch of other changes fixing issues with this floating around
- Randy Dunlap sent something for a regulator driver the other day and
I've got a couple of other Samsung patches I sent on the basis that this
must have been caused by a change in the Samsung headers.

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Paul Gortmaker]

[Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change] On 01/08/2011 (Mon 09:29) Mark Brown wrote:

> On Sat, Jul 30, 2011 at 01:44:25PM -0400, Paul Gortmaker wrote:
> > On 11-07-29 11:19 AM, Mark Brown wrote:
> 
> > > Some header change has removed an implicit include of module.h, breaking
> > > the build due to the use of THIS_MODULE. Fix that.
> 
> > Thanks, I'll apply it to the module.h cleanup branch that is soaking
> > in linux-next.
> 
> There's a bunch of other changes fixing issues with this floating around
> - Randy Dunlap sent something for a regulator driver the other day and
> I've got a couple of other Samsung patches I sent on the basis that this
> must have been caused by a change in the Samsung headers.

It is all taken care of, so you don't have to worry.  It isn't a change
specific to any Samsung headers.  If you are interested to know the
background of what is being changed and why, this is a good start.

https://lkml.org/lkml/2011/5/27/459

https://lkml.org/lkml/2011/7/28/12

Thanks,
Paul.

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Mark Brown]

On Tue, Aug 02, 2011 at 12:38:54AM -0400, Paul Gortmaker wrote:

> It is all taken care of, so you don't have to worry.  It isn't a change
> specific to any Samsung headers.  If you are interested to know the

I'm not worried, I'm now perfectly aware of the source of the breakage.
My goal is to make sure that you're aware that there are other patches
for this stuff that have been submitted separately which you're likely
to collide with if you're fixing these issues yourself.

Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change

[Paul Gortmaker]

[Re: [PATCH] cpufreq: Fix build of s3c64xx cpufreq driver for header change] On 03/08/2011 (Wed 14:35) Mark Brown wrote:

> On Tue, Aug 02, 2011 at 12:38:54AM -0400, Paul Gortmaker wrote:
> 
> > It is all taken care of, so you don't have to worry.  It isn't a change
> > specific to any Samsung headers.  If you are interested to know the
> 
> I'm not worried, I'm now perfectly aware of the source of the breakage.
> My goal is to make sure that you're aware that there are other patches
> for this stuff that have been submitted separately which you're likely
> to collide with if you're fixing these issues yourself.

As long as commits end up in Linus' tree directly or in one of the
queues that are a part of the linux-next infrastructure, we have good
visibility of any conflicts thanks to Stephen R's work with next.

Paul.