Re: [linux-pm] Re: [Resend][PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION (updated)
On Mon, 2007-08-06 at 13:56 +0200, Rafael J. Wysocki wrote: > On Monday, 6 August 2007 13:36, Pavel Machek wrote: > > On Mon 2007-08-06 13:15:17, Johannes Berg wrote: > > > On Mon, 2007-08-06 at 12:26 +0200, Pavel Machek wrote: > > > > > > > Well, so that it does not bitrot? This is few bytes, I'd say, and I > > > > believe we have too many config options already. > > > > > > This is not an option the user is ever going to see. I think I'd > > > prefer > > > > Ok, option that users can't set is probably not evil. > > > > > having two new per-ARCH config symbols though: > > > config SUSPEND_UP_POSSIBLE > > > depends on ARCH_SUSPEND_UP_POSSIBLE > > > > > > and then the architecture gets to define that when it can suspend. > > > > Looks like a plan. > > Hmm, why don't we do the $subject change first (the advantage if it is that > the patch is ready) and then move the necessary definitions to the arch level? Sounds good to me as well, that way we already have the basic stuff in place. Hey, we could even migrate over slowly by making SUSPEND_UP_POSSIBLE depend on ARCH_SUSPEND_UP_POSSIBLE *and* all the arches that support it right now. johannes signature.asc Description: This is a digitally signed message part
Re: [linux-pm] Re: [Resend][PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION (updated)
On Monday, 6 August 2007 13:36, Pavel Machek wrote: > On Mon 2007-08-06 13:15:17, Johannes Berg wrote: > > On Mon, 2007-08-06 at 12:26 +0200, Pavel Machek wrote: > > > > > Well, so that it does not bitrot? This is few bytes, I'd say, and I > > > believe we have too many config options already. > > > > This is not an option the user is ever going to see. I think I'd > > prefer > > Ok, option that users can't set is probably not evil. > > > having two new per-ARCH config symbols though: > > config SUSPEND_UP_POSSIBLE > > depends on ARCH_SUSPEND_UP_POSSIBLE > > > > and then the architecture gets to define that when it can suspend. > > Looks like a plan. Hmm, why don't we do the $subject change first (the advantage if it is that the patch is ready) and then move the necessary definitions to the arch level? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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: [linux-pm] Re: [Resend][PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION (updated)
On Mon 2007-08-06 13:15:17, Johannes Berg wrote: > On Mon, 2007-08-06 at 12:26 +0200, Pavel Machek wrote: > > > Well, so that it does not bitrot? This is few bytes, I'd say, and I > > believe we have too many config options already. > > This is not an option the user is ever going to see. I think I'd > prefer Ok, option that users can't set is probably not evil. > having two new per-ARCH config symbols though: > config SUSPEND_UP_POSSIBLE > depends on ARCH_SUSPEND_UP_POSSIBLE > > and then the architecture gets to define that when it can suspend. Looks like a plan. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: [linux-pm] Re: [Resend][PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION (updated)
On Mon, 2007-08-06 at 13:15 +0200, Johannes Berg wrote: > config SUSPEND_UP_POSSIBLE > depends on ARCH_SUSPEND_UP_POSSIBLE > > and then the architecture gets to define that when it can suspend. In fact, just doing depends on (ARCH_SUSPEND_UP_POSSIBLE && !SMP) || (ARCH_SUSPEND_SMP_POSSIBLE && SMP) would probably be good instead of doing the intermediate SUSPEND_UP_POSSIBLE and SUSPEND_SMP_POSSIBLE. The reason I like this better is that we don't have a central editing point where patches conflict causing unnecessary problems. But both are much better than what we have now anyway :) johannes signature.asc Description: This is a digitally signed message part
Re: [linux-pm] Re: [Resend][PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION (updated)
On Mon, 2007-08-06 at 12:26 +0200, Pavel Machek wrote: > Well, so that it does not bitrot? This is few bytes, I'd say, and I > believe we have too many config options already. This is not an option the user is ever going to see. I think I'd prefer having two new per-ARCH config symbols though: config SUSPEND_UP_POSSIBLE depends on ARCH_SUSPEND_UP_POSSIBLE and then the architecture gets to define that when it can suspend. johannes signature.asc Description: This is a digitally signed message part
Re: [linux-pm] Re: [Resend][PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION (updated)
On Mon 2007-08-06 11:29:51, Johannes Berg wrote: > On Mon, 2007-08-06 at 11:07 +0200, Pavel Machek wrote: > > Hi! > > > > > +config SUSPEND_UP_POSSIBLE > > > + bool > > > + depends on (X86 && !X86_VOYAGER) || (PPC32 && PPC_MPC52xx) \ > > > +|| (PPC64 && (PPC_PSERIES || PPC_PMAC)) || ARM || BLACKFIN \ > > > +|| MIPS || SUPERH || FRV > > > + depends on !SMP > > > + default y > > > > I guess I'd rather left SUSPEND_UP_POSSIBLE to allways y (as it always > > was), and let architectures that can't handle it not return "mem" > > from list of valid states... > > Yeah, that's the utterly broken interface we used to have. Until I fixed > it to have no valid states until architectures implement suspend_ops. > Still, I disagree, why bother with compiling code that can't ever be > used? Well, so that it does not bitrot? This is few bytes, I'd say, and I believe we have too many config options already. I do not think suspend_ops code is big enough to warrant separate config option... just disable CONFIG_PM or something. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: [linux-pm] Re: [Resend][PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION (updated)
On Monday, 6 August 2007 11:29, Johannes Berg wrote: > On Mon, 2007-08-06 at 11:07 +0200, Pavel Machek wrote: > > Hi! > > > > > +config SUSPEND_UP_POSSIBLE > > > + bool > > > + depends on (X86 && !X86_VOYAGER) || (PPC32 && PPC_MPC52xx) \ > > > +|| (PPC64 && (PPC_PSERIES || PPC_PMAC)) || ARM || BLACKFIN \ > > > +|| MIPS || SUPERH || FRV > > > + depends on !SMP > > > + default y > > > > I guess I'd rather left SUSPEND_UP_POSSIBLE to allways y (as it always > > was), and let architectures that can't handle it not return "mem" > > from list of valid states... > > Yeah, that's the utterly broken interface we used to have. Until I fixed > it to have no valid states until architectures implement suspend_ops. > Still, I disagree, why bother with compiling code that can't ever be > used? Yes, that's the idea. BTW, Pavel please see: http://lkml.org/lkml/2007/8/3/303 Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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: [linux-pm] Re: [Resend][PATCH] PM: Fix dependencies of CONFIG_SUSPEND and CONFIG_HIBERNATION (updated)
On Mon, 2007-08-06 at 11:07 +0200, Pavel Machek wrote: > Hi! > > > +config SUSPEND_UP_POSSIBLE > > + bool > > + depends on (X86 && !X86_VOYAGER) || (PPC32 && PPC_MPC52xx) \ > > + || (PPC64 && (PPC_PSERIES || PPC_PMAC)) || ARM || BLACKFIN \ > > + || MIPS || SUPERH || FRV > > + depends on !SMP > > + default y > > I guess I'd rather left SUSPEND_UP_POSSIBLE to allways y (as it always > was), and let architectures that can't handle it not return "mem" > from list of valid states... Yeah, that's the utterly broken interface we used to have. Until I fixed it to have no valid states until architectures implement suspend_ops. Still, I disagree, why bother with compiling code that can't ever be used? johannes signature.asc Description: This is a digitally signed message part
