subject:"kernel compile"

On Tue, Dec 31, 2013 at 10:01 -0800, Randy Dunlap wrote:
> 
> On 12/31/13 05:48, Gerhard Sittig wrote:
> > On Tue, Dec 31, 2013 at 11:51 +0100, Krzysztof Hałasa wrote:
> >>
> >> drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
> >> drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use 
> >> in this function)
> >>
> >> Now builds. Not tested on real hw.
> >>
> >> Signed-off-by: Krzysztof Hałasa 
> > 
> > I understood that a 'Fixes:  ' line is suggested when
> > you can clearly identify what broke what you fix.  Is it 27c1789ca6a6
> > "DMA-API: crypto: remove last references to 'static struct device *dev'"?
> > Then v3.13-rc1 would have been affected.
>  
> is 'Fixes: ' documented somewhere?

Last time I checked (few days ago, 'git grep -w Fixes:') it
wasn't, at least not within the kernel source tree and its
Documentation hierarchy.  Today's master still does not have it.

But a quick search in recent LAKML messages reveals that it's
been in use by e.g. Olof Johansson, Jason Cooper, Rusty Russell,
Dan Carpenter, Russell King, Mark Brown, Stephen Warren, Paul
Walmsley, and I'm not making this up but am just referring to
what repeatedly was requested in the past.  The form used there
was "Fixes:  ()" though.  A doc update may be due
to have a canonical format.

I do see the benefit of this tag, as it does not hide this
information in the commit message's prose, makes submitters think
about that property in more explicit ways and makes them provide
the information such that others need not do the research, and
greatly helps those involved in tests and release management to
determine affected versions and required actions that need to be
taken.  The tag is very useful.

virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

On Tue, Dec 31, 2013 at 18:14 +, Russell King - ARM Linux wrote:
> 
> Please get rid of your Mail-Followup-To: header:
> 
> Mail-Followup-To: Krzysztof Hałasa , 
>   
> lkml ,  
>   
> linux-arm-ker...@lists.infradead.org, 
>   
> Russell King ,   
>   
> Christian Hohnstaedt ,
>   
> Herbert Xu   
>   
> User-Agent: Mutt/1.5.21 (2010-09-15)  
>   
> 
> It causes all recipients following the thread to be moved into the To:
> header when someone replies to one of your messages, which is deemed to
> be anti-social.  You can kill this header by adding:
> 
>   set followup_to=no
> 
> to your .muttrc file.

Thank you for telling me, I was not aware.  Had no MFT related
setting in my config, learned from the manual that $followup_to
defaults to yes, have turned it off now.  Other mutt users may
want to check as well.  Happy new year! :)


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

On Tue, Dec 31, 2013 at 18:14 +, Russell King - ARM Linux wrote:
 
 Please get rid of your Mail-Followup-To: header:
 
 Mail-Followup-To: Krzysztof Hałasa khal...@piap.pl, 
   
 lkml linux-kernel@vger.kernel.org,  
   
 linux-arm-ker...@lists.infradead.org, 
   
 Russell King rmk+ker...@arm.linux.org.uk,   
   
 Christian Hohnstaedt chohnsta...@innominate.com,
   
 Herbert Xu herb...@gondor.apana.org.au  
   
 User-Agent: Mutt/1.5.21 (2010-09-15)  
   
 
 It causes all recipients following the thread to be moved into the To:
 header when someone replies to one of your messages, which is deemed to
 be anti-social.  You can kill this header by adding:
 
   set followup_to=no
 
 to your .muttrc file.

Thank you for telling me, I was not aware.  Had no MFT related
setting in my config, learned from the manual that $followup_to
defaults to yes, have turned it off now.  Other mutt users may
want to check as well.  Happy new year! :)


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

On Tue, Dec 31, 2013 at 10:01 -0800, Randy Dunlap wrote:
 
 On 12/31/13 05:48, Gerhard Sittig wrote:
  On Tue, Dec 31, 2013 at 11:51 +0100, Krzysztof Hałasa wrote:
 
  drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
  drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use 
  in this function)
 
  Now builds. Not tested on real hw.
 
  Signed-off-by: Krzysztof Hałasa khal...@piap.pl
  
  I understood that a 'Fixes: hash subject' line is suggested when
  you can clearly identify what broke what you fix.  Is it 27c1789ca6a6
  DMA-API: crypto: remove last references to 'static struct device *dev'?
  Then v3.13-rc1 would have been affected.
  
 is 'Fixes: whatever' documented somewhere?

Last time I checked (few days ago, 'git grep -w Fixes:') it
wasn't, at least not within the kernel source tree and its
Documentation hierarchy.  Today's master still does not have it.

But a quick search in recent LAKML messages reveals that it's
been in use by e.g. Olof Johansson, Jason Cooper, Rusty Russell,
Dan Carpenter, Russell King, Mark Brown, Stephen Warren, Paul
Walmsley, and I'm not making this up but am just referring to
what repeatedly was requested in the past.  The form used there
was Fixes: hash (oneline) though.  A doc update may be due
to have a canonical format.

I do see the benefit of this tag, as it does not hide this
information in the commit message's prose, makes submitters think
about that property in more explicit ways and makes them provide
the information such that others need not do the research, and
greatly helps those involved in tests and release management to
determine affected versions and required actions that need to be
taken.  The tag is very useful.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2014-01-01 Thread Russell King - ARM Linux

On Wed, Jan 01, 2014 at 01:37:46PM +0100, Gerhard Sittig wrote:
 Last time I checked (few days ago, 'git grep -w Fixes:') it
 wasn't, at least not within the kernel source tree and its
 Documentation hierarchy.  Today's master still does not have it.
 
 But a quick search in recent LAKML messages reveals that it's
 been in use by e.g. Olof Johansson, Jason Cooper, Rusty Russell,
 Dan Carpenter, Russell King, Mark Brown, Stephen Warren, Paul
 Walmsley, and I'm not making this up but am just referring to
 what repeatedly was requested in the past.  The form used there
 was Fixes: hash (oneline) though.  A doc update may be due
 to have a canonical format.

It was discussed at kernel summit, and I believe the resulting format
was only published in one of the kernel summit mailing lists.  The
outcome of it as I understand was that the format is:

Fixes: hash (one line summary)

Though the addition of the quotes was (iirc) only something added after
the vocal discussion.  If you mail Linus a patch with a fixes line which
doesn't match that, Linus will probably fix it up... (Linus has done that
with one of mine in the past.)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2014-01-01 Thread Jason Cooper

On Wed, Jan 01, 2014 at 12:46:25PM +, Russell King - ARM Linux wrote:
 On Wed, Jan 01, 2014 at 01:37:46PM +0100, Gerhard Sittig wrote:
  Last time I checked (few days ago, 'git grep -w Fixes:') it
  wasn't, at least not within the kernel source tree and its
  Documentation hierarchy.  Today's master still does not have it.
  
  But a quick search in recent LAKML messages reveals that it's
  been in use by e.g. Olof Johansson, Jason Cooper, Rusty Russell,
  Dan Carpenter, Russell King, Mark Brown, Stephen Warren, Paul
  Walmsley, and I'm not making this up but am just referring to
  what repeatedly was requested in the past.  The form used there
  was Fixes: hash (oneline) though.  A doc update may be due
  to have a canonical format.
 
 It was discussed at kernel summit, and I believe the resulting format
 was only published in one of the kernel summit mailing lists.  The
 outcome of it as I understand was that the format is:
 
 Fixes: hash (one line summary)

fwiw, Linus also recommended setting core.abbrev = 12.

thx,

Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2013-12-31 Thread Herbert Xu

On Tue, Dec 31, 2013 at 11:51:16AM +0100, Krzysztof Hałasa wrote:
> drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
> drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in 
> this function)
> 
> Now builds. Not tested on real hw.
> 
> Signed-off-by: Krzysztof Hałasa 

Patch applied.  Thanks!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2013-12-31 Thread Russell King - ARM Linux

Please get rid of your Mail-Followup-To: header:

Mail-Followup-To: Krzysztof Hałasa ,   
lkml ,
linux-arm-ker...@lists.infradead.org,   
Russell King , 
Christian Hohnstaedt ,  
Herbert Xu 
User-Agent: Mutt/1.5.21 (2010-09-15)

It causes all recipients following the thread to be moved into the To:
header when someone replies to one of your messages, which is deemed to
be anti-social.  You can kill this header by adding:

set followup_to=no

to your .muttrc file.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2013-12-31 Thread Randy Dunlap

On 12/31/13 05:48, Gerhard Sittig wrote:
> On Tue, Dec 31, 2013 at 11:51 +0100, Krzysztof Hałasa wrote:
>>
>> drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
>> drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in 
>> this function)
>>
>> Now builds. Not tested on real hw.
>>
>> Signed-off-by: Krzysztof Hałasa 
> 
> I understood that a 'Fixes:  ' line is suggested when
> you can clearly identify what broke what you fix.  Is it 27c1789ca6a6
> "DMA-API: crypto: remove last references to 'static struct device *dev'"?
> Then v3.13-rc1 would have been affected.
 
is 'Fixes: ' documented somewhere?

thanks,
-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2013-12-31 Thread Gerhard Sittig

On Tue, Dec 31, 2013 at 11:51 +0100, Krzysztof Hałasa wrote:
> 
> drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
> drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in 
> this function)
> 
> Now builds. Not tested on real hw.
> 
> Signed-off-by: Krzysztof Hałasa 

I understood that a 'Fixes:  ' line is suggested when
you can clearly identify what broke what you fix.  Is it 27c1789ca6a6
"DMA-API: crypto: remove last references to 'static struct device *dev'"?
Then v3.13-rc1 would have been affected.

