On Tue, Jan 15, 2008 at 11:14:09PM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > > make ARCH=x86_64 allyesconfig
> > > will set CONFIG_64BIT for you - no?
> >
> > Yes.
> >
> > But this still leaves the fact that when someone says 'allyesconfig'
> > it's no
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > make ARCH=x86_64 allyesconfig
> > will set CONFIG_64BIT for you - no?
>
> Yes.
>
> But this still leaves the fact that when someone says 'allyesconfig'
> it's no longer clear which configuration he has. And no, I do not
> consider it funny that
On Tue, Jan 15, 2008 at 07:21:42PM +0100, Sam Ravnborg wrote:
>...
> > > And I will add a config option to:
> > > - set -fno-unit-at-a-time
> >
> > I was told future gcc versions would remove that. Why do you
> > want it?
> Are there any better way to tell gcc no to inline so agressively?
I
On Tue, Jan 15, 2008 at 07:29:04PM +0100, Andi Kleen wrote:
> On Tue, Jan 15, 2008 at 07:21:42PM +0100, Sam Ravnborg wrote:
> > With default options to gcc my .config produces ~65 warnings
> > but with -fno-unit-a-time I get 112 warnings.
> > Solely due to less inlining done by gcc.
> >
> > So
On Tue, Jan 15, 2008 at 07:21:42PM +0100, Sam Ravnborg wrote:
> With default options to gcc my .config produces ~65 warnings
> but with -fno-unit-a-time I get 112 warnings.
> Solely due to less inlining done by gcc.
>
> So there are two sources for the 'randomization':
> a) The actual config
> b)
> >
> > The plan is to let section mismatch warnings become errors
> > after the merge window - so we hit -mm first.
>
> A lot of those I look at seem to be not really bugs; also my
> impression is that they sometimes crop up randomly. e.g. you
> change something completely unrelated and
On Tue, Jan 15, 2008 at 06:11:46PM +0100, Andi Kleen wrote:
> On Tue, Jan 15, 2008 at 05:25:13PM +0100, Sam Ravnborg wrote:
> > On Tue, Jan 15, 2008 at 04:17:42PM +0100, Ingo Molnar wrote:
> > >
> > > * Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > >
> > > > > find below the current set of
On Tue, Jan 15, 2008 at 05:25:13PM +0100, Sam Ravnborg wrote:
> On Tue, Jan 15, 2008 at 04:17:42PM +0100, Ingo Molnar wrote:
> >
> > * Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> >
> > > > find below the current set of warnings on -git. There are 62.
> > >
> > > The correct figure is 112.
> > >
On Tue, Jan 15, 2008 at 04:17:42PM +0100, Ingo Molnar wrote:
>
> * Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > > find below the current set of warnings on -git. There are 62.
> >
> > The correct figure is 112.
> >
> > You need to do a:
> > make KCFLAGS=-fno-unit-at-a-time
> > build to see
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > find below the current set of warnings on -git. There are 62.
>
> The correct figure is 112.
>
> You need to do a:
> make KCFLAGS=-fno-unit-at-a-time
> build to see them all.
btw., please add a .config option to trigger the -fno-unit-at-a-time
* Sam Ravnborg [EMAIL PROTECTED] wrote:
find below the current set of warnings on -git. There are 62.
The correct figure is 112.
You need to do a:
make KCFLAGS=-fno-unit-at-a-time
build to see them all.
btw., please add a .config option to trigger the -fno-unit-at-a-time
flags.
On Tue, Jan 15, 2008 at 04:17:42PM +0100, Ingo Molnar wrote:
* Sam Ravnborg [EMAIL PROTECTED] wrote:
find below the current set of warnings on -git. There are 62.
The correct figure is 112.
You need to do a:
make KCFLAGS=-fno-unit-at-a-time
build to see them all.
btw.,
On Tue, Jan 15, 2008 at 05:25:13PM +0100, Sam Ravnborg wrote:
On Tue, Jan 15, 2008 at 04:17:42PM +0100, Ingo Molnar wrote:
* Sam Ravnborg [EMAIL PROTECTED] wrote:
find below the current set of warnings on -git. There are 62.
The correct figure is 112.
You need to do a:
On Tue, Jan 15, 2008 at 06:11:46PM +0100, Andi Kleen wrote:
On Tue, Jan 15, 2008 at 05:25:13PM +0100, Sam Ravnborg wrote:
On Tue, Jan 15, 2008 at 04:17:42PM +0100, Ingo Molnar wrote:
* Sam Ravnborg [EMAIL PROTECTED] wrote:
find below the current set of warnings on -git. There
The plan is to let section mismatch warnings become errors
after the merge window - so we hit -mm first.
A lot of those I look at seem to be not really bugs; also my
impression is that they sometimes crop up randomly. e.g. you
change something completely unrelated and suddenly you get
On Tue, Jan 15, 2008 at 07:21:42PM +0100, Sam Ravnborg wrote:
With default options to gcc my .config produces ~65 warnings
but with -fno-unit-a-time I get 112 warnings.
Solely due to less inlining done by gcc.
So there are two sources for the 'randomization':
a) The actual config
b) The
On Tue, Jan 15, 2008 at 07:29:04PM +0100, Andi Kleen wrote:
On Tue, Jan 15, 2008 at 07:21:42PM +0100, Sam Ravnborg wrote:
With default options to gcc my .config produces ~65 warnings
but with -fno-unit-a-time I get 112 warnings.
Solely due to less inlining done by gcc.
So there are two
On Tue, Jan 15, 2008 at 07:21:42PM +0100, Sam Ravnborg wrote:
...
And I will add a config option to:
- set -fno-unit-at-a-time
I was told future gcc versions would remove that. Why do you
want it?
Are there any better way to tell gcc no to inline so agressively?
I haven't tested it,
* Adrian Bunk [EMAIL PROTECTED] wrote:
make ARCH=x86_64 allyesconfig
will set CONFIG_64BIT for you - no?
Yes.
But this still leaves the fact that when someone says 'allyesconfig'
it's no longer clear which configuration he has. And no, I do not
consider it funny that this now
On Tue, Jan 15, 2008 at 11:14:09PM +0100, Ingo Molnar wrote:
* Adrian Bunk [EMAIL PROTECTED] wrote:
make ARCH=x86_64 allyesconfig
will set CONFIG_64BIT for you - no?
Yes.
But this still leaves the fact that when someone says 'allyesconfig'
it's no longer clear which
On Mon, Jan 14, 2008 at 09:27:40PM +0100, Sam Ravnborg wrote:
> > > > Can you fix the bug that menuconfig does not let me enable CONFIG_64BIT?
> > >
> > > make ARCH=x86_64 allyesconfig
> > > will set CONFIG_64BIT for you - no?
> >
> > Yes.
> >
> > But this still leaves the fact that when
> > > Can you fix the bug that menuconfig does not let me enable CONFIG_64BIT?
> >
> > make ARCH=x86_64 allyesconfig
> > will set CONFIG_64BIT for you - no?
>
> Yes.
>
> But this still leaves the fact that when someone says 'allyesconfig'
> it's no longer clear which configuration he has.
On Mon, Jan 14, 2008 at 09:01:26PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 14, 2008 at 09:52:58PM +0200, Adrian Bunk wrote:
> > On Mon, Jan 14, 2008 at 08:10:09PM +0100, Ingo Molnar wrote:
> > >
> > > * Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > > > > for example, in current -git, could
On Mon, Jan 14, 2008 at 04:24:40PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > also, in theory we've got a pretty reliable set of the following
> > information:
> >
> > function X references symbol Y
> >
> > and we know what type of sections they are in,
On Mon, Jan 14, 2008 at 09:52:58PM +0200, Adrian Bunk wrote:
> On Mon, Jan 14, 2008 at 08:10:09PM +0100, Ingo Molnar wrote:
> >
> > * Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > > for example, in current -git, could you tell me why this triggers:
> > > >
> > > > WARNING:
On Mon, Jan 14, 2008 at 04:01:03PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Would be great to have them automated - just dunno how to do it. Do
> > > you see a feasible way to do it?
> >
> > a good starting point would be to make the warnings a lot more
>
On Mon, Jan 14, 2008 at 08:10:09PM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > > for example, in current -git, could you tell me why this triggers:
> > >
> > > WARNING: vmlinux.o(.text+0x87e2a): Section mismatch: reference to
> > > .init.text:
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > for example, in current -git, could you tell me why this triggers:
> >
> > WARNING: vmlinux.o(.text+0x87e2a): Section mismatch: reference to
> > .init.text: (between 'process_zones' and 'setup_per_cpu_pageset')
> >
> > and how to resolve
On Mon, Jan 14, 2008 at 04:01:03PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > Would be great to have them automated - just dunno how to do it. Do
> > > you see a feasible way to do it?
> >
> > a good starting point would be to make the warnings a lot more
>
On Mon, Jan 14, 2008 at 03:58:54PM +0100, Ingo Molnar wrote:
>...
> a good way i see is to:
>...
> - quickly reach a close-to-100%-perfect stage, brute-force. Drop
>__init* annotations en masse if they are not perfectly layered.
>Whoever reintroduces them will then have to do it
On Mon, Jan 14, 2008 at 02:52:40PM +0100, Ingo Molnar wrote:
>...
> but longer-term, shouldnt these annotations be automated? We'll see a
> constant stream of them, all around the clock as people regularly get it
> wrong (because it's not intuitive).
Definitely.
Even more when you looking at
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> also, in theory we've got a pretty reliable set of the following
> information:
>
> function X references symbol Y
>
> and we know what type of sections they are in, right?
>
> could -ffunction-sections be used to delay the categorization of
>
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Would be great to have them automated - just dunno how to do it. Do
> > you see a feasible way to do it?
>
> a good starting point would be to make the warnings a lot more
> self-explanatory. Right now it's often non-obvious trying to figure
> out
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Would be great to have them automated - just dunno how to do it. Do
> > you see a feasible way to do it?
>
> a good starting point would be to make the warnings a lot more
> self-explanatory. Right now it's often non-obvious trying to figure
> out
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > ok, i've dropped this patch from x86.git for now:
> >
> > Subject: x86: force __cpuinit on for CONFIG_PM without HOTPLUG_CPU
> > From: Andi Kleen <[EMAIL PROTECTED]>
> >
> > but longer-term, shouldnt these annotations be automated? We'll see
> >
On Mon, Jan 14, 2008 at 02:52:40PM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
> > > Adrian Bunk <[EMAIL PROTECTED]> writes:
> > > >
> > > > Technically you are the one who has to deal with problems in
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
> > Adrian Bunk <[EMAIL PROTECTED]> writes:
> > >
> > > Technically you are the one who has to deal with problems in your
> > > patches, not the people pointing at the problems.
> >
> > If
* Adrian Bunk [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
Adrian Bunk [EMAIL PROTECTED] writes:
Technically you are the one who has to deal with problems in your
patches, not the people pointing at the problems.
If you believe that my
On Mon, Jan 14, 2008 at 02:52:40PM +0100, Ingo Molnar wrote:
* Adrian Bunk [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
Adrian Bunk [EMAIL PROTECTED] writes:
Technically you are the one who has to deal with problems in your
patches,
* Ingo Molnar [EMAIL PROTECTED] wrote:
Would be great to have them automated - just dunno how to do it. Do
you see a feasible way to do it?
a good starting point would be to make the warnings a lot more
self-explanatory. Right now it's often non-obvious trying to figure
out how the
* Ingo Molnar [EMAIL PROTECTED] wrote:
also, in theory we've got a pretty reliable set of the following
information:
function X references symbol Y
and we know what type of sections they are in, right?
could -ffunction-sections be used to delay the categorization of
functions to
On Mon, Jan 14, 2008 at 02:52:40PM +0100, Ingo Molnar wrote:
...
but longer-term, shouldnt these annotations be automated? We'll see a
constant stream of them, all around the clock as people regularly get it
wrong (because it's not intuitive).
Definitely.
Even more when you looking at what
* Sam Ravnborg [EMAIL PROTECTED] wrote:
ok, i've dropped this patch from x86.git for now:
Subject: x86: force __cpuinit on for CONFIG_PM without HOTPLUG_CPU
From: Andi Kleen [EMAIL PROTECTED]
but longer-term, shouldnt these annotations be automated? We'll see
a constant stream
* Adrian Bunk [EMAIL PROTECTED] wrote:
for example, in current -git, could you tell me why this triggers:
WARNING: vmlinux.o(.text+0x87e2a): Section mismatch: reference to
.init.text: (between 'process_zones' and 'setup_per_cpu_pageset')
and how to resolve it? I had a
On Mon, Jan 14, 2008 at 08:10:09PM +0100, Ingo Molnar wrote:
* Adrian Bunk [EMAIL PROTECTED] wrote:
for example, in current -git, could you tell me why this triggers:
WARNING: vmlinux.o(.text+0x87e2a): Section mismatch: reference to
.init.text: (between
On Mon, Jan 14, 2008 at 04:24:40PM +0100, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
also, in theory we've got a pretty reliable set of the following
information:
function X references symbol Y
and we know what type of sections they are in, right?
could
On Mon, Jan 14, 2008 at 09:01:26PM +0100, Sam Ravnborg wrote:
On Mon, Jan 14, 2008 at 09:52:58PM +0200, Adrian Bunk wrote:
On Mon, Jan 14, 2008 at 08:10:09PM +0100, Ingo Molnar wrote:
* Adrian Bunk [EMAIL PROTECTED] wrote:
for example, in current -git, could you tell me why this
Can you fix the bug that menuconfig does not let me enable CONFIG_64BIT?
make ARCH=x86_64 allyesconfig
will set CONFIG_64BIT for you - no?
Yes.
But this still leaves the fact that when someone says 'allyesconfig'
it's no longer clear which configuration he has.
Assuming you are
On Mon, Jan 14, 2008 at 04:01:03PM +0100, Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
Would be great to have them automated - just dunno how to do it. Do
you see a feasible way to do it?
a good starting point would be to make the warnings a lot more
On Mon, Jan 14, 2008 at 09:27:40PM +0100, Sam Ravnborg wrote:
Can you fix the bug that menuconfig does not let me enable CONFIG_64BIT?
make ARCH=x86_64 allyesconfig
will set CONFIG_64BIT for you - no?
Yes.
But this still leaves the fact that when someone says 'allyesconfig'
On Thursday, 10 of January 2008, Andi Kleen wrote:
> On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
> > On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
> > > > But your patch does:
> > > >
> > > > +config PM_CPUINIT
> > > > + bool
> > > > + depends on PM
> > >
>
[Sorry for not replying earlier, I missed your message.]
On Friday, 4 of January 2008, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > So you would need to fix that first. Would be fine for me, but is
> > > out of scope for my patch.
> >
> > OK, I'll fix that up
On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
> Adrian Bunk <[EMAIL PROTECTED]> writes:
> >
> > Technically you are the one who has to deal with problems in your
> > patches, not the people pointing at the problems.
>
> If you believe that my patch adds a new problem then please
Adrian Bunk <[EMAIL PROTECTED]> writes:
>
> Technically you are the one who has to deal with problems in your
> patches, not the people pointing at the problems.
If you believe that my patch adds a new problem then please describe
it clearly so that I can understand it.
-Andi
--
To unsubscribe
On Thu, Jan 10, 2008 at 12:42:53PM +0100, Andi Kleen wrote:
> On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
> > On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
> > > > But your patch does:
> > > >
> > > > +config PM_CPUINIT
> > > > + bool
> > > > + depends on PM
On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
> On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
> > > But your patch does:
> > >
> > > +config PM_CPUINIT
> > > + bool
> > > + depends on PM
> >
> > That is because arch/x86/power/cpu.c where this happens is
On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
> > But your patch does:
> >
> > +config PM_CPUINIT
> > + bool
> > + depends on PM
>
> That is because arch/x86/power/cpu.c where this happens is currently
>
> obj-$(CONFIG_PM)+= cpu.o
>
> If it was changed
> But your patch does:
>
> +config PM_CPUINIT
> + bool
> + depends on PM
That is because arch/x86/power/cpu.c where this happens is currently
obj-$(CONFIG_PM)+= cpu.o
If it was changed to CONFIG_something else then yes that dependency
should be changed too.
-Andi
On Thu, Jan 10, 2008 at 10:58:57AM +0100, Andi Kleen wrote:
> > It seems the correct solution would be not to hijack __cpuinit
> > (as your patch does), but to create a new annotation.
>
> The rationale is that after suspend the CPU has to be reinitialized.
> That is because it is essentially
> It seems the correct solution would be not to hijack __cpuinit
> (as your patch does), but to create a new annotation.
The rationale is that after suspend the CPU has to be reinitialized.
That is because it is essentially like a reboot. All the previous
CPU state is gone.
It doesn't need to
On Thu, Jan 03, 2008 at 07:43:43PM +0100, Andi Kleen wrote:
> On Thursday 03 January 2008 19:14:38 Adrian Bunk wrote:
> > On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote:
> > >
> > > This avoids the requirement to mark a lot of initialization functions not
> > > __cpuinit just for
It seems the correct solution would be not to hijack __cpuinit
(as your patch does), but to create a new annotation.
The rationale is that after suspend the CPU has to be reinitialized.
That is because it is essentially like a reboot. All the previous
CPU state is gone.
It doesn't need to
On Thu, Jan 03, 2008 at 07:43:43PM +0100, Andi Kleen wrote:
On Thursday 03 January 2008 19:14:38 Adrian Bunk wrote:
On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote:
This avoids the requirement to mark a lot of initialization functions not
__cpuinit just for resume from
On Thu, Jan 10, 2008 at 10:58:57AM +0100, Andi Kleen wrote:
It seems the correct solution would be not to hijack __cpuinit
(as your patch does), but to create a new annotation.
The rationale is that after suspend the CPU has to be reinitialized.
That is because it is essentially like a
But your patch does:
+config PM_CPUINIT
+ bool
+ depends on PM
That is because arch/x86/power/cpu.c where this happens is currently
obj-$(CONFIG_PM)+= cpu.o
If it was changed to CONFIG_something else then yes that dependency
should be changed too.
-Andi
--
To
On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
But your patch does:
+config PM_CPUINIT
+ bool
+ depends on PM
That is because arch/x86/power/cpu.c where this happens is currently
obj-$(CONFIG_PM)+= cpu.o
If it was changed to
On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
But your patch does:
+config PM_CPUINIT
+ bool
+ depends on PM
That is because arch/x86/power/cpu.c where this happens is currently
On Thu, Jan 10, 2008 at 12:42:53PM +0100, Andi Kleen wrote:
On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
But your patch does:
+config PM_CPUINIT
+ bool
+ depends on PM
That is because
Adrian Bunk [EMAIL PROTECTED] writes:
Technically you are the one who has to deal with problems in your
patches, not the people pointing at the problems.
If you believe that my patch adds a new problem then please describe
it clearly so that I can understand it.
-Andi
--
To unsubscribe from
On Thu, Jan 10, 2008 at 02:12:59PM +0100, Andi Kleen wrote:
Adrian Bunk [EMAIL PROTECTED] writes:
Technically you are the one who has to deal with problems in your
patches, not the people pointing at the problems.
If you believe that my patch adds a new problem then please describe
it
[Sorry for not replying earlier, I missed your message.]
On Friday, 4 of January 2008, Ingo Molnar wrote:
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
So you would need to fix that first. Would be fine for me, but is
out of scope for my patch.
OK, I'll fix that up later.
i'll
On Thursday, 10 of January 2008, Andi Kleen wrote:
On Thursday 10 January 2008 12:26:07 Adrian Bunk wrote:
On Thu, Jan 10, 2008 at 12:15:15PM +0100, Andi Kleen wrote:
But your patch does:
+config PM_CPUINIT
+ bool
+ depends on PM
That is because
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > So you would need to fix that first. Would be fine for me, but is
> > out of scope for my patch.
>
> OK, I'll fix that up later.
i'll apply Andi's patch to x86.git - or would like to maintain that
patch?
Ingo
--
To unsubscribe from
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
So you would need to fix that first. Would be fine for me, but is
out of scope for my patch.
OK, I'll fix that up later.
i'll apply Andi's patch to x86.git - or would like to maintain that
patch?
Ingo
--
To unsubscribe from this
On Thursday, 3 of January 2008, Andi Kleen wrote:
>
> > > +config PM_CPUINIT
> > > + bool
> > > + depends on PM
> >
> > Please make it PM_SLEEP (PM is more than suspend/hibernation).
>
> That was something that irritated me too while writing the patch, but the
> functions I
> am interested in
On Thursday 03 January 2008 19:14:38 Adrian Bunk wrote:
> On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote:
> >
> > This avoids the requirement to mark a lot of initialization functions not
> > __cpuinit just for resume from RAM.
> >
> > More functions could be converted now, didn't
On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote:
>
> This avoids the requirement to mark a lot of initialization functions not
> __cpuinit just for resume from RAM.
>
> More functions could be converted now, didn't do all.
>...
Shouldn't this aready be handled by the following?
> > +config PM_CPUINIT
> > + bool
> > + depends on PM
>
> Please make it PM_SLEEP (PM is more than suspend/hibernation).
That was something that irritated me too while writing the patch, but the
functions I
am interested in with this are referenced from arch/x86/power/cpu.c and that is
On Thursday, 3 of January 2008, Andi Kleen wrote:
>
> This avoids the requirement to mark a lot of initialization functions not
> __cpuinit just for resume from RAM.
>
> More functions could be converted now, didn't do all.
>
> Cc: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
>
> Signed-off-by:
This avoids the requirement to mark a lot of initialization functions not
__cpuinit just for resume from RAM.
More functions could be converted now, didn't do all.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/Kconfig|
This avoids the requirement to mark a lot of initialization functions not
__cpuinit just for resume from RAM.
More functions could be converted now, didn't do all.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
arch/x86/Kconfig|
On Thursday, 3 of January 2008, Andi Kleen wrote:
This avoids the requirement to mark a lot of initialization functions not
__cpuinit just for resume from RAM.
More functions could be converted now, didn't do all.
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andi Kleen
+config PM_CPUINIT
+ bool
+ depends on PM
Please make it PM_SLEEP (PM is more than suspend/hibernation).
That was something that irritated me too while writing the patch, but the
functions I
am interested in with this are referenced from arch/x86/power/cpu.c and that is
On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote:
This avoids the requirement to mark a lot of initialization functions not
__cpuinit just for resume from RAM.
More functions could be converted now, didn't do all.
...
Shouldn't this aready be handled by the following?
config
On Thursday 03 January 2008 19:14:38 Adrian Bunk wrote:
On Thu, Jan 03, 2008 at 04:42:29PM +0100, Andi Kleen wrote:
This avoids the requirement to mark a lot of initialization functions not
__cpuinit just for resume from RAM.
More functions could be converted now, didn't do all.
...
On Thursday, 3 of January 2008, Andi Kleen wrote:
+config PM_CPUINIT
+ bool
+ depends on PM
Please make it PM_SLEEP (PM is more than suspend/hibernation).
That was something that irritated me too while writing the patch, but the
functions I
am interested in with this are
86 matches
Mail list logo
