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 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. > > > > > > Then fix this first. > > Rafael indicated he would do that, but it is really outside the scope > of my patch. I was just interested in fixing a linker warning.
Your patch description doesn't mention any linker warning. Can you send the linker warning so that we can see the problem and not only the patch you wrote for fixing the undisclosed problem? > > And the following other points you didn't bother to reply to also still > > stand even after this fix: > > - already __cpuinit code will waste memory with CONFIG_PM_SLEEP=y > > Don't know what your point is. Anyways if you think there is a problem > somewhere please feel free to write patches. Technically you are the one who has to deal with problems in your patches, not the people pointing at the problems. > > - change shouldn't be x86 specific > > CPU initialization is deeply architecture specific. I don't see much use > in generalizing that. That the code is architecture specific is clear. But how to best annotate suspend and CPU hotplug code is a problem that is shared between many architectures and whose solution should not be architecture specific. > -Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- 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/