> --- a/drivers/crypto/ixp4xx_crypto.c
> +++ b/drivers/crypto/ixp4xx_crypto.c
> @@ -1410,14 +1410,12 @@ static const struct platform_device_info ixp_dev_info 
> __initdata = {
>  static int __init ixp_module_init(void)
>  {
>   int num = ARRAY_SIZE(ixp4xx_algos);
> - int i, err ;
> + int i, err;
>  
>   pdev = platform_device_register_full(_dev_info);
>   if (IS_ERR(pdev))
>   return PTR_ERR(pdev);
>  
> - dev = >dev;
> -
>   spin_lock_init(_lock);
>   spin_lock_init(_lock);


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2013-12-31 Thread Krzysztof Hałasa

drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in 
this function)

Now builds. Not tested on real hw.

Signed-off-by: Krzysztof Hałasa 

--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -1410,14 +1410,12 @@ static const struct platform_device_info ixp_dev_info 
__initdata = {
 static int __init ixp_module_init(void)
 {
int num = ARRAY_SIZE(ixp4xx_algos);
-   int i, err ;
+   int i, err;
 
pdev = platform_device_register_full(_dev_info);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
 
-   dev = >dev;
-
spin_lock_init(_lock);
spin_lock_init(_lock);
 

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2013-12-31 Thread Krzysztof Hałasa

drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in 
this function)

Now builds. Not tested on real hw.

Signed-off-by: Krzysztof Hałasa khal...@piap.pl

--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -1410,14 +1410,12 @@ static const struct platform_device_info ixp_dev_info 
__initdata = {
 static int __init ixp_module_init(void)
 {
int num = ARRAY_SIZE(ixp4xx_algos);
-   int i, err ;
+   int i, err;
 
pdev = platform_device_register_full(ixp_dev_info);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
 
-   dev = pdev-dev;
-
spin_lock_init(desc_lock);
spin_lock_init(emerg_lock);
 

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2013-12-31 Thread Gerhard Sittig

On Tue, Dec 31, 2013 at 11:51 +0100, Krzysztof Hałasa wrote:
 
 drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
 drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in 
 this function)
 
 Now builds. Not tested on real hw.
 
 Signed-off-by: Krzysztof Hałasa khal...@piap.pl

I understood that a 'Fixes: hash subject' line is suggested when
you can clearly identify what broke what you fix.  Is it 27c1789ca6a6
DMA-API: crypto: remove last references to 'static struct device *dev'?
Then v3.13-rc1 would have been affected.

 --- a/drivers/crypto/ixp4xx_crypto.c
 +++ b/drivers/crypto/ixp4xx_crypto.c
 @@ -1410,14 +1410,12 @@ static const struct platform_device_info ixp_dev_info 
 __initdata = {
  static int __init ixp_module_init(void)
  {
   int num = ARRAY_SIZE(ixp4xx_algos);
 - int i, err ;
 + int i, err;
  
   pdev = platform_device_register_full(ixp_dev_info);
   if (IS_ERR(pdev))
   return PTR_ERR(pdev);
  
 - dev = pdev-dev;
 -
   spin_lock_init(desc_lock);
   spin_lock_init(emerg_lock);


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2013-12-31 Thread Randy Dunlap

On 12/31/13 05:48, Gerhard Sittig wrote:
 On Tue, Dec 31, 2013 at 11:51 +0100, Krzysztof Hałasa wrote:

 drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
 drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in 
 this function)

 Now builds. Not tested on real hw.

 Signed-off-by: Krzysztof Hałasa khal...@piap.pl
 
 I understood that a 'Fixes: hash subject' line is suggested when
 you can clearly identify what broke what you fix.  Is it 27c1789ca6a6
 DMA-API: crypto: remove last references to 'static struct device *dev'?
 Then v3.13-rc1 would have been affected.
 
is 'Fixes: whatever' documented somewhere?

thanks,
-- 
~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2013-12-31 Thread Russell King - ARM Linux

Please get rid of your Mail-Followup-To: header:

Mail-Followup-To: Krzysztof Hałasa khal...@piap.pl,   
lkml linux-kernel@vger.kernel.org,
linux-arm-ker...@lists.infradead.org,   
Russell King rmk+ker...@arm.linux.org.uk, 
Christian Hohnstaedt chohnsta...@innominate.com,  
Herbert Xu herb...@gondor.apana.org.au
User-Agent: Mutt/1.5.21 (2010-09-15)

It causes all recipients following the thread to be moved into the To:
header when someone replies to one of your messages, which is deemed to
be anti-social.  You can kill this header by adding:

set followup_to=no

to your .muttrc file.

Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

2013-12-31 Thread Herbert Xu

On Tue, Dec 31, 2013 at 11:51:16AM +0100, Krzysztof Hałasa wrote:
 drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init':
 drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in 
 this function)
 
 Now builds. Not tested on real hw.
 
 Signed-off-by: Krzysztof Hałasa khal...@piap.pl

Patch applied.  Thanks!
-- 
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mips/ftrace: Fix kernel compile error

2013-01-25 Thread Steven Rostedt

While compiling for my yeeloong2 laptop, I hit this compile error.

As warnings are set for errors, if we define ftrace_modify_code_2(), we
must use it. As MIPS 64 does not use this function, it requires being
commented out via an #ifndef CONFIG_64bit. Otherwise you get this error:

  CC  arch/mips/kernel/ftrace.o
cc1: warnings being treated as errors
/work/autotest/nobackup/mips-test.git/arch/mips/kernel/ftrace.c:98:12:
error: 'ftrace_modify_code_2' defined but not used
make[3]: *** [arch/mips/kernel/ftrace.o] Error 1
make[2]: *** [arch/mips/kernel] Error 2
make[2]: *** Waiting for unfinished jobs
make[1]: *** [arch/mips] Error 2
make[1]: *** Waiting for unfinished jobs


Cc: Al Cooper 
Cc: David Daney 
Signed-off-by: Steven Rostedt 

diff --git a/arch/mips/kernel/ftrace.c b/arch/mips/kernel/ftrace.c
index 6bcb678..83fa146 100644
--- a/arch/mips/kernel/ftrace.c
+++ b/arch/mips/kernel/ftrace.c
@@ -95,6 +95,7 @@ static int ftrace_modify_code(unsigned long ip, unsigned int 
new_code)
return 0;
 }
 
+#ifndef CONFIG_64BIT
 static int ftrace_modify_code_2(unsigned long ip, unsigned int new_code1,
unsigned int new_code2)
 {
@@ -110,6 +111,7 @@ static int ftrace_modify_code_2(unsigned long ip, unsigned 
int new_code1,
flush_icache_range(ip, ip + 8); /* original ip + 12 */
return 0;
 }
+#endif
 
 /*
  * The details about the calling site of mcount on MIPS


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mips/ftrace: Fix kernel compile error

2013-01-25 Thread Steven Rostedt

While compiling for my yeeloong2 laptop, I hit this compile error.

As warnings are set for errors, if we define ftrace_modify_code_2(), we
must use it. As MIPS 64 does not use this function, it requires being
commented out via an #ifndef CONFIG_64bit. Otherwise you get this error:

  CC  arch/mips/kernel/ftrace.o
cc1: warnings being treated as errors
/work/autotest/nobackup/mips-test.git/arch/mips/kernel/ftrace.c:98:12:
error: 'ftrace_modify_code_2' defined but not used
make[3]: *** [arch/mips/kernel/ftrace.o] Error 1
make[2]: *** [arch/mips/kernel] Error 2
make[2]: *** Waiting for unfinished jobs
make[1]: *** [arch/mips] Error 2
make[1]: *** Waiting for unfinished jobs


Cc: Al Cooper alcoop...@gmail.com
Cc: David Daney ddaney@gmail.com
Signed-off-by: Steven Rostedt rost...@goodmis.org

diff --git a/arch/mips/kernel/ftrace.c b/arch/mips/kernel/ftrace.c
index 6bcb678..83fa146 100644
--- a/arch/mips/kernel/ftrace.c
+++ b/arch/mips/kernel/ftrace.c
@@ -95,6 +95,7 @@ static int ftrace_modify_code(unsigned long ip, unsigned int 
new_code)
return 0;
 }
 
+#ifndef CONFIG_64BIT
 static int ftrace_modify_code_2(unsigned long ip, unsigned int new_code1,
unsigned int new_code2)
 {
@@ -110,6 +111,7 @@ static int ftrace_modify_code_2(unsigned long ip, unsigned 
int new_code1,
flush_icache_range(ip, ip + 8); /* original ip + 12 */
return 0;
 }
+#endif
 
 /*
  * The details about the calling site of mcount on MIPS


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

2007-10-22 Thread Daniel Walker

On Wed, 2007-10-17 at 11:34 -0400, Steven Rostedt wrote:

> 
> Hmm, what about a __seq_irqsave_raw and __seq_nop?
> 
> That way it spells out that irqs are NOT touched if it is not a raw lock.

I took out the nop , and just did a save flags which makes sense.. There
is still more cleanup to do in that regard.

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 include/linux/seqlock.h |   26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

Index: linux-2.6.23/include/linux/seqlock.h
===
--- linux-2.6.23.orig/include/linux/seqlock.h
+++ linux-2.6.23/include/linux/seqlock.h
@@ -92,8 +92,11 @@ static inline void __write_seqlock(seqlo
 
 static __always_inline unsigned long __write_seqlock_irqsave(seqlock_t *sl)
 {
+   unsigned long flags;
+
+   local_save_flags(flags);
__write_seqlock(sl);
-   return 0;
+   return flags;
 }
 
 static inline void __write_sequnlock(seqlock_t *sl)
@@ -280,26 +283,27 @@ do {  
\
PICK_SEQ_OP(__write_sequnlock_irq_raw, __write_sequnlock, lock)
 
 static __always_inline
-unsigned long __read_seqbegin_irqsave_raw(raw_seqlock_t *sl)
+unsigned long __seq_irqsave_raw(raw_seqlock_t *sl)
 {
unsigned long flags;
 
local_irq_save(flags);
-   __read_seqbegin_raw(sl);
return flags;
 }
 
-static __always_inline unsigned long __read_seqbegin_irqsave(seqlock_t *sl)
+static __always_inline unsigned long __seq_irqsave(seqlock_t *sl)
 {
-   __read_seqbegin(sl);
-   return 0;
+   unsigned long flags;
+
+   local_save_flags(flags);
+   return flags;
 }
 
-#define read_seqbegin_irqsave(lock, flags) \
-do {   \
-   flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
-   __read_seqbegin_irqsave, lock); \
-} while (0)
+#define read_seqbegin_irqsave(lock, flags) \
+({ \
+   flags = PICK_SEQ_OP_RET(__seq_irqsave_raw, __seq_irqsave, lock);\
+   read_seqbegin(lock);\
+})
 
 static __always_inline int
 __read_seqretry_irqrestore(seqlock_t *sl, unsigned iv, unsigned long flags)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

2007-10-22 Thread Daniel Walker

On Wed, 2007-10-17 at 11:34 -0400, Steven Rostedt wrote:

 
 Hmm, what about a __seq_irqsave_raw and __seq_nop?
 
 That way it spells out that irqs are NOT touched if it is not a raw lock.

I took out the nop , and just did a save flags which makes sense.. There
is still more cleanup to do in that regard.

Signed-off-by: Daniel Walker [EMAIL PROTECTED]

---
 include/linux/seqlock.h |   26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

Index: linux-2.6.23/include/linux/seqlock.h
===
--- linux-2.6.23.orig/include/linux/seqlock.h
+++ linux-2.6.23/include/linux/seqlock.h
@@ -92,8 +92,11 @@ static inline void __write_seqlock(seqlo
 
 static __always_inline unsigned long __write_seqlock_irqsave(seqlock_t *sl)
 {
+   unsigned long flags;
+
+   local_save_flags(flags);
__write_seqlock(sl);
-   return 0;
+   return flags;
 }
 
 static inline void __write_sequnlock(seqlock_t *sl)
@@ -280,26 +283,27 @@ do {  
\
PICK_SEQ_OP(__write_sequnlock_irq_raw, __write_sequnlock, lock)
 
 static __always_inline
-unsigned long __read_seqbegin_irqsave_raw(raw_seqlock_t *sl)
+unsigned long __seq_irqsave_raw(raw_seqlock_t *sl)
 {
unsigned long flags;
 
local_irq_save(flags);
-   __read_seqbegin_raw(sl);
return flags;
 }
 
-static __always_inline unsigned long __read_seqbegin_irqsave(seqlock_t *sl)
+static __always_inline unsigned long __seq_irqsave(seqlock_t *sl)
 {
-   __read_seqbegin(sl);
-   return 0;
+   unsigned long flags;
+
+   local_save_flags(flags);
+   return flags;
 }
 
-#define read_seqbegin_irqsave(lock, flags) \
-do {   \
-   flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
-   __read_seqbegin_irqsave, lock); \
-} while (0)
+#define read_seqbegin_irqsave(lock, flags) \
+({ \
+   flags = PICK_SEQ_OP_RET(__seq_irqsave_raw, __seq_irqsave, lock);\
+   read_seqbegin(lock);\
+})
 
 static __always_inline int
 __read_seqretry_irqrestore(seqlock_t *sl, unsigned iv, unsigned long flags)


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set


--

On Wed, 17 Oct 2007, Daniel Walker wrote:

> On Wed, 2007-10-17 at 11:10 -0400, Steven Rostedt wrote:
>
> > > >
> > > >  #define read_seqbegin_irqsave(lock, flags) \
> > > > -do {   \
> > > > +({ \
> > > > flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
> > > > __read_seqbegin_irqsave, lock); \
> > > > -} while (0)
> > > > +   read_seqbegin(lock);\
> > > > +})
> >
> > Yes, definitely the raw and unraw functions should be called
> > local_irqsave_raw or something else that makes this obvious to what it
> > is doing.
>
> Hmm.. I'm not sure what else to name them .. Since it's in the seqlock.h
> I don't think it should be called anything "local_irq*" .. It could be
> seq_irqsave_{raw} .

Hmm, what about a __seq_irqsave_raw and __seq_nop?

That way it spells out that irqs are NOT touched if it is not a raw lock.

-- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

2007-10-17 Thread Daniel Walker

On Wed, 2007-10-17 at 11:10 -0400, Steven Rostedt wrote:

> > >  
> > >  #define read_seqbegin_irqsave(lock, flags)   \
> > > -do { \
> > > +({   \
> > >   flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
> > >   __read_seqbegin_irqsave, lock); \
> > > -} while (0)
> > > + read_seqbegin(lock);\
> > > +})
> 
> Yes, definitely the raw and unraw functions should be called
> local_irqsave_raw or something else that makes this obvious to what it
> is doing.

Hmm.. I'm not sure what else to name them .. Since it's in the seqlock.h
I don't think it should be called anything "local_irq*" .. It could be
seq_irqsave_{raw} . 

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

On Wed, 2007-10-17 at 07:48 -0700, Daniel Walker wrote:
> Steven, 
> 
> Could you include this patch, it was submitted on the list but you
> didn't get CC'd ..

Thanks, it may have been a while before I see this (/me has been nose
deep in debugging).

> > On Tue, 2007-10-16 at 10:35 +0200, Remy Bohmer wrote:
> > > Hello Daniel and Ingo,
> > > 
> > > I use 2.6.23-rt1 and the patch of Daniel below which seems to be in
> > > there breaks the compilation of the RT-kernel when CONFIG_GENERIC_TIME
> > > is NOT set.
> > > 
> > > It breaks in the do_gettimeofday(struct timeval *tv) code in the
> > > architecture specific code
> > > where there is a call to: seq = read_seqbegin_irqsave(_lock, flags);
> > > The PICK_FUNCTION implementation does not return anything, so the
> > > compile breaks here.
> > > 
> > > I am figuring out how to solve this problem nicely, but I have not
> > > found a nice solution yet. Attached I have put my hack to make it
> > > compile on ARM again, but maybe one of you can do a better proposal to
> > > fix this.
> > 
> > Here's another fix for this. I compile tested for ARM (!GENERIC_TIME) ,
> > but I didn't boot test .. Could you boot test this patch?
> > 
> > ---
> > 
> > Move the read_seqbegin() call up in the chain so the value 
> > can be returned
> > 
> > Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
> > 
> > ---
> >  include/linux/seqlock.h |7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > Index: linux-2.6.23/include/linux/seqlock.h
> > ===
> > --- linux-2.6.23.orig/include/linux/seqlock.h
> > +++ linux-2.6.23/include/linux/seqlock.h
> > @@ -285,21 +285,20 @@ unsigned long __read_seqbegin_irqsave_ra
> > unsigned long flags;
> >  
> > local_irq_save(flags);
> > -   __read_seqbegin_raw(sl);
> > return flags;
> >  }
> >  
> >  static __always_inline unsigned long __read_seqbegin_irqsave(seqlock_t *sl)
> >  {
> > -   __read_seqbegin(sl);
> > return 0;
> >  }

The above should be renamed. They have nothing to do with seqlocks now.

> >  
> >  #define read_seqbegin_irqsave(lock, flags) \
> > -do {   \
> > +({ \
> > flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
> > __read_seqbegin_irqsave, lock); \
> > -} while (0)
> > +   read_seqbegin(lock);\
> > +})

Yes, definitely the raw and unraw functions should be called
local_irqsave_raw or something else that makes this obvious to what it
is doing.

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

2007-10-17 Thread Remy Bohmer

Hello Daniel,

> Here's another fix for this. I compile tested for ARM (!GENERIC_TIME) ,
> but I didn't boot test .. Could you boot test this patch?

This fix seems to work! The target still boots properly. So, it can be
pushed upstream... :-)

Kind Regards,

Remy Bohmer

2007/10/16, Daniel Walker <[EMAIL PROTECTED]>:
> On Tue, 2007-10-16 at 10:35 +0200, Remy Bohmer wrote:
> > Hello Daniel and Ingo,
> >
> > I use 2.6.23-rt1 and the patch of Daniel below which seems to be in
> > there breaks the compilation of the RT-kernel when CONFIG_GENERIC_TIME
> > is NOT set.
> >
> > It breaks in the do_gettimeofday(struct timeval *tv) code in the
> > architecture specific code
> > where there is a call to: seq = read_seqbegin_irqsave(_lock, flags);
> > The PICK_FUNCTION implementation does not return anything, so the
> > compile breaks here.
> >
> > I am figuring out how to solve this problem nicely, but I have not
> > found a nice solution yet. Attached I have put my hack to make it
> > compile on ARM again, but maybe one of you can do a better proposal to
> > fix this.
>
> Here's another fix for this. I compile tested for ARM (!GENERIC_TIME) ,
> but I didn't boot test .. Could you boot test this patch?
>
> ---
>
> Move the read_seqbegin() call up in the chain so the value
> can be returned
>
> Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
>
> ---
>  include/linux/seqlock.h |7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> Index: linux-2.6.23/include/linux/seqlock.h
> ===
> --- linux-2.6.23.orig/include/linux/seqlock.h
> +++ linux-2.6.23/include/linux/seqlock.h
> @@ -285,21 +285,20 @@ unsigned long __read_seqbegin_irqsave_ra
> unsigned long flags;
>
> local_irq_save(flags);
> -   __read_seqbegin_raw(sl);
> return flags;
>  }
>
>  static __always_inline unsigned long __read_seqbegin_irqsave(seqlock_t *sl)
>  {
> -   __read_seqbegin(sl);
> return 0;
>  }
>
>  #define read_seqbegin_irqsave(lock, flags) \
> -do {   \
> +({ \
> flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
> __read_seqbegin_irqsave, lock); \
> -} while (0)
> +   read_seqbegin(lock);\
> +})
>
>  static __always_inline int
>  __read_seqretry_irqrestore(seqlock_t *sl, unsigned iv, unsigned long flags)
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

2007-10-17 Thread Remy Bohmer

Hello Daniel,

 Here's another fix for this. I compile tested for ARM (!GENERIC_TIME) ,
 but I didn't boot test .. Could you boot test this patch?

This fix seems to work! The target still boots properly. So, it can be
pushed upstream... :-)

Kind Regards,

Remy Bohmer

2007/10/16, Daniel Walker [EMAIL PROTECTED]:
 On Tue, 2007-10-16 at 10:35 +0200, Remy Bohmer wrote:
  Hello Daniel and Ingo,
 
  I use 2.6.23-rt1 and the patch of Daniel below which seems to be in
  there breaks the compilation of the RT-kernel when CONFIG_GENERIC_TIME
  is NOT set.
 
  It breaks in the do_gettimeofday(struct timeval *tv) code in the
  architecture specific code
  where there is a call to: seq = read_seqbegin_irqsave(xtime_lock, flags);
  The PICK_FUNCTION implementation does not return anything, so the
  compile breaks here.
 
  I am figuring out how to solve this problem nicely, but I have not
  found a nice solution yet. Attached I have put my hack to make it
  compile on ARM again, but maybe one of you can do a better proposal to
  fix this.

 Here's another fix for this. I compile tested for ARM (!GENERIC_TIME) ,
 but I didn't boot test .. Could you boot test this patch?

 ---

 Move the read_seqbegin() call up in the chain so the value
 can be returned

 Signed-off-by: Daniel Walker [EMAIL PROTECTED]

 ---
  include/linux/seqlock.h |7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

 Index: linux-2.6.23/include/linux/seqlock.h
 ===
 --- linux-2.6.23.orig/include/linux/seqlock.h
 +++ linux-2.6.23/include/linux/seqlock.h
 @@ -285,21 +285,20 @@ unsigned long __read_seqbegin_irqsave_ra
 unsigned long flags;

 local_irq_save(flags);
 -   __read_seqbegin_raw(sl);
 return flags;
  }

  static __always_inline unsigned long __read_seqbegin_irqsave(seqlock_t *sl)
  {
 -   __read_seqbegin(sl);
 return 0;
  }

  #define read_seqbegin_irqsave(lock, flags) \
 -do {   \
 +({ \
 flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
 __read_seqbegin_irqsave, lock); \
 -} while (0)
 +   read_seqbegin(lock);\
 +})

  static __always_inline int
  __read_seqretry_irqrestore(seqlock_t *sl, unsigned iv, unsigned long flags)


 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

On Wed, 2007-10-17 at 07:48 -0700, Daniel Walker wrote:
 Steven, 
 
 Could you include this patch, it was submitted on the list but you
 didn't get CC'd ..

Thanks, it may have been a while before I see this (/me has been nose
deep in debugging).

  On Tue, 2007-10-16 at 10:35 +0200, Remy Bohmer wrote:
   Hello Daniel and Ingo,
   
   I use 2.6.23-rt1 and the patch of Daniel below which seems to be in
   there breaks the compilation of the RT-kernel when CONFIG_GENERIC_TIME
   is NOT set.
   
   It breaks in the do_gettimeofday(struct timeval *tv) code in the
   architecture specific code
   where there is a call to: seq = read_seqbegin_irqsave(xtime_lock, flags);
   The PICK_FUNCTION implementation does not return anything, so the
   compile breaks here.
   
   I am figuring out how to solve this problem nicely, but I have not
   found a nice solution yet. Attached I have put my hack to make it
   compile on ARM again, but maybe one of you can do a better proposal to
   fix this.
  
  Here's another fix for this. I compile tested for ARM (!GENERIC_TIME) ,
  but I didn't boot test .. Could you boot test this patch?
  
  ---
  
  Move the read_seqbegin() call up in the chain so the value 
  can be returned
  
  Signed-off-by: Daniel Walker [EMAIL PROTECTED]
  
  ---
   include/linux/seqlock.h |7 +++
   1 file changed, 3 insertions(+), 4 deletions(-)
  
  Index: linux-2.6.23/include/linux/seqlock.h
  ===
  --- linux-2.6.23.orig/include/linux/seqlock.h
  +++ linux-2.6.23/include/linux/seqlock.h
  @@ -285,21 +285,20 @@ unsigned long __read_seqbegin_irqsave_ra
  unsigned long flags;
   
  local_irq_save(flags);
  -   __read_seqbegin_raw(sl);
  return flags;
   }
   
   static __always_inline unsigned long __read_seqbegin_irqsave(seqlock_t *sl)
   {
  -   __read_seqbegin(sl);
  return 0;
   }

The above should be renamed. They have nothing to do with seqlocks now.

   
   #define read_seqbegin_irqsave(lock, flags) \
  -do {   \
  +({ \
  flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
  __read_seqbegin_irqsave, lock); \
  -} while (0)
  +   read_seqbegin(lock);\
  +})

Yes, definitely the raw and unraw functions should be called
local_irqsave_raw or something else that makes this obvious to what it
is doing.

-- Steve


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

2007-10-17 Thread Daniel Walker

On Wed, 2007-10-17 at 11:10 -0400, Steven Rostedt wrote:


#define read_seqbegin_irqsave(lock, flags)   \
   -do { \
   +({   \
 flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
 __read_seqbegin_irqsave, lock); \
   -} while (0)
   + read_seqbegin(lock);\
   +})
 
 Yes, definitely the raw and unraw functions should be called
 local_irqsave_raw or something else that makes this obvious to what it
 is doing.

Hmm.. I'm not sure what else to name them .. Since it's in the seqlock.h
I don't think it should be called anything local_irq* .. It could be
seq_irqsave_{raw} . 

Daniel

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set


--

On Wed, 17 Oct 2007, Daniel Walker wrote:

 On Wed, 2007-10-17 at 11:10 -0400, Steven Rostedt wrote:

   
 #define read_seqbegin_irqsave(lock, flags) \
-do {   \
+({ \
flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
__read_seqbegin_irqsave, lock); \
-} while (0)
+   read_seqbegin(lock);\
+})
 
  Yes, definitely the raw and unraw functions should be called
  local_irqsave_raw or something else that makes this obvious to what it
  is doing.

 Hmm.. I'm not sure what else to name them .. Since it's in the seqlock.h
 I don't think it should be called anything local_irq* .. It could be
 seq_irqsave_{raw} .

Hmm, what about a __seq_irqsave_raw and __seq_nop?

That way it spells out that irqs are NOT touched if it is not a raw lock.

-- Steve

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

2007-10-16 Thread Daniel Walker

On Tue, 2007-10-16 at 10:35 +0200, Remy Bohmer wrote:
> Hello Daniel and Ingo,
> 
> I use 2.6.23-rt1 and the patch of Daniel below which seems to be in
> there breaks the compilation of the RT-kernel when CONFIG_GENERIC_TIME
> is NOT set.
> 
> It breaks in the do_gettimeofday(struct timeval *tv) code in the
> architecture specific code
> where there is a call to: seq = read_seqbegin_irqsave(_lock, flags);
> The PICK_FUNCTION implementation does not return anything, so the
> compile breaks here.
> 
> I am figuring out how to solve this problem nicely, but I have not
> found a nice solution yet. Attached I have put my hack to make it
> compile on ARM again, but maybe one of you can do a better proposal to
> fix this.

Here's another fix for this. I compile tested for ARM (!GENERIC_TIME) ,
but I didn't boot test .. Could you boot test this patch?

---

Move the read_seqbegin() call up in the chain so the value 
can be returned

Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>

---
 include/linux/seqlock.h |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

Index: linux-2.6.23/include/linux/seqlock.h
===
--- linux-2.6.23.orig/include/linux/seqlock.h
+++ linux-2.6.23/include/linux/seqlock.h
@@ -285,21 +285,20 @@ unsigned long __read_seqbegin_irqsave_ra
unsigned long flags;
 
local_irq_save(flags);
-   __read_seqbegin_raw(sl);
return flags;
 }
 
 static __always_inline unsigned long __read_seqbegin_irqsave(seqlock_t *sl)
 {
-   __read_seqbegin(sl);
return 0;
 }
 
 #define read_seqbegin_irqsave(lock, flags) \
-do {   \
+({ \
flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
__read_seqbegin_irqsave, lock); \
-} while (0)
+   read_seqbegin(lock);\
+})
 
 static __always_inline int
 __read_seqretry_irqrestore(seqlock_t *sl, unsigned iv, unsigned long flags)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

2007-10-16 Thread Remy Bohmer

ock_irqrestore_raw,   \
> +   __write_sequnlock_irqrestore, lock, flags)
> +
> +#define write_sequnlock_bh(lock)   \
> +   PICK_SEQ_OP(__write_sequnlock_bh_raw, __write_sequnlock, lock)
> +
> +#define write_sequnlock_irq(lock)  \
> +   PICK_SEQ_OP(__write_sequnlock_irq_raw, __write_sequnlock, lock)
> +
> +static __always_inline
> +unsigned long __read_seqbegin_irqsave_raw(raw_seqlock_t *sl)
> +{
> +   unsigned long flags;
> +
> +   local_irq_save(flags);
> +   __read_seqbegin_raw(sl);
> +   return flags;
> +}
> +
> +static __always_inline unsigned long __read_seqbegin_irqsave(seqlock_t *sl)
> +{
> +   __read_seqbegin(sl);
> +   return 0;
> +}
> +
> +#define read_seqbegin_irqsave(lock, flags) \
> +do {   \
> +   flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
> +   __read_seqbegin_irqsave, lock); \
> +} while (0)
> +
> +static __always_inline int
> +__read_seqretry_irqrestore(seqlock_t *sl, unsigned iv, unsigned long flags)
> +{
> +   return __read_seqretry(sl, iv);
> +}
> +
> +static __always_inline int
> +__read_seqretry_irqrestore_raw(raw_seqlock_t *sl, unsigned iv,
> +  unsigned long flags)
> +{
> +   int ret = read_seqretry(sl, iv);
> +   local_irq_restore(flags);
> +   preempt_check_resched();
> +   return ret;
> +}
> +
> +#define read_seqretry_irqrestore(lock, iv, flags)  \
> +   PICK_SEQ_OP_RET(__read_seqretry_irqrestore_raw, \
> +   __read_seqretry_irqrestore, lock, iv, flags)
>
>  /*
>   * Version using sequence counter only.
> @@ -286,53 +370,4 @@ static inline void write_seqcount_end(se
> smp_wmb();
> s->sequence++;
>  }
> -
> -#define PICK_IRQOP(op, lock)   \
> -do {   \
> -   if (TYPE_EQUAL((lock), raw_seqlock_t))  \
> -   op();   \
> -   else if (TYPE_EQUAL((lock), seqlock_t)) \
> -   { /* nothing */ }   \
> -   else __bad_seqlock_type();  \
> -} while (0)
> -
> -#define PICK_IRQOP2(op, arg, lock) \
> -do {   \
> -   if (TYPE_EQUAL((lock), raw_seqlock_t))  \
> -   op(arg);\
> -   else if (TYPE_EQUAL(lock, seqlock_t))   \
> -   { /* nothing */ }   \
> -   else __bad_seqlock_type();  \
> -} while (0)
> -
> -
> -
> -/*
> - * Possible sw/hw IRQ protected versions of the interfaces.
> - */
> -#define write_seqlock_irqsave(lock, flags) \
> -   do { PICK_IRQOP2(local_irq_save, flags, lock); write_seqlock(lock); } 
> while (0)
> -#define write_seqlock_irq(lock)  
>   \
> -   do { PICK_IRQOP(local_irq_disable, lock); write_seqlock(lock); } 
> while (0)
> -#define write_seqlock_bh(lock) \
> -do { PICK_IRQOP(local_bh_disable, lock); write_seqlock(lock); } 
> while (0)
> -
> -#define write_sequnlock_irqrestore(lock, flags)  
>   \
> -   do { write_sequnlock(lock); PICK_IRQOP2(local_irq_restore, flags, 
> lock); preempt_check_resched(); } while(0)
> -#define write_sequnlock_irq(lock)  \
> -   do { write_sequnlock(lock); PICK_IRQOP(local_irq_enable, lock); 
> preempt_check_resched(); } while(0)
> -#define write_sequnlock_bh(lock)   \
> -   do { write_sequnlock(lock); PICK_IRQOP(local_bh_enable, lock); } 
> while(0)
> -
> -#define read_seqbegin_irqsave(lock, flags) \
> -   ({ PICK_IRQOP2(local_irq_save, flags, lock); read_seqbegin(lock); })
> -
> -#define read_seqretry_irqrestore(lock, iv, flags)  \
> -   ({  \
> -   int ret = read_seqretry(lock, iv);  \
> -   PICK_IRQOP2(local_irq_restore, flags, lock);\
> -   preempt_check_resched();\
> -   ret;\
> -   })
> -
>  #endif /* __LINUX_SE

[RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

2007-10-16 Thread Remy Bohmer

 = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
 +   __read_seqbegin_irqsave, lock); \
 +} while (0)
 +
 +static __always_inline int
 +__read_seqretry_irqrestore(seqlock_t *sl, unsigned iv, unsigned long flags)
 +{
 +   return __read_seqretry(sl, iv);
 +}
 +
 +static __always_inline int
 +__read_seqretry_irqrestore_raw(raw_seqlock_t *sl, unsigned iv,
 +  unsigned long flags)
 +{
 +   int ret = read_seqretry(sl, iv);
 +   local_irq_restore(flags);
 +   preempt_check_resched();
 +   return ret;
 +}
 +
 +#define read_seqretry_irqrestore(lock, iv, flags)  \
 +   PICK_SEQ_OP_RET(__read_seqretry_irqrestore_raw, \
 +   __read_seqretry_irqrestore, lock, iv, flags)

  /*
   * Version using sequence counter only.
 @@ -286,53 +370,4 @@ static inline void write_seqcount_end(se
 smp_wmb();
 s-sequence++;
  }
 -
 -#define PICK_IRQOP(op, lock)   \
 -do {   \
 -   if (TYPE_EQUAL((lock), raw_seqlock_t))  \
 -   op();   \
 -   else if (TYPE_EQUAL((lock), seqlock_t)) \
 -   { /* nothing */ }   \
 -   else __bad_seqlock_type();  \
 -} while (0)
 -
 -#define PICK_IRQOP2(op, arg, lock) \
 -do {   \
 -   if (TYPE_EQUAL((lock), raw_seqlock_t))  \
 -   op(arg);\
 -   else if (TYPE_EQUAL(lock, seqlock_t))   \
 -   { /* nothing */ }   \
 -   else __bad_seqlock_type();  \
 -} while (0)
 -
 -
 -
 -/*
 - * Possible sw/hw IRQ protected versions of the interfaces.
 - */
 -#define write_seqlock_irqsave(lock, flags) \
 -   do { PICK_IRQOP2(local_irq_save, flags, lock); write_seqlock(lock); } 
 while (0)
 -#define write_seqlock_irq(lock)  
   \
 -   do { PICK_IRQOP(local_irq_disable, lock); write_seqlock(lock); } 
 while (0)
 -#define write_seqlock_bh(lock) \
 -do { PICK_IRQOP(local_bh_disable, lock); write_seqlock(lock); } 
 while (0)
 -
 -#define write_sequnlock_irqrestore(lock, flags)  
   \
 -   do { write_sequnlock(lock); PICK_IRQOP2(local_irq_restore, flags, 
 lock); preempt_check_resched(); } while(0)
 -#define write_sequnlock_irq(lock)  \
 -   do { write_sequnlock(lock); PICK_IRQOP(local_irq_enable, lock); 
 preempt_check_resched(); } while(0)
 -#define write_sequnlock_bh(lock)   \
 -   do { write_sequnlock(lock); PICK_IRQOP(local_bh_enable, lock); } 
 while(0)
 -
 -#define read_seqbegin_irqsave(lock, flags) \
 -   ({ PICK_IRQOP2(local_irq_save, flags, lock); read_seqbegin(lock); })
 -
 -#define read_seqretry_irqrestore(lock, iv, flags)  \
 -   ({  \
 -   int ret = read_seqretry(lock, iv);  \
 -   PICK_IRQOP2(local_irq_restore, flags, lock);\
 -   preempt_check_resched();\
 -   ret;\
 -   })
 -
  #endif /* __LINUX_SEQLOCK_H */

 --
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

This patch is hack that makes the RT-kernel compile again when
CONFIG_GENERIC_TIME is NOT set. Probably every architecture
has the same problem because the read_seqbegin_irqsave() macro
has been changed to something not returning anything.

Signed-off-by: Remy Bohmer [EMAIL PROTECTED]
---
 arch/arm/kernel/time.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-2.6.23/arch/arm/kernel/time.c
===
--- linux-2.6.23.orig/arch/arm/kernel/time.c	2007-10-16 09:17:25.0 +0200
+++ linux-2.6.23/arch/arm/kernel/time.c	2007-10-16 10:08:02.0 +0200
@@ -251,7 +251,8 @@ void do_gettimeofday(struct timeval *tv)
 	unsigned long usec, sec;
 
 	do {
-		seq = read_seqbegin_irqsave(xtime_lock, flags);
+		read_seqbegin_irqsave(xtime_lock, flags);
+		seq = xtime_lock.sequence;
 		usec = system_timer-offset();
 		sec = xtime.tv_sec;
 		usec += xtime.tv_nsec / 1000;

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

2007-10-16 Thread Daniel Walker

On Tue, 2007-10-16 at 10:35 +0200, Remy Bohmer wrote:
 Hello Daniel and Ingo,
 
 I use 2.6.23-rt1 and the patch of Daniel below which seems to be in
 there breaks the compilation of the RT-kernel when CONFIG_GENERIC_TIME
 is NOT set.
 
 It breaks in the do_gettimeofday(struct timeval *tv) code in the
 architecture specific code
 where there is a call to: seq = read_seqbegin_irqsave(xtime_lock, flags);
 The PICK_FUNCTION implementation does not return anything, so the
 compile breaks here.
 
 I am figuring out how to solve this problem nicely, but I have not
 found a nice solution yet. Attached I have put my hack to make it
 compile on ARM again, but maybe one of you can do a better proposal to
 fix this.

Here's another fix for this. I compile tested for ARM (!GENERIC_TIME) ,
but I didn't boot test .. Could you boot test this patch?

---

Move the read_seqbegin() call up in the chain so the value 
can be returned

Signed-off-by: Daniel Walker [EMAIL PROTECTED]

---
 include/linux/seqlock.h |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

Index: linux-2.6.23/include/linux/seqlock.h
===
--- linux-2.6.23.orig/include/linux/seqlock.h
+++ linux-2.6.23/include/linux/seqlock.h
@@ -285,21 +285,20 @@ unsigned long __read_seqbegin_irqsave_ra
unsigned long flags;
 
local_irq_save(flags);
-   __read_seqbegin_raw(sl);
return flags;
 }
 
 static __always_inline unsigned long __read_seqbegin_irqsave(seqlock_t *sl)
 {
-   __read_seqbegin(sl);
return 0;
 }
 
 #define read_seqbegin_irqsave(lock, flags) \
-do {   \
+({ \
flags = PICK_SEQ_OP_RET(__read_seqbegin_irqsave_raw,\
__read_seqbegin_irqsave, lock); \
-} while (0)
+   read_seqbegin(lock);\
+})
 
 static __always_inline int
 __read_seqretry_irqrestore(seqlock_t *sl, unsigned iv, unsigned long flags)


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

2007-09-29 Thread Russell King

On Wed, Sep 26, 2007 at 04:53:14PM -0400, Dave Jones wrote:
> Following up on this from yesterday, Linus please revert the above cset.
> It doesn't seem to be necessary (it was added to fix a miscompile in
> 'make allnoconfig' which doesn't seem to be repeatable with it reverted)
> and actively breaks the ARM SA1100 framebuffer driver.
> 
> (If you'd prefer a patch reverting it, I'll send one, but I'm
>  hoping that git-revert will just dtrt).

Dave,

Thanks for checking this out on x86, and getting it reverted.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

2007-09-29 Thread Russell King

On Wed, Sep 26, 2007 at 04:53:14PM -0400, Dave Jones wrote:
 Following up on this from yesterday, Linus please revert the above cset.
 It doesn't seem to be necessary (it was added to fix a miscompile in
 'make allnoconfig' which doesn't seem to be repeatable with it reverted)
 and actively breaks the ARM SA1100 framebuffer driver.
 
 (If you'd prefer a patch reverting it, I'll send one, but I'm
  hoping that git-revert will just dtrt).

Dave,

Thanks for checking this out on x86, and getting it reverted.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

2007-09-26 Thread Dave Jones

On Tue, Sep 25, 2007 at 10:36:51AM -0400, Dave Jones wrote:
 > On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
 >  > On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED] wrote:
 >  > > I was building a kernel for an iPaq {SA1110} and ran into this.
 >  > > 
 >  > > linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
 >  > > Has a: #include 
 >  > > Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
 >  > > defined(CONFIG_CPU_FREQ_SA1110)
 >  > > who's else section redefines the cpufreq_get function inhereited from
 >  > > the header
 >  > > 
 >  > > I'm guessing no one ever ended up in the "else" section until now, and
 >  > > that the header was added some time ago and no one caught this.
 >  > > This patch worked for me to get rid of the compile time problems.  I'm
 >  > > having issues with the kernel, but as far as I can tell they are form
 >  > > the Frame buffer and not because of this.  If this assessment is correct
 >  > > {the not needing this code anymore} then please pass this along so it
 >  > > makes it into an upcoming release.
 >  > > 
 >  > > --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
 >  > > 17:36:21.0 -0500
 >  > > +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
 >  > > 17:40:02.0 -0500
 >  > > @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
 >  > > return cclk_frequency_100khz[PPCR & 0xf] * 100;
 >  > >  }
 >  > > 
 >  > > -#else
 >  > > -/*
 >  > > - * We still need to provide this so building without cpufreq works.
 >  > > - */
 >  > > -unsigned int cpufreq_get(unsigned int cpu)
 >  > > -{
 >  > > -   return cclk_frequency_100khz[PPCR & 0xf] * 100;
 >  > > -}
 >  > > -EXPORT_SYMBOL(cpufreq_get);
 >  > >  #endif
 >  > > 
 >  > >  /*
 >  > 
 >  > No.  That code is required - the StrongARM 1100 framebuffer driver
 >  > *needs* to know what the CPU frequency is so it can set the pixel
 >  > clock divisor.
 >  > 
 >  > The real problem is the silly people who added this to cpufreq.h:
 >  > 
 >  > #ifdef CONFIG_CPU_FREQ
 >  > unsigned int cpufreq_quick_get(unsigned int cpu);
 >  > unsigned int cpufreq_get(unsigned int cpu);
 >  > #else
 >  > static inline unsigned int cpufreq_quick_get(unsigned int cpu)
 >  > {
 >  > return 0;
 >  > }
 >  > static inline unsigned int cpufreq_get(unsigned int cpu)
 >  > {
 >  > return 0;
 >  > }
 >  > #endif
 >  > 
 >  > which utterly bogus.
 > 
 > Which came from ...
 > 
 > commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
 > Author: Andrew Morton <[EMAIL PROTECTED]>
 > Date:   Wed May 2 19:27:08 2007 +0200
 > 
 > [PATCH] x86-64: fix x86_64-mm-sched-clock-share
 > 
 > Fix for the following patch. Provide dummy cpufreq functions when
 > CPUFREQ is not compiled in.
 > 
 > Cc: Andi Kleen <[EMAIL PROTECTED]>
 > Cc: Dave Jones <[EMAIL PROTECTED]>
 > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
 > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
 > 

Following up on this from yesterday, Linus please revert the above cset.
It doesn't seem to be necessary (it was added to fix a miscompile in
'make allnoconfig' which doesn't seem to be repeatable with it reverted)
and actively breaks the ARM SA1100 framebuffer driver.

(If you'd prefer a patch reverting it, I'll send one, but I'm
 hoping that git-revert will just dtrt).

Thanks,

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

2007-09-26 Thread Dave Jones

On Tue, Sep 25, 2007 at 10:36:51AM -0400, Dave Jones wrote:
  On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED] wrote:
 I was building a kernel for an iPaq {SA1110} and ran into this.
 
 linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
 Has a: #include linux/cpufreq.h
 Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
 defined(CONFIG_CPU_FREQ_SA1110)
 who's else section redefines the cpufreq_get function inhereited from
 the header
 
 I'm guessing no one ever ended up in the else section until now, and
 that the header was added some time ago and no one caught this.
 This patch worked for me to get rid of the compile time problems.  I'm
 having issues with the kernel, but as far as I can tell they are form
 the Frame buffer and not because of this.  If this assessment is correct
 {the not needing this code anymore} then please pass this along so it
 makes it into an upcoming release.
 
 --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
 17:36:21.0 -0500
 +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
 17:40:02.0 -0500
 @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
 return cclk_frequency_100khz[PPCR  0xf] * 100;
  }
 
 -#else
 -/*
 - * We still need to provide this so building without cpufreq works.
 - */
 -unsigned int cpufreq_get(unsigned int cpu)
 -{
 -   return cclk_frequency_100khz[PPCR  0xf] * 100;
 -}
 -EXPORT_SYMBOL(cpufreq_get);
  #endif
 
  /*

No.  That code is required - the StrongARM 1100 framebuffer driver
*needs* to know what the CPU frequency is so it can set the pixel
clock divisor.

The real problem is the silly people who added this to cpufreq.h:

#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu);
unsigned int cpufreq_get(unsigned int cpu);
#else
static inline unsigned int cpufreq_quick_get(unsigned int cpu)
{
return 0;
}
static inline unsigned int cpufreq_get(unsigned int cpu)
{
return 0;
}
#endif

which utterly bogus.
  
  Which came from ...
  
  commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
  Author: Andrew Morton [EMAIL PROTECTED]
  Date:   Wed May 2 19:27:08 2007 +0200
  
  [PATCH] x86-64: fix x86_64-mm-sched-clock-share
  
  Fix for the following patch. Provide dummy cpufreq functions when
  CPUFREQ is not compiled in.
  
  Cc: Andi Kleen [EMAIL PROTECTED]
  Cc: Dave Jones [EMAIL PROTECTED]
  Signed-off-by: Andrew Morton [EMAIL PROTECTED]
  Signed-off-by: Andi Kleen [EMAIL PROTECTED]
  

Following up on this from yesterday, Linus please revert the above cset.
It doesn't seem to be necessary (it was added to fix a miscompile in
'make allnoconfig' which doesn't seem to be repeatable with it reverted)
and actively breaks the ARM SA1100 framebuffer driver.

(If you'd prefer a patch reverting it, I'll send one, but I'm
 hoping that git-revert will just dtrt).

Thanks,

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

2007-09-25 Thread Greg.Chandler


Well then, now I guess I know why the FB isn't working...
Sorry to open up the can of worms this turned out to be {after reading
all the other replies first}...

 

-Original Message-
From: Russell King [mailto:[EMAIL PROTECTED] On Behalf Of Russell
King
Sent: Tuesday, September 25, 2007 2:32 AM
To: Chandler, Greg; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
Subject: Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more}
ARM/StrongARM

On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED]
wrote:
> I was building a kernel for an iPaq {SA1110} and ran into this.
> 
> linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
> Has a: #include 
> Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
> defined(CONFIG_CPU_FREQ_SA1110)
> who's else section redefines the cpufreq_get function inhereited from 
> the header
> 
> I'm guessing no one ever ended up in the "else" section until now, and

> that the header was added some time ago and no one caught this.
> This patch worked for me to get rid of the compile time problems.  I'm

> having issues with the kernel, but as far as I can tell they are form 
> the Frame buffer and not because of this.  If this assessment is 
> correct {the not needing this code anymore} then please pass this 
> along so it makes it into an upcoming release.
> 
> --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24 
> 17:36:21.0 -0500
> +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
> 17:40:02.0 -0500
> @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
> return cclk_frequency_100khz[PPCR & 0xf] * 100;  }
> 
> -#else
> -/*
> - * We still need to provide this so building without cpufreq works.
> - */
> -unsigned int cpufreq_get(unsigned int cpu) -{
> -   return cclk_frequency_100khz[PPCR & 0xf] * 100;
> -}
> -EXPORT_SYMBOL(cpufreq_get);
>  #endif
> 
>  /*

No.  That code is required - the StrongARM 1100 framebuffer driver
*needs* to know what the CPU frequency is so it can set the pixel clock
divisor.

The real problem is the silly people who added this to cpufreq.h:

#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu); unsigned int
cpufreq_get(unsigned int cpu); #else static inline unsigned int
cpufreq_quick_get(unsigned int cpu) {
return 0;
}
static inline unsigned int cpufreq_get(unsigned int cpu) {
return 0;
}
#endif

which utterly bogus.

--
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, Sep 25, 2007 at 10:31:42AM -0700, Andrew Morton wrote:
 > On Tue, 25 Sep 2007 13:22:55 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
 > 
 > >  > 
 > >  > OK, here: 
 > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch
 > >  > 
 > >  > So I guess what we want to do here is to revert that patch, test i386
 > >  > allnoconfig and then fix up anything which breaks.
 > > 
 > > Nothing breaks for me with make ARCH=i386 bzImage on my x86-64 box
 > > (which should be the same as a native build).
 > 
 > Was that with allnoconfig?

yeah.

 > > The functions that complain in that patch header don't seem to actually
 > > exist in mainline at all. (`init_sched_clock' and `call_r_s_f')
 > > Did this patch perhaps jump the gun, and these are -mm only ?
 > 
 > Could be that this patch fixed version 17 of sched-clock-share and we ended
 > up merging verion 56.  It was awful.

heh.

I think just reverting that change for .23 makes sense. It doesn't
seem that anything breaks by not having it there, and we know it
definitly breaks arm at least.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, 25 Sep 2007 13:22:55 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:

>  > 
>  > OK, here: 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch
>  > 
>  > So I guess what we want to do here is to revert that patch, test i386
>  > allnoconfig and then fix up anything which breaks.
> 
> Nothing breaks for me with make ARCH=i386 bzImage on my x86-64 box
> (which should be the same as a native build).

Was that with allnoconfig?

> The functions that complain in that patch header don't seem to actually
> exist in mainline at all. (`init_sched_clock' and `call_r_s_f')
> Did this patch perhaps jump the gun, and these are -mm only ?

Could be that this patch fixed version 17 of sched-clock-share and we ended
up merging verion 56.  It was awful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, Sep 25, 2007 at 10:08:39AM -0700, Andrew Morton wrote:
 > On Tue, 25 Sep 2007 12:58:34 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
 > 
 > > On Tue, Sep 25, 2007 at 09:52:29AM -0700, Andrew Morton wrote:
 > >  > On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
 > >  > > 
 > >  > > commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
 > >  > > Author: Andrew Morton <[EMAIL PROTECTED]>
 > >  > > Date:   Wed May 2 19:27:08 2007 +0200
 > >  > > 
 > >  > > [PATCH] x86-64: fix x86_64-mm-sched-clock-share
 > >  > > 
 > >  > > Fix for the following patch. Provide dummy cpufreq functions when
 > >  > > CPUFREQ is not compiled in.
 > >  > > 
 > >  > > Cc: Andi Kleen <[EMAIL PROTECTED]>
 > >  > > Cc: Dave Jones <[EMAIL PROTECTED]>
 > >  > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
 > >  > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
 > >  > > 
 > >  > > I don't remember seeing any problem here, so I'm not entirely sure 
 > > what
 > >  > > this was supposed to be fixing.  Perhaps the -mm-esque patch name
 > >  > > will provide Andrew/Andi clues. It lacks sufficient information for
 > >  > > my brain to guess what the problem was.
 > >  > 
 > >  > Oh geeze.  sched-clock-share went through about 18 different versions, 
 > > was
 > >  > merged, unmerged, remerged, dropped, etc.  I don't recall at what stage 
 > > in
 > >  > this mess the above fix was inserted, sorry.
 > >  > 
 > >  > > "Fix for the following patch" is also something that really should
 > >  > > never be added to a git changelog too, because 'next' means absolutely
 > >  > > nothing to me, nor I expect 99% of changelog readers.
 > >  > 
 > >  > 184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
 > >  > actually.  I intended that Andi fold it into the base patch prior to
 > >  > sending it to Linus.  He normally does that, but it looks like this
 > >  > one was handled as a standalone commit for some reason.
 > > 
 > > So lets see what happens if we revert it ?
 > > 
 > 
 > 
 > 
 > OK, here: 
 > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch
 > 
 > So I guess what we want to do here is to revert that patch, test i386
 > allnoconfig and then fix up anything which breaks.

Nothing breaks for me with make ARCH=i386 bzImage on my x86-64 box
(which should be the same as a native build).

The functions that complain in that patch header don't seem to actually
exist in mainline at all. (`init_sched_clock' and `call_r_s_f')
Did this patch perhaps jump the gun, and these are -mm only ?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, 25 Sep 2007 12:58:34 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:

> On Tue, Sep 25, 2007 at 09:52:29AM -0700, Andrew Morton wrote:
>  > On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
>  > > 
>  > > commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
>  > > Author: Andrew Morton <[EMAIL PROTECTED]>
>  > > Date:   Wed May 2 19:27:08 2007 +0200
>  > > 
>  > > [PATCH] x86-64: fix x86_64-mm-sched-clock-share
>  > > 
>  > > Fix for the following patch. Provide dummy cpufreq functions when
>  > > CPUFREQ is not compiled in.
>  > > 
>  > > Cc: Andi Kleen <[EMAIL PROTECTED]>
>  > > Cc: Dave Jones <[EMAIL PROTECTED]>
>  > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
>  > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
>  > > 
>  > > I don't remember seeing any problem here, so I'm not entirely sure what
>  > > this was supposed to be fixing.  Perhaps the -mm-esque patch name
>  > > will provide Andrew/Andi clues. It lacks sufficient information for
>  > > my brain to guess what the problem was.
>  > 
>  > Oh geeze.  sched-clock-share went through about 18 different versions, was
>  > merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
>  > this mess the above fix was inserted, sorry.
>  > 
>  > > "Fix for the following patch" is also something that really should
>  > > never be added to a git changelog too, because 'next' means absolutely
>  > > nothing to me, nor I expect 99% of changelog readers.
>  > 
>  > 184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
>  > actually.  I intended that Andi fold it into the base patch prior to
>  > sending it to Linus.  He normally does that, but it looks like this
>  > one was handled as a standalone commit for some reason.
> 
> So lets see what happens if we revert it ?
> 



OK, here: 
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch

So I guess what we want to do here is to revert that patch, test i386
allnoconfig and then fix up anything which breaks.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, Sep 25, 2007 at 09:52:29AM -0700, Andrew Morton wrote:
 > On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
 > > 
 > > commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
 > > Author: Andrew Morton <[EMAIL PROTECTED]>
 > > Date:   Wed May 2 19:27:08 2007 +0200
 > > 
 > > [PATCH] x86-64: fix x86_64-mm-sched-clock-share
 > > 
 > > Fix for the following patch. Provide dummy cpufreq functions when
 > > CPUFREQ is not compiled in.
 > > 
 > > Cc: Andi Kleen <[EMAIL PROTECTED]>
 > > Cc: Dave Jones <[EMAIL PROTECTED]>
 > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
 > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
 > > 
 > > I don't remember seeing any problem here, so I'm not entirely sure what
 > > this was supposed to be fixing.  Perhaps the -mm-esque patch name
 > > will provide Andrew/Andi clues. It lacks sufficient information for
 > > my brain to guess what the problem was.
 > 
 > Oh geeze.  sched-clock-share went through about 18 different versions, was
 > merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
 > this mess the above fix was inserted, sorry.
 > 
 > > "Fix for the following patch" is also something that really should
 > > never be added to a git changelog too, because 'next' means absolutely
 > > nothing to me, nor I expect 99% of changelog readers.
 > 
 > 184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
 > actually.  I intended that Andi fold it into the base patch prior to
 > sending it to Linus.  He normally does that, but it looks like this
 > one was handled as a standalone commit for some reason.

So lets see what happens if we revert it ?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:

> On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
>  > On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED] wrote:
>  > > I was building a kernel for an iPaq {SA1110} and ran into this.
>  > > 
>  > > linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
>  > > Has a: #include 
>  > > Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
>  > > defined(CONFIG_CPU_FREQ_SA1110)
>  > > who's else section redefines the cpufreq_get function inhereited from
>  > > the header
>  > > 
>  > > I'm guessing no one ever ended up in the "else" section until now, and
>  > > that the header was added some time ago and no one caught this.
>  > > This patch worked for me to get rid of the compile time problems.  I'm
>  > > having issues with the kernel, but as far as I can tell they are form
>  > > the Frame buffer and not because of this.  If this assessment is correct
>  > > {the not needing this code anymore} then please pass this along so it
>  > > makes it into an upcoming release.
>  > > 
>  > > --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
>  > > 17:36:21.0 -0500
>  > > +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
>  > > 17:40:02.0 -0500
>  > > @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
>  > > return cclk_frequency_100khz[PPCR & 0xf] * 100;
>  > >  }
>  > > 
>  > > -#else
>  > > -/*
>  > > - * We still need to provide this so building without cpufreq works.
>  > > - */
>  > > -unsigned int cpufreq_get(unsigned int cpu)
>  > > -{
>  > > -   return cclk_frequency_100khz[PPCR & 0xf] * 100;
>  > > -}
>  > > -EXPORT_SYMBOL(cpufreq_get);
>  > >  #endif
>  > > 
>  > >  /*
>  > 
>  > No.  That code is required - the StrongARM 1100 framebuffer driver
>  > *needs* to know what the CPU frequency is so it can set the pixel
>  > clock divisor.
>  > 
>  > The real problem is the silly people who added this to cpufreq.h:
>  > 
>  > #ifdef CONFIG_CPU_FREQ
>  > unsigned int cpufreq_quick_get(unsigned int cpu);
>  > unsigned int cpufreq_get(unsigned int cpu);
>  > #else
>  > static inline unsigned int cpufreq_quick_get(unsigned int cpu)
>  > {
>  > return 0;
>  > }
>  > static inline unsigned int cpufreq_get(unsigned int cpu)
>  > {
>  > return 0;
>  > }
>  > #endif
>  > 
>  > which utterly bogus.
> 
> Which came from ...
> 
> commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
> Author: Andrew Morton <[EMAIL PROTECTED]>
> Date:   Wed May 2 19:27:08 2007 +0200
> 
> [PATCH] x86-64: fix x86_64-mm-sched-clock-share
> 
> Fix for the following patch. Provide dummy cpufreq functions when
> CPUFREQ is not compiled in.
> 
> Cc: Andi Kleen <[EMAIL PROTECTED]>
> Cc: Dave Jones <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
> 
> I don't remember seeing any problem here, so I'm not entirely sure what
> this was supposed to be fixing.  Perhaps the -mm-esque patch name
> will provide Andrew/Andi clues. It lacks sufficient information for
> my brain to guess what the problem was.

Oh geeze.  sched-clock-share went through about 18 different versions, was
merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
this mess the above fix was inserted, sorry.

> "Fix for the following patch" is also something that really should
> never be added to a git changelog too, because 'next' means absolutely
> nothing to me, nor I expect 99% of changelog readers.

184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
actually.  I intended that Andi fold it into the base patch prior to
sending it to Linus.  He normally does that, but it looks like this
one was handled as a standalone commit for some reason.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
 > On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED] wrote:
 > > I was building a kernel for an iPaq {SA1110} and ran into this.
 > > 
 > > linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
 > > Has a: #include 
 > > Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
 > > defined(CONFIG_CPU_FREQ_SA1110)
 > > who's else section redefines the cpufreq_get function inhereited from
 > > the header
 > > 
 > > I'm guessing no one ever ended up in the "else" section until now, and
 > > that the header was added some time ago and no one caught this.
 > > This patch worked for me to get rid of the compile time problems.  I'm
 > > having issues with the kernel, but as far as I can tell they are form
 > > the Frame buffer and not because of this.  If this assessment is correct
 > > {the not needing this code anymore} then please pass this along so it
 > > makes it into an upcoming release.
 > > 
 > > --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
 > > 17:36:21.0 -0500
 > > +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
 > > 17:40:02.0 -0500
 > > @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
 > > return cclk_frequency_100khz[PPCR & 0xf] * 100;
 > >  }
 > > 
 > > -#else
 > > -/*
 > > - * We still need to provide this so building without cpufreq works.
 > > - */
 > > -unsigned int cpufreq_get(unsigned int cpu)
 > > -{
 > > -   return cclk_frequency_100khz[PPCR & 0xf] * 100;
 > > -}
 > > -EXPORT_SYMBOL(cpufreq_get);
 > >  #endif
 > > 
 > >  /*
 > 
 > No.  That code is required - the StrongARM 1100 framebuffer driver
 > *needs* to know what the CPU frequency is so it can set the pixel
 > clock divisor.
 > 
 > The real problem is the silly people who added this to cpufreq.h:
 > 
 > #ifdef CONFIG_CPU_FREQ
 > unsigned int cpufreq_quick_get(unsigned int cpu);
 > unsigned int cpufreq_get(unsigned int cpu);
 > #else
 > static inline unsigned int cpufreq_quick_get(unsigned int cpu)
 > {
 > return 0;
 > }
 > static inline unsigned int cpufreq_get(unsigned int cpu)
 > {
 > return 0;
 > }
 > #endif
 > 
 > which utterly bogus.

Which came from ...

commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
Author: Andrew Morton <[EMAIL PROTECTED]>
Date:   Wed May 2 19:27:08 2007 +0200

[PATCH] x86-64: fix x86_64-mm-sched-clock-share

Fix for the following patch. Provide dummy cpufreq functions when
CPUFREQ is not compiled in.

Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Dave Jones <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

I don't remember seeing any problem here, so I'm not entirely sure what
this was supposed to be fixing.  Perhaps the -mm-esque patch name
will provide Andrew/Andi clues. It lacks sufficient information for
my brain to guess what the problem was.

"Fix for the following patch" is also something that really should
never be added to a git changelog too, because 'next' means absolutely
nothing to me, nor I expect 99% of changelog readers.


Cc's added.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

2007-09-25 Thread Russell King

On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED] wrote:
> I was building a kernel for an iPaq {SA1110} and ran into this.
> 
> linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
> Has a: #include 
> Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
> defined(CONFIG_CPU_FREQ_SA1110)
> who's else section redefines the cpufreq_get function inhereited from
> the header
> 
> I'm guessing no one ever ended up in the "else" section until now, and
> that the header was added some time ago and no one caught this.
> This patch worked for me to get rid of the compile time problems.  I'm
> having issues with the kernel, but as far as I can tell they are form
> the Frame buffer and not because of this.  If this assessment is correct
> {the not needing this code anymore} then please pass this along so it
> makes it into an upcoming release.
> 
> --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
> 17:36:21.0 -0500
> +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
> 17:40:02.0 -0500
> @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
> return cclk_frequency_100khz[PPCR & 0xf] * 100;
>  }
> 
> -#else
> -/*
> - * We still need to provide this so building without cpufreq works.
> - */
> -unsigned int cpufreq_get(unsigned int cpu)
> -{
> -   return cclk_frequency_100khz[PPCR & 0xf] * 100;
> -}
> -EXPORT_SYMBOL(cpufreq_get);
>  #endif
> 
>  /*

No.  That code is required - the StrongARM 1100 framebuffer driver
*needs* to know what the CPU frequency is so it can set the pixel
clock divisor.

The real problem is the silly people who added this to cpufreq.h:

#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu);
unsigned int cpufreq_get(unsigned int cpu);
#else
static inline unsigned int cpufreq_quick_get(unsigned int cpu)
{
return 0;
}
static inline unsigned int cpufreq_get(unsigned int cpu)
{
return 0;
}
#endif

which utterly bogus.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

2007-09-25 Thread Russell King

On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED] wrote:
 I was building a kernel for an iPaq {SA1110} and ran into this.
 
 linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
 Has a: #include linux/cpufreq.h
 Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
 defined(CONFIG_CPU_FREQ_SA1110)
 who's else section redefines the cpufreq_get function inhereited from
 the header
 
 I'm guessing no one ever ended up in the else section until now, and
 that the header was added some time ago and no one caught this.
 This patch worked for me to get rid of the compile time problems.  I'm
 having issues with the kernel, but as far as I can tell they are form
 the Frame buffer and not because of this.  If this assessment is correct
 {the not needing this code anymore} then please pass this along so it
 makes it into an upcoming release.
 
 --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
 17:36:21.0 -0500
 +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
 17:40:02.0 -0500
 @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
 return cclk_frequency_100khz[PPCR  0xf] * 100;
  }
 
 -#else
 -/*
 - * We still need to provide this so building without cpufreq works.
 - */
 -unsigned int cpufreq_get(unsigned int cpu)
 -{
 -   return cclk_frequency_100khz[PPCR  0xf] * 100;
 -}
 -EXPORT_SYMBOL(cpufreq_get);
  #endif
 
  /*

No.  That code is required - the StrongARM 1100 framebuffer driver
*needs* to know what the CPU frequency is so it can set the pixel
clock divisor.

The real problem is the silly people who added this to cpufreq.h:

#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu);
unsigned int cpufreq_get(unsigned int cpu);
#else
static inline unsigned int cpufreq_quick_get(unsigned int cpu)
{
return 0;
}
static inline unsigned int cpufreq_get(unsigned int cpu)
{
return 0;
}
#endif

which utterly bogus.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
  On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED] wrote:
   I was building a kernel for an iPaq {SA1110} and ran into this.
   
   linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
   Has a: #include linux/cpufreq.h
   Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
   defined(CONFIG_CPU_FREQ_SA1110)
   who's else section redefines the cpufreq_get function inhereited from
   the header
   
   I'm guessing no one ever ended up in the else section until now, and
   that the header was added some time ago and no one caught this.
   This patch worked for me to get rid of the compile time problems.  I'm
   having issues with the kernel, but as far as I can tell they are form
   the Frame buffer and not because of this.  If this assessment is correct
   {the not needing this code anymore} then please pass this along so it
   makes it into an upcoming release.
   
   --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
   17:36:21.0 -0500
   +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
   17:40:02.0 -0500
   @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
   return cclk_frequency_100khz[PPCR  0xf] * 100;
}
   
   -#else
   -/*
   - * We still need to provide this so building without cpufreq works.
   - */
   -unsigned int cpufreq_get(unsigned int cpu)
   -{
   -   return cclk_frequency_100khz[PPCR  0xf] * 100;
   -}
   -EXPORT_SYMBOL(cpufreq_get);
#endif
   
/*
  
  No.  That code is required - the StrongARM 1100 framebuffer driver
  *needs* to know what the CPU frequency is so it can set the pixel
  clock divisor.
  
  The real problem is the silly people who added this to cpufreq.h:
  
  #ifdef CONFIG_CPU_FREQ
  unsigned int cpufreq_quick_get(unsigned int cpu);
  unsigned int cpufreq_get(unsigned int cpu);
  #else
  static inline unsigned int cpufreq_quick_get(unsigned int cpu)
  {
  return 0;
  }
  static inline unsigned int cpufreq_get(unsigned int cpu)
  {
  return 0;
  }
  #endif
  
  which utterly bogus.

Which came from ...

commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
Author: Andrew Morton [EMAIL PROTECTED]
Date:   Wed May 2 19:27:08 2007 +0200

[PATCH] x86-64: fix x86_64-mm-sched-clock-share

Fix for the following patch. Provide dummy cpufreq functions when
CPUFREQ is not compiled in.

Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Dave Jones [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]

I don't remember seeing any problem here, so I'm not entirely sure what
this was supposed to be fixing.  Perhaps the -mm-esque patch name
will provide Andrew/Andi clues. It lacks sufficient information for
my brain to guess what the problem was.

Fix for the following patch is also something that really should
never be added to a git changelog too, because 'next' means absolutely
nothing to me, nor I expect 99% of changelog readers.


Cc's added.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones [EMAIL PROTECTED] wrote:

 On Tue, Sep 25, 2007 at 08:31:32AM +0100, Russell King wrote:
   On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED] wrote:
I was building a kernel for an iPaq {SA1110} and ran into this.

linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
Has a: #include linux/cpufreq.h
Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
defined(CONFIG_CPU_FREQ_SA1110)
who's else section redefines the cpufreq_get function inhereited from
the header

I'm guessing no one ever ended up in the else section until now, and
that the header was added some time ago and no one caught this.
This patch worked for me to get rid of the compile time problems.  I'm
having issues with the kernel, but as far as I can tell they are form
the Frame buffer and not because of this.  If this assessment is correct
{the not needing this code anymore} then please pass this along so it
makes it into an upcoming release.

--- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
17:36:21.0 -0500
+++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
17:40:02.0 -0500
@@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
return cclk_frequency_100khz[PPCR  0xf] * 100;
 }

-#else
-/*
- * We still need to provide this so building without cpufreq works.
- */
-unsigned int cpufreq_get(unsigned int cpu)
-{
-   return cclk_frequency_100khz[PPCR  0xf] * 100;
-}
-EXPORT_SYMBOL(cpufreq_get);
 #endif

 /*
   
   No.  That code is required - the StrongARM 1100 framebuffer driver
   *needs* to know what the CPU frequency is so it can set the pixel
   clock divisor.
   
   The real problem is the silly people who added this to cpufreq.h:
   
   #ifdef CONFIG_CPU_FREQ
   unsigned int cpufreq_quick_get(unsigned int cpu);
   unsigned int cpufreq_get(unsigned int cpu);
   #else
   static inline unsigned int cpufreq_quick_get(unsigned int cpu)
   {
   return 0;
   }
   static inline unsigned int cpufreq_get(unsigned int cpu)
   {
   return 0;
   }
   #endif
   
   which utterly bogus.
 
 Which came from ...
 
 commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
 Author: Andrew Morton [EMAIL PROTECTED]
 Date:   Wed May 2 19:27:08 2007 +0200
 
 [PATCH] x86-64: fix x86_64-mm-sched-clock-share
 
 Fix for the following patch. Provide dummy cpufreq functions when
 CPUFREQ is not compiled in.
 
 Cc: Andi Kleen [EMAIL PROTECTED]
 Cc: Dave Jones [EMAIL PROTECTED]
 Signed-off-by: Andrew Morton [EMAIL PROTECTED]
 Signed-off-by: Andi Kleen [EMAIL PROTECTED]
 
 I don't remember seeing any problem here, so I'm not entirely sure what
 this was supposed to be fixing.  Perhaps the -mm-esque patch name
 will provide Andrew/Andi clues. It lacks sufficient information for
 my brain to guess what the problem was.

Oh geeze.  sched-clock-share went through about 18 different versions, was
merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
this mess the above fix was inserted, sorry.

 Fix for the following patch is also something that really should
 never be added to a git changelog too, because 'next' means absolutely
 nothing to me, nor I expect 99% of changelog readers.

184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
actually.  I intended that Andi fold it into the base patch prior to
sending it to Linus.  He normally does that, but it looks like this
one was handled as a standalone commit for some reason.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, Sep 25, 2007 at 09:52:29AM -0700, Andrew Morton wrote:
  On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones [EMAIL PROTECTED] wrote:
   
   commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
   Author: Andrew Morton [EMAIL PROTECTED]
   Date:   Wed May 2 19:27:08 2007 +0200
   
   [PATCH] x86-64: fix x86_64-mm-sched-clock-share
   
   Fix for the following patch. Provide dummy cpufreq functions when
   CPUFREQ is not compiled in.
   
   Cc: Andi Kleen [EMAIL PROTECTED]
   Cc: Dave Jones [EMAIL PROTECTED]
   Signed-off-by: Andrew Morton [EMAIL PROTECTED]
   Signed-off-by: Andi Kleen [EMAIL PROTECTED]
   
   I don't remember seeing any problem here, so I'm not entirely sure what
   this was supposed to be fixing.  Perhaps the -mm-esque patch name
   will provide Andrew/Andi clues. It lacks sufficient information for
   my brain to guess what the problem was.
  
  Oh geeze.  sched-clock-share went through about 18 different versions, was
  merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
  this mess the above fix was inserted, sorry.
  
   Fix for the following patch is also something that really should
   never be added to a git changelog too, because 'next' means absolutely
   nothing to me, nor I expect 99% of changelog readers.
  
  184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
  actually.  I intended that Andi fold it into the base patch prior to
  sending it to Linus.  He normally does that, but it looks like this
  one was handled as a standalone commit for some reason.

So lets see what happens if we revert it ?

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, 25 Sep 2007 12:58:34 -0400 Dave Jones [EMAIL PROTECTED] wrote:

 On Tue, Sep 25, 2007 at 09:52:29AM -0700, Andrew Morton wrote:
   On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones [EMAIL PROTECTED] wrote:

commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
Author: Andrew Morton [EMAIL PROTECTED]
Date:   Wed May 2 19:27:08 2007 +0200

[PATCH] x86-64: fix x86_64-mm-sched-clock-share

Fix for the following patch. Provide dummy cpufreq functions when
CPUFREQ is not compiled in.

Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Dave Jones [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]

I don't remember seeing any problem here, so I'm not entirely sure what
this was supposed to be fixing.  Perhaps the -mm-esque patch name
will provide Andrew/Andi clues. It lacks sufficient information for
my brain to guess what the problem was.
   
   Oh geeze.  sched-clock-share went through about 18 different versions, was
   merged, unmerged, remerged, dropped, etc.  I don't recall at what stage in
   this mess the above fix was inserted, sorry.
   
Fix for the following patch is also something that really should
never be added to a git changelog too, because 'next' means absolutely
nothing to me, nor I expect 99% of changelog readers.
   
   184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
   actually.  I intended that Andi fold it into the base patch prior to
   sending it to Linus.  He normally does that, but it looks like this
   one was handled as a standalone commit for some reason.
 
 So lets see what happens if we revert it ?
 

grep flurry

OK, here: 
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch

So I guess what we want to do here is to revert that patch, test i386
allnoconfig and then fix up anything which breaks.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, Sep 25, 2007 at 10:08:39AM -0700, Andrew Morton wrote:
On Tue, 25 Sep 2007 12:58:34 -0400 Dave Jones [EMAIL PROTECTED] wrote:

On Tue, Sep 25, 2007 at 09:52:29AM -0700, Andrew Morton wrote:
On Tue, 25 Sep 2007 10:36:51 -0400 Dave Jones [EMAIL PROTECTED] wrote:

commit 184c44d2049c4db7ef6ec65794546954da2c6a0e
Author: Andrew Morton [EMAIL PROTECTED]
Date: Wed May 2 19:27:08 2007 +0200

[PATCH] x86-64: fix x86_64-mm-sched-clock-share

Fix for the following patch. Provide dummy cpufreq functions when
CPUFREQ is not compiled in.

Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Dave Jones [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]

I don't remember seeing any problem here, so I'm not entirely sure
what
this was supposed to be fixing. Perhaps the -mm-esque patch name
will provide Andrew/Andi clues. It lacks sufficient information for
my brain to guess what the problem was.

Oh geeze. sched-clock-share went through about 18 different versions,
was
merged, unmerged, remerged, dropped, etc. I don't recall at what stage
in
this mess the above fix was inserted, sorry.

Fix for the following patch is also something that really should
never be added to a git changelog too, because 'next' means absolutely
nothing to me, nor I expect 99% of changelog readers.

184c44d2049c4db7ef6ec65794546954da2c6a0e should never have existed,
actually. I intended that Andi fold it into the base patch prior to
sending it to Linus. He normally does that, but it looks like this
one was handled as a standalone commit for some reason.

So lets see what happens if we revert it ?

grep flurry

OK, here:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch

So I guess what we want to do here is to revert that patch, test i386
allnoconfig and then fix up anything which breaks.

Nothing breaks for me with make ARCH=i386 bzImage on my x86-64 box
(which should be the same as a native build).

The functions that complain in that patch header don't seem to actually
exist in mainline at all. (`init_sched_clock' and `call_r_s_f')
Did this patch perhaps jump the gun, and these are -mm only ?

Dave

--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, 25 Sep 2007 13:22:55 -0400 Dave Jones [EMAIL PROTECTED] wrote:

   
   OK, here: 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch
   
   So I guess what we want to do here is to revert that patch, test i386
   allnoconfig and then fix up anything which breaks.
 
 Nothing breaks for me with make ARCH=i386 bzImage on my x86-64 box
 (which should be the same as a native build).

Was that with allnoconfig?

 The functions that complain in that patch header don't seem to actually
 exist in mainline at all. (`init_sched_clock' and `call_r_s_f')
 Did this patch perhaps jump the gun, and these are -mm only ?

Could be that this patch fixed version 17 of sched-clock-share and we ended
up merging verion 56.  It was awful.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

On Tue, Sep 25, 2007 at 10:31:42AM -0700, Andrew Morton wrote:
  On Tue, 25 Sep 2007 13:22:55 -0400 Dave Jones [EMAIL PROTECTED] wrote:
  
 
 OK, here: 
   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/broken-out/fix-x86_64-mm-sched-clock-share.patch
 
 So I guess what we want to do here is to revert that patch, test i386
 allnoconfig and then fix up anything which breaks.
   
   Nothing breaks for me with make ARCH=i386 bzImage on my x86-64 box
   (which should be the same as a native build).
  
  Was that with allnoconfig?

yeah.

   The functions that complain in that patch header don't seem to actually
   exist in mainline at all. (`init_sched_clock' and `call_r_s_f')
   Did this patch perhaps jump the gun, and these are -mm only ?
  
  Could be that this patch fixed version 17 of sched-clock-share and we ended
  up merging verion 56.  It was awful.

heh.

I think just reverting that change for .23 makes sense. It doesn't
seem that anything breaks by not having it there, and we know it
definitly breaks arm at least.

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

2007-09-25 Thread Greg.Chandler


Well then, now I guess I know why the FB isn't working...
Sorry to open up the can of worms this turned out to be {after reading
all the other replies first}...

 

-Original Message-
From: Russell King [mailto:[EMAIL PROTECTED] On Behalf Of Russell
King
Sent: Tuesday, September 25, 2007 2:32 AM
To: Chandler, Greg; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
Subject: Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more}
ARM/StrongARM

On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED]
wrote:
 I was building a kernel for an iPaq {SA1110} and ran into this.
 
 linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
 Has a: #include linux/cpufreq.h
 Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
 defined(CONFIG_CPU_FREQ_SA1110)
 who's else section redefines the cpufreq_get function inhereited from 
 the header
 
 I'm guessing no one ever ended up in the else section until now, and

 that the header was added some time ago and no one caught this.
 This patch worked for me to get rid of the compile time problems.  I'm

 having issues with the kernel, but as far as I can tell they are form 
 the Frame buffer and not because of this.  If this assessment is 
 correct {the not needing this code anymore} then please pass this 
 along so it makes it into an upcoming release.
 
 --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24 
 17:36:21.0 -0500
 +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
 17:40:02.0 -0500
 @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
 return cclk_frequency_100khz[PPCR  0xf] * 100;  }
 
 -#else
 -/*
 - * We still need to provide this so building without cpufreq works.
 - */
 -unsigned int cpufreq_get(unsigned int cpu) -{
 -   return cclk_frequency_100khz[PPCR  0xf] * 100;
 -}
 -EXPORT_SYMBOL(cpufreq_get);
  #endif
 
  /*

No.  That code is required - the StrongARM 1100 framebuffer driver
*needs* to know what the CPU frequency is so it can set the pixel clock
divisor.

The real problem is the silly people who added this to cpufreq.h:

#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu); unsigned int
cpufreq_get(unsigned int cpu); #else static inline unsigned int
cpufreq_quick_get(unsigned int cpu) {
return 0;
}
static inline unsigned int cpufreq_get(unsigned int cpu) {
return 0;
}
#endif

which utterly bogus.

--
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc2-mm1 -- PPC G5 kernel compile failure (patch)

2007-08-10 Thread Andy Whitcroft

Krzysztof Helt wrote:
> On Thu, 9 Aug 2007 14:04:49 +0100
> Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> 
>> Seeing the following compile error on a G5 mac:
>>
>>   drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
>>   drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use in this
>>  function)
>>   drivers/video/tdfxfb.c:1341: error: (Each undeclared identifier is
>> reported only once
>>   drivers/video/tdfxfb.c:1341: error: for each function it appears in.)
>>
>> This seems to be the following fragment from tdfxfb-hardware-cursor:
>>
>> +   } else if (!strcmp(this_opt, "hwcursor")) {
>> +   hwcursor = simple_strtoul(opt + 9, NULL, 0);
>>
>> I guess the nieve fix would be s/opt/this_opt, but I am also
>> suspicious of the +9 here as hwcursor is only 8 long?  Now this
>> seems to take a numeric value and I assume that is via hwcursor=N,
>> if so then the +9 would make sense _if_ the strcmp was against
>> "hwcursor=".
>>
> 
> The patch below fixes all issues you have pointed out. It also fixes
> the description of the nomtrr option.
> 
> ---
> 
> From: Krzysztof Helt <[EMAIL PROTECTED]>
> 
> This patch fixes compilation with setup options bug and corrects
> description of the nomtrr option.
> 
> Signed-off-by: Krzysztof Helt <[EMAIL PROTECTED]>
> 
> ---
> 
> --- linux-2.6.22.new/drivers/video/tdfxfb.c   2007-08-09 16:11:23.870028259 
> +0200
> +++ linux-2.6.23/drivers/video/tdfxfb.c   2007-08-09 16:15:07.654781024 
> +0200
> @@ -1337,8 +1337,8 @@ static void tdfxfb_setup(char *options)
>   nopan = 1;
>   } else if (!strcmp(this_opt, "nowrap")) {
>   nowrap = 1;
> - } else if (!strcmp(this_opt, "hwcursor")) {
> - hwcursor = simple_strtoul(opt + 9, NULL, 0);
> + } else if (!strncmp(this_opt, "hwcursor=", 9)) {
> + hwcursor = simple_strtoul(this_opt + 9, NULL, 0);
>  #ifdef CONFIG_MTRR
>   } else if (!strncmp(this_opt, "nomtrr", 6)) {
>   nomtrr = 1;
> @@ -1409,7 +1409,7 @@ MODULE_PARM_DESC(hwcursor, "Enable hardw
>   "(1=enable, 0=disable, default=1)");
>  #ifdef CONFIG_MTRR
>  module_param(nomtrr, bool, 0);
> -MODULE_PARM_DESC(nomtrr, "Disable MTRR support (0 or 1=disabled) 
> (default=0)");
> +MODULE_PARM_DESC(nomtrr, "Disable MTRR support (default: enabled)");
>  #endif
>  
>  module_init(tdfxfb_init);

Confirmed that this gets my kernel compiled and the result boots.

Tested-by: Andy Whitcroft <[EMAIL PROTECTED]>

-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc2-mm1 -- PPC G5 kernel compile failure (patch)

2007-08-10 Thread Andy Whitcroft

Krzysztof Helt wrote:
 On Thu, 9 Aug 2007 14:04:49 +0100
 Andy Whitcroft [EMAIL PROTECTED] wrote:
 
 Seeing the following compile error on a G5 mac:

   drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
   drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use in this
  function)
   drivers/video/tdfxfb.c:1341: error: (Each undeclared identifier is
 reported only once
   drivers/video/tdfxfb.c:1341: error: for each function it appears in.)

 This seems to be the following fragment from tdfxfb-hardware-cursor:

 +   } else if (!strcmp(this_opt, hwcursor)) {
 +   hwcursor = simple_strtoul(opt + 9, NULL, 0);

 I guess the nieve fix would be s/opt/this_opt, but I am also
 suspicious of the +9 here as hwcursor is only 8 long?  Now this
 seems to take a numeric value and I assume that is via hwcursor=N,
 if so then the +9 would make sense _if_ the strcmp was against
 hwcursor=.

 
 The patch below fixes all issues you have pointed out. It also fixes
 the description of the nomtrr option.
 
 ---
 
 From: Krzysztof Helt [EMAIL PROTECTED]
 
 This patch fixes compilation with setup options bug and corrects
 description of the nomtrr option.
 
 Signed-off-by: Krzysztof Helt [EMAIL PROTECTED]
 
 ---
 
 --- linux-2.6.22.new/drivers/video/tdfxfb.c   2007-08-09 16:11:23.870028259 
 +0200
 +++ linux-2.6.23/drivers/video/tdfxfb.c   2007-08-09 16:15:07.654781024 
 +0200
 @@ -1337,8 +1337,8 @@ static void tdfxfb_setup(char *options)
   nopan = 1;
   } else if (!strcmp(this_opt, nowrap)) {
   nowrap = 1;
 - } else if (!strcmp(this_opt, hwcursor)) {
 - hwcursor = simple_strtoul(opt + 9, NULL, 0);
 + } else if (!strncmp(this_opt, hwcursor=, 9)) {
 + hwcursor = simple_strtoul(this_opt + 9, NULL, 0);
  #ifdef CONFIG_MTRR
   } else if (!strncmp(this_opt, nomtrr, 6)) {
   nomtrr = 1;
 @@ -1409,7 +1409,7 @@ MODULE_PARM_DESC(hwcursor, Enable hardw
   (1=enable, 0=disable, default=1));
  #ifdef CONFIG_MTRR
  module_param(nomtrr, bool, 0);
 -MODULE_PARM_DESC(nomtrr, Disable MTRR support (0 or 1=disabled) 
 (default=0));
 +MODULE_PARM_DESC(nomtrr, Disable MTRR support (default: enabled));
  #endif
  
  module_init(tdfxfb_init);

Confirmed that this gets my kernel compiled and the result boots.

Tested-by: Andy Whitcroft [EMAIL PROTECTED]

-apw
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc2-mm1 -- PPC G5 kernel compile failure (patch)

On Thu, Aug 09, 2007 at 04:20:06PM +0200, Krzysztof Helt wrote:
> On Thu, 9 Aug 2007 14:04:49 +0100
> Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> 
> > Seeing the following compile error on a G5 mac:
> > 
> >   drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
> >   drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use in this
> >  function)
> >   drivers/video/tdfxfb.c:1341: error: (Each undeclared identifier is
> > reported only once
> >   drivers/video/tdfxfb.c:1341: error: for each function it appears in.)
> > 
> > This seems to be the following fragment from tdfxfb-hardware-cursor:
> > 
> > +   } else if (!strcmp(this_opt, "hwcursor")) {
> > +   hwcursor = simple_strtoul(opt + 9, NULL, 0);
> > 
> > I guess the nieve fix would be s/opt/this_opt, but I am also
> > suspicious of the +9 here as hwcursor is only 8 long?  Now this
> > seems to take a numeric value and I assume that is via hwcursor=N,
> > if so then the +9 would make sense _if_ the strcmp was against
> > "hwcursor=".
> > 
> 
> The patch below fixes all issues you have pointed out. It also fixes
> the description of the nomtrr option.

Will push this through our tests and let you know.

-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc2-mm1 -- PPC G5 kernel compile failure (patch)

2007-08-09 Thread Krzysztof Helt

On Thu, 9 Aug 2007 14:04:49 +0100
Andy Whitcroft <[EMAIL PROTECTED]> wrote:

> Seeing the following compile error on a G5 mac:
> 
>   drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
>   drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use in this
>  function)
>   drivers/video/tdfxfb.c:1341: error: (Each undeclared identifier is
> reported only once
>   drivers/video/tdfxfb.c:1341: error: for each function it appears in.)
> 
> This seems to be the following fragment from tdfxfb-hardware-cursor:
> 
> +   } else if (!strcmp(this_opt, "hwcursor")) {
> +   hwcursor = simple_strtoul(opt + 9, NULL, 0);
> 
> I guess the nieve fix would be s/opt/this_opt, but I am also
> suspicious of the +9 here as hwcursor is only 8 long?  Now this
> seems to take a numeric value and I assume that is via hwcursor=N,
> if so then the +9 would make sense _if_ the strcmp was against
> "hwcursor=".
> 

The patch below fixes all issues you have pointed out. It also fixes
the description of the nomtrr option.

---

From: Krzysztof Helt <[EMAIL PROTECTED]>

This patch fixes compilation with setup options bug and corrects
description of the nomtrr option.

Signed-off-by: Krzysztof Helt <[EMAIL PROTECTED]>

---

--- linux-2.6.22.new/drivers/video/tdfxfb.c 2007-08-09 16:11:23.870028259 
+0200
+++ linux-2.6.23/drivers/video/tdfxfb.c 2007-08-09 16:15:07.654781024 +0200
@@ -1337,8 +1337,8 @@ static void tdfxfb_setup(char *options)
nopan = 1;
} else if (!strcmp(this_opt, "nowrap")) {
nowrap = 1;
-   } else if (!strcmp(this_opt, "hwcursor")) {
-   hwcursor = simple_strtoul(opt + 9, NULL, 0);
+   } else if (!strncmp(this_opt, "hwcursor=", 9)) {
+   hwcursor = simple_strtoul(this_opt + 9, NULL, 0);
 #ifdef CONFIG_MTRR
} else if (!strncmp(this_opt, "nomtrr", 6)) {
nomtrr = 1;
@@ -1409,7 +1409,7 @@ MODULE_PARM_DESC(hwcursor, "Enable hardw
"(1=enable, 0=disable, default=1)");
 #ifdef CONFIG_MTRR
 module_param(nomtrr, bool, 0);
-MODULE_PARM_DESC(nomtrr, "Disable MTRR support (0 or 1=disabled) (default=0)");
+MODULE_PARM_DESC(nomtrr, "Disable MTRR support (default: enabled)");
 #endif
 
 module_init(tdfxfb_init);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc2-mm1 -- PPC G5 kernel compile failure

Seeing the following compile error on a G5 mac:

  drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
  drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use in this
 function)
  drivers/video/tdfxfb.c:1341: error: (Each undeclared identifier is
reported only once
  drivers/video/tdfxfb.c:1341: error: for each function it appears in.)

This seems to be the following fragment from tdfxfb-hardware-cursor:

+   } else if (!strcmp(this_opt, "hwcursor")) {
+   hwcursor = simple_strtoul(opt + 9, NULL, 0);

I guess the nieve fix would be s/opt/this_opt, but I am also
suspicious of the +9 here as hwcursor is only 8 long?  Now this
seems to take a numeric value and I assume that is via hwcursor=N,
if so then the +9 would make sense _if_ the strcmp was against
"hwcursor=".

Krzysztof?

-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc2-mm1 -- PPC G5 kernel compile failure

Seeing the following compile error on a G5 mac:

  drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
  drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use in this
 function)
  drivers/video/tdfxfb.c:1341: error: (Each undeclared identifier is
reported only once
  drivers/video/tdfxfb.c:1341: error: for each function it appears in.)

This seems to be the following fragment from tdfxfb-hardware-cursor:

+   } else if (!strcmp(this_opt, hwcursor)) {
+   hwcursor = simple_strtoul(opt + 9, NULL, 0);

I guess the nieve fix would be s/opt/this_opt, but I am also
suspicious of the +9 here as hwcursor is only 8 long?  Now this
seems to take a numeric value and I assume that is via hwcursor=N,
if so then the +9 would make sense _if_ the strcmp was against
hwcursor=.

Krzysztof?

-apw
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc2-mm1 -- PPC G5 kernel compile failure (patch)

2007-08-09 Thread Krzysztof Helt

On Thu, 9 Aug 2007 14:04:49 +0100
Andy Whitcroft [EMAIL PROTECTED] wrote:

 Seeing the following compile error on a G5 mac:
 
   drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
   drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use in this
  function)
   drivers/video/tdfxfb.c:1341: error: (Each undeclared identifier is
 reported only once
   drivers/video/tdfxfb.c:1341: error: for each function it appears in.)
 
 This seems to be the following fragment from tdfxfb-hardware-cursor:
 
 +   } else if (!strcmp(this_opt, hwcursor)) {
 +   hwcursor = simple_strtoul(opt + 9, NULL, 0);
 
 I guess the nieve fix would be s/opt/this_opt, but I am also
 suspicious of the +9 here as hwcursor is only 8 long?  Now this
 seems to take a numeric value and I assume that is via hwcursor=N,
 if so then the +9 would make sense _if_ the strcmp was against
 hwcursor=.
 

The patch below fixes all issues you have pointed out. It also fixes
the description of the nomtrr option.

---

From: Krzysztof Helt [EMAIL PROTECTED]

This patch fixes compilation with setup options bug and corrects
description of the nomtrr option.

Signed-off-by: Krzysztof Helt [EMAIL PROTECTED]

---

--- linux-2.6.22.new/drivers/video/tdfxfb.c 2007-08-09 16:11:23.870028259 
+0200
+++ linux-2.6.23/drivers/video/tdfxfb.c 2007-08-09 16:15:07.654781024 +0200
@@ -1337,8 +1337,8 @@ static void tdfxfb_setup(char *options)
nopan = 1;
} else if (!strcmp(this_opt, nowrap)) {
nowrap = 1;
-   } else if (!strcmp(this_opt, hwcursor)) {
-   hwcursor = simple_strtoul(opt + 9, NULL, 0);
+   } else if (!strncmp(this_opt, hwcursor=, 9)) {
+   hwcursor = simple_strtoul(this_opt + 9, NULL, 0);
 #ifdef CONFIG_MTRR
} else if (!strncmp(this_opt, nomtrr, 6)) {
nomtrr = 1;
@@ -1409,7 +1409,7 @@ MODULE_PARM_DESC(hwcursor, Enable hardw
(1=enable, 0=disable, default=1));
 #ifdef CONFIG_MTRR
 module_param(nomtrr, bool, 0);
-MODULE_PARM_DESC(nomtrr, Disable MTRR support (0 or 1=disabled) (default=0));
+MODULE_PARM_DESC(nomtrr, Disable MTRR support (default: enabled));
 #endif
 
 module_init(tdfxfb_init);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc2-mm1 -- PPC G5 kernel compile failure (patch)

On Thu, Aug 09, 2007 at 04:20:06PM +0200, Krzysztof Helt wrote:
 On Thu, 9 Aug 2007 14:04:49 +0100
 Andy Whitcroft [EMAIL PROTECTED] wrote:
 
  Seeing the following compile error on a G5 mac:
  
drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use in this
   function)
drivers/video/tdfxfb.c:1341: error: (Each undeclared identifier is
  reported only once
drivers/video/tdfxfb.c:1341: error: for each function it appears in.)
  
  This seems to be the following fragment from tdfxfb-hardware-cursor:
  
  +   } else if (!strcmp(this_opt, hwcursor)) {
  +   hwcursor = simple_strtoul(opt + 9, NULL, 0);
  
  I guess the nieve fix would be s/opt/this_opt, but I am also
  suspicious of the +9 here as hwcursor is only 8 long?  Now this
  seems to take a numeric value and I assume that is via hwcursor=N,
  if so then the +9 would make sense _if_ the strcmp was against
  hwcursor=.
  
 
 The patch below fixes all issues you have pointed out. It also fixes
 the description of the nomtrr option.

Will push this through our tests and let you know.

-apw
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel compile error in bootsplash.c

2005-08-27 Thread Alessandro Suardi

On 8/27/05, J. B. <[EMAIL PROTECTED]> wrote:
> if got it from
>  ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
> and applied some patches

The problem resides in the "some patches" then - as Randy said,
 bootsplash.c isn't in kernel.org kernels.

> > 
> > From: Randy.Dunlap <[EMAIL PROTECTED]>
> > Sent: Sat Aug 27 20:34:27 CEST 2005
> > To: J. B. <[EMAIL PROTECTED]>
> > Subject: Re: kernel compile error in bootsplash.c
> >
> >
> > On Sat, 27 Aug 2005 19:53:35 +0200 (CEST) J. B. wrote:
> >
> > > I try to compile a 2.6.10 kernel but it stops with an error
> > > in bootsplash.c. I have everything set in my .config file in 
> > > /usr/src/linux for bootsplash support.
> > >
> > > Anybody an idea. Where should i start to look? I am a newbie in kernel 
> > > world
> >
> > This is in a vendor kernel, right?
> > So please take it up with that vendor.
> >
> > Kernels from kernel.org don't contain drivers/video/bootsplash/*
> >
> >
> > > in file included from drivers/video/bootsplash/bootsplash.c:18:
> > > include/linux/fb.h:869: error: array type has incomplete element type
> > > drivers/video/bootsplash/bootsplash.c:37: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:38: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:39: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:40: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:41: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:42: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:43: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:44: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:45: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:46: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:47: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:48: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:49: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:50: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:52: warning: pointer targets in 
> > > initialization differ in signedness
> > > drivers/video/bootsplash/bootsplash.c: In function 'splash_verbose':
> > > drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
> > > passing argument 1 of 'splashcopy' differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
> > > passing argument 2 of 'splashcopy' differ in signedness
> > > drivers/video/bootsplash/bootsplash.c: In function 'splash_prepare':
> > > drivers/video/bootsplash/bootsplash.c:642: warning: pointer targets in 
> > > passing argument 1 of 'splashcopy' differ in signedness
> > > drivers/video/bootsplash/bootsplash.c: In function 'splash_write_proc':
> > > drivers/video/bootsplash/bootsplash.c:788: warning: pointer targets in 
> > > passing argument 1 of 'boxit' differ in signedness
> > > drivers/video/bootsplash/bootsplash.c:789: warning: pointer targets in 
> > > passing argument 1 of 'boxit' differ in signedness
> > > make[5]: *** [drivers/video/bootsplash/bootsplash.o] Error 1
> > > make[4]: *** [drivers/video/bootsplash] Error 2
> > > make[3]: *** [drivers/video] Error 2
> > > make[2]: *** [drivers] Error 2
> > > make[2]: Leaving directory `/usr/src/linux-2.6.10'
> > > make[1]: *** [stamp-build] Error 2
> > > make[1]: Leaving directory `/usr/src/linux-2.6.10'
> > > make: *** [stamp-buildpackage] Error 2

--alessandro

 "Not every smile means I'm laughing inside"

(Wallflowers - "From The Bottom Of My Heart")
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel compile error in bootsplash.c

2005-08-27 Thread Lee Revell

On Sat, 2005-08-27 at 20:48 +0200, J. B. wrote:
> if got it from
>  ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
> and applied some patches

"some patches" could be anything.  Please don't waste our time with bug
reports for randomly patched kernels.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel compile error in bootsplash.c

if got it from
 ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
and applied some patches

> 
> From: Randy.Dunlap <[EMAIL PROTECTED]>
> Sent: Sat Aug 27 20:34:27 CEST 2005
> To: J. B. <[EMAIL PROTECTED]>
> Subject: Re: kernel compile error in bootsplash.c
> 
> 
> On Sat, 27 Aug 2005 19:53:35 +0200 (CEST) J. B. wrote:
> 
> > I try to compile a 2.6.10 kernel but it stops with an error
> > in bootsplash.c. I have everything set in my .config file in /usr/src/linux 
> > for bootsplash support. 
> > 
> > Anybody an idea. Where should i start to look? I am a newbie in kernel world
> 
> This is in a vendor kernel, right?
> So please take it up with that vendor.
> 
> Kernels from kernel.org don't contain drivers/video/bootsplash/*
> 
> 
> > in file included from drivers/video/bootsplash/bootsplash.c:18:
> > include/linux/fb.h:869: error: array type has incomplete element type
> > drivers/video/bootsplash/bootsplash.c:37: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:38: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:39: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:40: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:41: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:42: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:43: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:44: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:45: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:46: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:47: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:48: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:49: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:50: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c:52: warning: pointer targets in 
> > initialization differ in signedness
> > drivers/video/bootsplash/bootsplash.c: In function 'splash_verbose':
> > drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
> > passing argument 1 of 'splashcopy' differ in signedness
> > drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
> > passing argument 2 of 'splashcopy' differ in signedness
> > drivers/video/bootsplash/bootsplash.c: In function 'splash_prepare':
> > drivers/video/bootsplash/bootsplash.c:642: warning: pointer targets in 
> > passing argument 1 of 'splashcopy' differ in signedness
> > drivers/video/bootsplash/bootsplash.c: In function 'splash_write_proc':
> > drivers/video/bootsplash/bootsplash.c:788: warning: pointer targets in 
> > passing argument 1 of 'boxit' differ in signedness
> > drivers/video/bootsplash/bootsplash.c:789: warning: pointer targets in 
> > passing argument 1 of 'boxit' differ in signedness
> > make[5]: *** [drivers/video/bootsplash/bootsplash.o] Error 1
> > make[4]: *** [drivers/video/bootsplash] Error 2
> > make[3]: *** [drivers/video] Error 2
> > make[2]: *** [drivers] Error 2
> > make[2]: Leaving directory `/usr/src/linux-2.6.10'
> > make[1]: *** [stamp-build] Error 2
> > make[1]: Leaving directory `/usr/src/linux-2.6.10'
> > make: *** [stamp-buildpackage] Error 2
> > -
> 
> 
> ---
> ~Randy

-
Mail.be, WebMail and Virtual Office
http://www.mail.be

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel compile error in bootsplash.c

2005-08-27 Thread Randy.Dunlap

On Sat, 27 Aug 2005 19:53:35 +0200 (CEST) J. B. wrote:

> I try to compile a 2.6.10 kernel but it stops with an error
> in bootsplash.c. I have everything set in my .config file in /usr/src/linux 
> for bootsplash support. 
> 
> Anybody an idea. Where should i start to look? I am a newbie in kernel world

This is in a vendor kernel, right?
So please take it up with that vendor.

Kernels from kernel.org don't contain drivers/video/bootsplash/*


> in file included from drivers/video/bootsplash/bootsplash.c:18:
> include/linux/fb.h:869: error: array type has incomplete element type
> drivers/video/bootsplash/bootsplash.c:37: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:38: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:39: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:40: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:41: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:42: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:43: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:44: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:45: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:46: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:47: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:48: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:49: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:50: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:52: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c: In function 'splash_verbose':
> drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
> passing argument 1 of 'splashcopy' differ in signedness
> drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
> passing argument 2 of 'splashcopy' differ in signedness
> drivers/video/bootsplash/bootsplash.c: In function 'splash_prepare':
> drivers/video/bootsplash/bootsplash.c:642: warning: pointer targets in 
> passing argument 1 of 'splashcopy' differ in signedness
> drivers/video/bootsplash/bootsplash.c: In function 'splash_write_proc':
> drivers/video/bootsplash/bootsplash.c:788: warning: pointer targets in 
> passing argument 1 of 'boxit' differ in signedness
> drivers/video/bootsplash/bootsplash.c:789: warning: pointer targets in 
> passing argument 1 of 'boxit' differ in signedness
> make[5]: *** [drivers/video/bootsplash/bootsplash.o] Error 1
> make[4]: *** [drivers/video/bootsplash] Error 2
> make[3]: *** [drivers/video] Error 2
> make[2]: *** [drivers] Error 2
> make[2]: Leaving directory `/usr/src/linux-2.6.10'
> make[1]: *** [stamp-build] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.6.10'
> make: *** [stamp-buildpackage] Error 2
> -


---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel compile error in bootsplash.c

I googled some more and seem to have found the reason of the error:

http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html

It is related to gcc 4.0 which indeed i did an apt-get update for.

But is there a patch avail for my 2.6.10 kernel-source?

 
> 
> I try to compile a 2.6.10 kernel but it stops with an error
> in bootsplash.c. I have everything set in my .config file in /usr/src/linux 
> for bootsplash support. 
> 
> Anybody an idea. Where should i start to look? I am a newbie in kernel world
> 
> in file included from drivers/video/bootsplash/bootsplash.c:18:
> include/linux/fb.h:869: error: array type has incomplete element type
> drivers/video/bootsplash/bootsplash.c:37: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:38: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:39: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:40: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:41: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:42: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:43: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:44: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:45: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:46: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:47: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:48: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:49: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:50: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c:52: warning: pointer targets in 
> initialization differ in signedness
> drivers/video/bootsplash/bootsplash.c: In function 'splash_verbose':
> drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
> passing argument 1 of 'splashcopy' differ in signedness
> drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
> passing argument 2 of 'splashcopy' differ in signedness
> drivers/video/bootsplash/bootsplash.c: In function 'splash_prepare':
> drivers/video/bootsplash/bootsplash.c:642: warning: pointer targets in 
> passing argument 1 of 'splashcopy' differ in signedness
> drivers/video/bootsplash/bootsplash.c: In function 'splash_write_proc':
> drivers/video/bootsplash/bootsplash.c:788: warning: pointer targets in 
> passing argument 1 of 'boxit' differ in signedness
> drivers/video/bootsplash/bootsplash.c:789: warning: pointer targets in 
> passing argument 1 of 'boxit' differ in signedness
> make[5]: *** [drivers/video/bootsplash/bootsplash.o] Error 1
> make[4]: *** [drivers/video/bootsplash] Error 2
> make[3]: *** [drivers/video] Error 2
> make[2]: *** [drivers] Error 2
> make[2]: Leaving directory `/usr/src/linux-2.6.10'
> make[1]: *** [stamp-build] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.6.10'
> make: *** [stamp-buildpackage] Error 2
> -
> Mail.be, WebMail and Virtual Office
> http://www.mail.be
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-
Mail.be, WebMail and Virtual Office
http://www.mail.be

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

kernel compile error in bootsplash.c

I try to compile a 2.6.10 kernel but it stops with an error
in bootsplash.c. I have everything set in my .config file in /usr/src/linux for 
bootsplash support. 

Anybody an idea. Where should i start to look? I am a newbie in kernel world

in file included from drivers/video/bootsplash/bootsplash.c:18:
include/linux/fb.h:869: error: array type has incomplete element type
drivers/video/bootsplash/bootsplash.c:37: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:38: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:39: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:40: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:41: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:42: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:43: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:44: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:45: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:46: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:47: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:48: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:49: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:50: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:52: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c: In function 'splash_verbose':
drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in passing 
argument 1 of 'splashcopy' differ in signedness
drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in passing 
argument 2 of 'splashcopy' differ in signedness
drivers/video/bootsplash/bootsplash.c: In function 'splash_prepare':
drivers/video/bootsplash/bootsplash.c:642: warning: pointer targets in passing 
argument 1 of 'splashcopy' differ in signedness
drivers/video/bootsplash/bootsplash.c: In function 'splash_write_proc':
drivers/video/bootsplash/bootsplash.c:788: warning: pointer targets in passing 
argument 1 of 'boxit' differ in signedness
drivers/video/bootsplash/bootsplash.c:789: warning: pointer targets in passing 
argument 1 of 'boxit' differ in signedness
make[5]: *** [drivers/video/bootsplash/bootsplash.o] Error 1
make[4]: *** [drivers/video/bootsplash] Error 2
make[3]: *** [drivers/video] Error 2
make[2]: *** [drivers] Error 2
make[2]: Leaving directory `/usr/src/linux-2.6.10'
make[1]: *** [stamp-build] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.10'
make: *** [stamp-buildpackage] Error 2
-
Mail.be, WebMail and Virtual Office
http://www.mail.be

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

kernel compile error in bootsplash.c

I try to compile a 2.6.10 kernel but it stops with an error
in bootsplash.c. I have everything set in my .config file in /usr/src/linux for 
bootsplash support. 

Anybody an idea. Where should i start to look? I am a newbie in kernel world

in file included from drivers/video/bootsplash/bootsplash.c:18:
include/linux/fb.h:869: error: array type has incomplete element type
drivers/video/bootsplash/bootsplash.c:37: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:38: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:39: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:40: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:41: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:42: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:43: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:44: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:45: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:46: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:47: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:48: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:49: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:50: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c:52: warning: pointer targets in 
initialization differ in signedness
drivers/video/bootsplash/bootsplash.c: In function 'splash_verbose':
drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in passing 
argument 1 of 'splashcopy' differ in signedness
drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in passing 
argument 2 of 'splashcopy' differ in signedness
drivers/video/bootsplash/bootsplash.c: In function 'splash_prepare':
drivers/video/bootsplash/bootsplash.c:642: warning: pointer targets in passing 
argument 1 of 'splashcopy' differ in signedness
drivers/video/bootsplash/bootsplash.c: In function 'splash_write_proc':
drivers/video/bootsplash/bootsplash.c:788: warning: pointer targets in passing 
argument 1 of 'boxit' differ in signedness
drivers/video/bootsplash/bootsplash.c:789: warning: pointer targets in passing 
argument 1 of 'boxit' differ in signedness
make[5]: *** [drivers/video/bootsplash/bootsplash.o] Error 1
make[4]: *** [drivers/video/bootsplash] Error 2
make[3]: *** [drivers/video] Error 2
make[2]: *** [drivers] Error 2
make[2]: Leaving directory `/usr/src/linux-2.6.10'
make[1]: *** [stamp-build] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.10'
make: *** [stamp-buildpackage] Error 2
-
Mail.be, WebMail and Virtual Office
http://www.mail.be

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel compile error in bootsplash.c

I googled some more and seem to have found the reason of the error:

http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html

It is related to gcc 4.0 which indeed i did an apt-get update for.

But is there a patch avail for my 2.6.10 kernel-source?

 
 
 I try to compile a 2.6.10 kernel but it stops with an error
 in bootsplash.c. I have everything set in my .config file in /usr/src/linux 
 for bootsplash support. 
 
 Anybody an idea. Where should i start to look? I am a newbie in kernel world
 
 in file included from drivers/video/bootsplash/bootsplash.c:18:
 include/linux/fb.h:869: error: array type has incomplete element type
 drivers/video/bootsplash/bootsplash.c:37: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:38: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:39: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:40: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:41: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:42: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:43: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:44: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:45: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:46: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:47: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:48: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:49: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:50: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:52: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c: In function 'splash_verbose':
 drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
 passing argument 1 of 'splashcopy' differ in signedness
 drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
 passing argument 2 of 'splashcopy' differ in signedness
 drivers/video/bootsplash/bootsplash.c: In function 'splash_prepare':
 drivers/video/bootsplash/bootsplash.c:642: warning: pointer targets in 
 passing argument 1 of 'splashcopy' differ in signedness
 drivers/video/bootsplash/bootsplash.c: In function 'splash_write_proc':
 drivers/video/bootsplash/bootsplash.c:788: warning: pointer targets in 
 passing argument 1 of 'boxit' differ in signedness
 drivers/video/bootsplash/bootsplash.c:789: warning: pointer targets in 
 passing argument 1 of 'boxit' differ in signedness
 make[5]: *** [drivers/video/bootsplash/bootsplash.o] Error 1
 make[4]: *** [drivers/video/bootsplash] Error 2
 make[3]: *** [drivers/video] Error 2
 make[2]: *** [drivers] Error 2
 make[2]: Leaving directory `/usr/src/linux-2.6.10'
 make[1]: *** [stamp-build] Error 2
 make[1]: Leaving directory `/usr/src/linux-2.6.10'
 make: *** [stamp-buildpackage] Error 2
 -
 Mail.be, WebMail and Virtual Office
 http://www.mail.be
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

-
Mail.be, WebMail and Virtual Office
http://www.mail.be

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel compile error in bootsplash.c

2005-08-27 Thread Randy.Dunlap

On Sat, 27 Aug 2005 19:53:35 +0200 (CEST) J. B. wrote:

 I try to compile a 2.6.10 kernel but it stops with an error
 in bootsplash.c. I have everything set in my .config file in /usr/src/linux 
 for bootsplash support. 
 
 Anybody an idea. Where should i start to look? I am a newbie in kernel world

This is in a vendor kernel, right?
So please take it up with that vendor.

Kernels from kernel.org don't contain drivers/video/bootsplash/*


 in file included from drivers/video/bootsplash/bootsplash.c:18:
 include/linux/fb.h:869: error: array type has incomplete element type
 drivers/video/bootsplash/bootsplash.c:37: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:38: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:39: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:40: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:41: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:42: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:43: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:44: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:45: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:46: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:47: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:48: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:49: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:50: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c:52: warning: pointer targets in 
 initialization differ in signedness
 drivers/video/bootsplash/bootsplash.c: In function 'splash_verbose':
 drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
 passing argument 1 of 'splashcopy' differ in signedness
 drivers/video/bootsplash/bootsplash.c:572: warning: pointer targets in 
 passing argument 2 of 'splashcopy' differ in signedness
 drivers/video/bootsplash/bootsplash.c: In function 'splash_prepare':
 drivers/video/bootsplash/bootsplash.c:642: warning: pointer targets in 
 passing argument 1 of 'splashcopy' differ in signedness
 drivers/video/bootsplash/bootsplash.c: In function 'splash_write_proc':
 drivers/video/bootsplash/bootsplash.c:788: warning: pointer targets in 
 passing argument 1 of 'boxit' differ in signedness
 drivers/video/bootsplash/bootsplash.c:789: warning: pointer targets in 
 passing argument 1 of 'boxit' differ in signedness
 make[5]: *** [drivers/video/bootsplash/bootsplash.o] Error 1
 make[4]: *** [drivers/video/bootsplash] Error 2
 make[3]: *** [drivers/video] Error 2
 make[2]: *** [drivers] Error 2
 make[2]: Leaving directory `/usr/src/linux-2.6.10'
 make[1]: *** [stamp-build] Error 2
 make[1]: Leaving directory `/usr/src/linux-2.6.10'
 make: *** [stamp-buildpackage] Error 2
 -


---
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel compile error in bootsplash.c