Re: [PATCH][RFC] Kill off legacy power management stuff.
On Wednesday 18 April 2007 20:35, Robert P. J. Day wrote: > On Wed, 18 Apr 2007, Dave Jones wrote: > > > On Wed, Apr 18, 2007 at 05:23:15PM -0400, Len Brown wrote: > > > > > > p.p.s. patch improvements that will let me avoid doing any of that > > > > myself always welcome. :-) > > > > > > well, I'm sorry that I've known about the APM issue for a long time > > > and done nothing about it. I did ping davej when he broke it, > > > but his to-do list is probably even longer than mine. > > > > ping timeout. > > > > I don't recall too many of the details surrounding those changes, > > but I certainly won't stand in the way of anyone trying to fix it. > > It sounds like you and Robert are on top of it, or do you want me to > > poke at it ? > > well, before i get even more confused by what was (once upon a time) a > fairly straightforward removal patch, the first obvious question is -- > are there *any* circumstances that *require* a config selection of > CONFIG_PM_LEGACY, as opposed to a selection of APM and/or ACPI? if > there are, then it can't simply be removed. my original patch > submission was based on the assumption that absolutely no one needed > the legacy stuff anymore and absolutely everything related to it could > be scrapped. > > so, first things first: what *needs* legacy PM at the moment? > > rday > > p.s. i'm confused by the header file include/linux/pm_legacy.h, > especially this part: > > > #ifdef CONFIG_PM_LEGACY > ... > # else /* CONFIG_PM_LEGACY */ > > #define PM_IS_ACTIVE() 0 > ... > #endif > === > > so the macro "PM_IS_ACTIVE()" represents whether *legacy* PM has > been selected. in other words, it makes no (apparent) sense that the > value of that macro would represent some kind of contention mechanism > between APM and ACPI, which is entirely independent from the legacy > stuff. right? yep, the problem is that PM_IS_ACTIVE() got mixed up in CONFIG_PM_LEGACY. how about i send a patch to fix this first -- when i get back tomorrow. and then the CONFIG_PM_LEGACY patch will not be tangled in this? -Len - 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][RFC] Kill off legacy power management stuff.
On Wednesday 18 April 2007 20:35, Robert P. J. Day wrote: On Wed, 18 Apr 2007, Dave Jones wrote: On Wed, Apr 18, 2007 at 05:23:15PM -0400, Len Brown wrote: p.p.s. patch improvements that will let me avoid doing any of that myself always welcome. :-) well, I'm sorry that I've known about the APM issue for a long time and done nothing about it. I did ping davej when he broke it, but his to-do list is probably even longer than mine. ping timeout. I don't recall too many of the details surrounding those changes, but I certainly won't stand in the way of anyone trying to fix it. It sounds like you and Robert are on top of it, or do you want me to poke at it ? well, before i get even more confused by what was (once upon a time) a fairly straightforward removal patch, the first obvious question is -- are there *any* circumstances that *require* a config selection of CONFIG_PM_LEGACY, as opposed to a selection of APM and/or ACPI? if there are, then it can't simply be removed. my original patch submission was based on the assumption that absolutely no one needed the legacy stuff anymore and absolutely everything related to it could be scrapped. so, first things first: what *needs* legacy PM at the moment? rday p.s. i'm confused by the header file include/linux/pm_legacy.h, especially this part: #ifdef CONFIG_PM_LEGACY ... # else /* CONFIG_PM_LEGACY */ #define PM_IS_ACTIVE() 0 ... #endif === so the macro PM_IS_ACTIVE() represents whether *legacy* PM has been selected. in other words, it makes no (apparent) sense that the value of that macro would represent some kind of contention mechanism between APM and ACPI, which is entirely independent from the legacy stuff. right? yep, the problem is that PM_IS_ACTIVE() got mixed up in CONFIG_PM_LEGACY. how about i send a patch to fix this first -- when i get back tomorrow. and then the CONFIG_PM_LEGACY patch will not be tangled in this? -Len - 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][RFC] Kill off legacy power management stuff.
On Wed, 18 Apr 2007, Dave Jones wrote: > On Wed, Apr 18, 2007 at 05:23:15PM -0400, Len Brown wrote: > > > > p.p.s. patch improvements that will let me avoid doing any of that > > > myself always welcome. :-) > > > > well, I'm sorry that I've known about the APM issue for a long time > > and done nothing about it. I did ping davej when he broke it, > > but his to-do list is probably even longer than mine. > > ping timeout. > > I don't recall too many of the details surrounding those changes, > but I certainly won't stand in the way of anyone trying to fix it. > It sounds like you and Robert are on top of it, or do you want me to > poke at it ? well, before i get even more confused by what was (once upon a time) a fairly straightforward removal patch, the first obvious question is -- are there *any* circumstances that *require* a config selection of CONFIG_PM_LEGACY, as opposed to a selection of APM and/or ACPI? if there are, then it can't simply be removed. my original patch submission was based on the assumption that absolutely no one needed the legacy stuff anymore and absolutely everything related to it could be scrapped. so, first things first: what *needs* legacy PM at the moment? rday p.s. i'm confused by the header file include/linux/pm_legacy.h, especially this part: #ifdef CONFIG_PM_LEGACY ... # else /* CONFIG_PM_LEGACY */ #define PM_IS_ACTIVE() 0 ... #endif === so the macro "PM_IS_ACTIVE()" represents whether *legacy* PM has been selected. in other words, it makes no (apparent) sense that the value of that macro would represent some kind of contention mechanism between APM and ACPI, which is entirely independent from the legacy stuff. right? -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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][RFC] Kill off legacy power management stuff.
On Wed, Apr 18, 2007 at 05:23:15PM -0400, Len Brown wrote: > > p.p.s. patch improvements that will let me avoid doing any of that > > myself always welcome. :-) > > well, I'm sorry that I've known about the APM issue for a long time > and done nothing about it. I did ping davej when he broke it, > but his to-do list is probably even longer than mine. ping timeout. I don't recall too many of the details surrounding those changes, but I certainly won't stand in the way of anyone trying to fix it. It sounds like you and Robert are on top of it, or do you want me to poke at 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][RFC] Kill off legacy power management stuff.
On Wed, 18 Apr 2007, Len Brown wrote: > On Wednesday 18 April 2007 16:23, Robert P. J. Day wrote: > > ok, i get it now and -- correct me if i'm wrong -- all my legacy PM > > removal patch was doing was exposing a design boo-boo in which > > APM/ACPI contention was being handled by a macro in a subsystem even > > older than either of them, right? > > yeah, it didn't start out that way, the bug was added when the > CONFIG_PM_LEGACY #define was added. > > > so all that needs to be done is add back in a contention solution > > of some kind that doesn't rely on that ancient system, yes? > > Yes, it is a matter of making the variable not go away when the > #define goes away. > > > as for that thinkpad t30 situation, well, that's just borked, and > > should be fixed. > > yes, the actual failure is that APM mode on the T30 hangs -- and > that is independent of the issue at hand. However, there could be > other failures on other machines when both APM and ACPI think they > are active. at this point, i think the proper approach is to locate and remove all dependencies on the legacy PM code, which includes making sure there's a reliable contention mechanism for APM and ACPI that doesn't need anything out of the legacy code or header files. once that's done, the legacy deletion itself should be trivial. the obvious place for the contention stuff is, i would think, include/linux/pm.h, yes? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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][RFC] Kill off legacy power management stuff.
On Wednesday 18 April 2007 16:23, Robert P. J. Day wrote: > On Wed, 18 Apr 2007, Len Brown wrote: > > Here is how it should work. CONFIG_ACPI and CONFIG_APM should both > > available in a kernel build. However, at boot time, of ACPI is > > active, then APM should be disabled. > > > > The pm_active flag used to handle this, but that method was BROKEN > > when the CONFIG_PM_LEGACY #define was added. Today, there are > > systems (such as the Thinkpad T30) that will not boot if > > CONFIG_PM_LEGACY is not defined. The reason nobody is complaining > > is because the distros are currently defining CONFIG_PM_LEGACY. > > But when you nuke that option and everything under it, this bug will > > be exposed and some systems will stop booting. > > ok, i get it now and -- correct me if i'm wrong -- all my legacy PM > removal patch was doing was exposing a design boo-boo in which > APM/ACPI contention was being handled by a macro in a subsystem even > older than either of them, right? yeah, it didn't start out that way, the bug was added when the CONFIG_PM_LEGACY #define was added. > so all that needs to be done is add > back in a contention solution of some kind that doesn't rely on that > ancient system, yes? Yes, it is a matter of making the variable not go away when the #define goes away. > as for that thinkpad t30 situation, well, that's just borked, and > should be fixed. yes, the actual failure is that APM mode on the T30 hangs -- and that is independent of the issue at hand. However, there could be other failures on other machines when both APM and ACPI think they are active. > rday > > p.s. at the risk of repeating myself repetitively, do we now agree > that what i was trying to remove *was* adequately ancient? although > it's clear that it has to be done slightly more carefully than was > done in my initial patch. yes, I think so. > p.p.s. patch improvements that will let me avoid doing any of that > myself always welcome. :-) well, I'm sorry that I've known about the APM issue for a long time and done nothing about it. I did ping davej when he broke it, but his to-do list is probably even longer than mine. -Len - 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: {Spam?} Re: [PATCH][RFC] Kill off legacy power management stuff.
On Wed, 18 Apr 2007, Len Brown wrote:
> On Saturday 14 April 2007 09:01, Robert P. J. Day wrote:
> > On Fri, 13 Apr 2007, Stephen Rothwell wrote:
> >
> > > On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) "Robert P. J. Day" <[EMAIL
> > > PROTECTED]> wrote:
> > > >
> > > > On Fri, 13 Apr 2007, Stephen Rothwell wrote:
> > > > >
> > > > > One thing that comes to mind is that you will need some way to
> > > > > make sure that only one of ACPI and APM get initialized ...
> > > >
> > > > i don't see how that has anything to do with removing legacy PM
> > > > support. you can select both ACPI and APM *now*. if that's a bad
> > > > thing, then fixing it is a completely independent issue.
> > >
> > > Except your patch removes this hunk:
> > >
> > > @@ -2264,14 +2248,6 @@ static int __init apm_init(void)
> > > apm_info.disabled = 1;
> > > return -ENODEV;
> > > }
> > > - if (PM_IS_ACTIVE()) {
> > > - printk(KERN_NOTICE "apm: overridden by ACPI.\n");
> > > - apm_info.disabled = 1;
> > > - return -ENODEV;
> > > - }
> > > -#ifdef CONFIG_PM_LEGACY
> > > - pm_active = 1;
> > > -#endif
> > >
> > > in apm.c and a similar piece of the ACPI initialisation that
> > > prevented one initialising if the other had already initialised.
> >
> > ah, just took a closer look at this. from :
> > ...
> > #ifdef CONFIG_PM_LEGACY
> > ...
> > #else
> > #define PM_IS_ACTIVE() 0
> > ...
> > #endif
> >
> > so if you choose not to configure legacy PM, that macro equates to
> > false and that "if" construct in arch/i386/kernel/apm.c doesn't
> > come into play, anyway.
> >
> > so i re-iterate what i posted in my earlier e-mail -- if APM and
> > ACPI want to avoid clashing, they have to do it without invoking
> > anything related to legacy PM.
>
> Here is how it should work. CONFIG_ACPI and CONFIG_APM should both
> available in a kernel build. However, at boot time, of ACPI is
> active, then APM should be disabled.
>
> The pm_active flag used to handle this, but that method was BROKEN
> when the CONFIG_PM_LEGACY #define was added. Today, there are
> systems (such as the Thinkpad T30) that will not boot if
> CONFIG_PM_LEGACY is not defined. The reason nobody is complaining
> is because the distros are currently defining CONFIG_PM_LEGACY.
> But when you nuke that option and everything under it, this bug will
> be exposed and some systems will stop booting.
ok, i get it now and -- correct me if i'm wrong -- all my legacy PM
removal patch was doing was exposing a design boo-boo in which
APM/ACPI contention was being handled by a macro in a subsystem even
older than either of them, right? so all that needs to be done is add
back in a contention solution of some kind that doesn't rely on that
ancient system, yes?
as for that thinkpad t30 situation, well, that's just borked, and
should be fixed.
rday
p.s. at the risk of repeating myself repetitively, do we now agree
that what i was trying to remove *was* adequately ancient? although
it's clear that it has to be done slightly more carefully than was
done in my initial patch.
p.p.s. patch improvements that will let me avoid doing any of that
myself always welcome. :-)
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
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][RFC] Kill off legacy power management stuff.
Hi! > >>One reason was that there are (were?) a number of machines which only > >>powered > >>down properly using apm. It was discussed as part of shutting down after > >>power > >>failure when your UPS is running out of power. > >> > > > >um ... what does APM have to do with legacy PM? two different issues, > >no? > > > Since the patches are going into apm.c and apm was used for suspend and > poweroff before ACPI was a feature of the hardware, I assume there's a > relationship. As of 2.6.9 ACPI still couldn't power down one of my >old There is not. The patches should not affect you unless you use obscure 68000 driver. We are removing infrastructure that has no users. 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: {Spam?} Re: [PATCH][RFC] Kill off legacy power management stuff.
On Saturday 14 April 2007 09:01, Robert P. J. Day wrote:
> On Fri, 13 Apr 2007, Stephen Rothwell wrote:
>
> > On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) "Robert P. J. Day" <[EMAIL
> > PROTECTED]> wrote:
> > >
> > > On Fri, 13 Apr 2007, Stephen Rothwell wrote:
> > > >
> > > > One thing that comes to mind is that you will need some way to
> > > > make sure that only one of ACPI and APM get initialized ...
> > >
> > > i don't see how that has anything to do with removing legacy PM
> > > support. you can select both ACPI and APM *now*. if that's a bad
> > > thing, then fixing it is a completely independent issue.
> >
> > Except your patch removes this hunk:
> >
> > @@ -2264,14 +2248,6 @@ static int __init apm_init(void)
> > apm_info.disabled = 1;
> > return -ENODEV;
> > }
> > - if (PM_IS_ACTIVE()) {
> > - printk(KERN_NOTICE "apm: overridden by ACPI.\n");
> > - apm_info.disabled = 1;
> > - return -ENODEV;
> > - }
> > -#ifdef CONFIG_PM_LEGACY
> > - pm_active = 1;
> > -#endif
> >
> > in apm.c and a similar piece of the ACPI initialisation that
> > prevented one initialising if the other had already initialised.
>
> ah, just took a closer look at this. from :
> ...
> #ifdef CONFIG_PM_LEGACY
> ...
> #else
> #define PM_IS_ACTIVE() 0
> ...
> #endif
>
> so if you choose not to configure legacy PM, that macro equates to
> false and that "if" construct in arch/i386/kernel/apm.c doesn't come
> into play, anyway.
>
> so i re-iterate what i posted in my earlier e-mail -- if APM and ACPI
> want to avoid clashing, they have to do it without invoking anything
> related to legacy PM.
Here is how it should work.
CONFIG_ACPI and CONFIG_APM should both available in a kernel build.
However, at boot time, of ACPI is active, then APM should be disabled.
The pm_active flag used to handle this, but that method was BROKEN
when the CONFIG_PM_LEGACY #define was added. Today, there are systems
(such as the Thinkpad T30) that will not boot if CONFIG_PM_LEGACY
is not defined. The reason nobody is complaining is because the distros
are currently defining CONFIG_PM_LEGACY. But when you nuke that option
and everything under it, this bug will be exposed and some systems will stop
booting.
-Len
-
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][RFC] Kill off legacy power management stuff.
On Wed, 18 Apr 2007, Bill Davidsen wrote: > Robert P. J. Day wrote: ... > > um ... what does APM have to do with legacy PM? two different > > issues, no? > Since the patches are going into apm.c and apm was used for suspend > and poweroff before ACPI was a feature of the hardware, I assume > there's a relationship. As of 2.6.9 ACPI still couldn't power down > one of my old boxes, it hasn't been updated since that time, so I > can't say what later kernels will do. perhaps i completely misunderstood what i was looking at but when i submitted a patch to remove "legacy power management," i wasn't referring to APM. i was talking about the PM stuff even *older* than that, that's listed as "Legacy Power Management API (DEPRECATED)" under the PM config menu. so, politics and scheduling aside, was that earlier patch a reasonable and correct way to do *that*? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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][RFC] Kill off legacy power management stuff.
Robert P. J. Day wrote: On Tue, 17 Apr 2007, Bill Davidsen wrote: Rafael J. Wysocki wrote: [appropriate CCs added] On Friday, 13 April 2007 02:33, Robert P. J. Day wrote: just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as "DEPRECATED", while the help screen calls it "obsolete." that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. It's been like this for a long long time. I think you're right that it can be dropped, but I don't know the details (eg. why it hasn't been dropped yet). One reason was that there are (were?) a number of machines which only powered down properly using apm. It was discussed as part of shutting down after power failure when your UPS is running out of power. um ... what does APM have to do with legacy PM? two different issues, no? Since the patches are going into apm.c and apm was used for suspend and poweroff before ACPI was a feature of the hardware, I assume there's a relationship. As of 2.6.9 ACPI still couldn't power down one of my old boxes, it hasn't been updated since that time, so I can't say what later kernels will do. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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][RFC] Kill off legacy power management stuff.
Robert P. J. Day wrote: On Tue, 17 Apr 2007, Bill Davidsen wrote: Rafael J. Wysocki wrote: [appropriate CCs added] On Friday, 13 April 2007 02:33, Robert P. J. Day wrote: just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as DEPRECATED, while the help screen calls it obsolete. that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. It's been like this for a long long time. I think you're right that it can be dropped, but I don't know the details (eg. why it hasn't been dropped yet). One reason was that there are (were?) a number of machines which only powered down properly using apm. It was discussed as part of shutting down after power failure when your UPS is running out of power. um ... what does APM have to do with legacy PM? two different issues, no? Since the patches are going into apm.c and apm was used for suspend and poweroff before ACPI was a feature of the hardware, I assume there's a relationship. As of 2.6.9 ACPI still couldn't power down one of my old boxes, it hasn't been updated since that time, so I can't say what later kernels will do. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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][RFC] Kill off legacy power management stuff.
On Wed, 18 Apr 2007, Bill Davidsen wrote: Robert P. J. Day wrote: ... um ... what does APM have to do with legacy PM? two different issues, no? Since the patches are going into apm.c and apm was used for suspend and poweroff before ACPI was a feature of the hardware, I assume there's a relationship. As of 2.6.9 ACPI still couldn't power down one of my old boxes, it hasn't been updated since that time, so I can't say what later kernels will do. perhaps i completely misunderstood what i was looking at but when i submitted a patch to remove legacy power management, i wasn't referring to APM. i was talking about the PM stuff even *older* than that, that's listed as Legacy Power Management API (DEPRECATED) under the PM config menu. so, politics and scheduling aside, was that earlier patch a reasonable and correct way to do *that*? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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: {Spam?} Re: [PATCH][RFC] Kill off legacy power management stuff.
On Saturday 14 April 2007 09:01, Robert P. J. Day wrote:
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) Robert P. J. Day [EMAIL
PROTECTED] wrote:
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
One thing that comes to mind is that you will need some way to
make sure that only one of ACPI and APM get initialized ...
i don't see how that has anything to do with removing legacy PM
support. you can select both ACPI and APM *now*. if that's a bad
thing, then fixing it is a completely independent issue.
Except your patch removes this hunk:
@@ -2264,14 +2248,6 @@ static int __init apm_init(void)
apm_info.disabled = 1;
return -ENODEV;
}
- if (PM_IS_ACTIVE()) {
- printk(KERN_NOTICE apm: overridden by ACPI.\n);
- apm_info.disabled = 1;
- return -ENODEV;
- }
-#ifdef CONFIG_PM_LEGACY
- pm_active = 1;
-#endif
in apm.c and a similar piece of the ACPI initialisation that
prevented one initialising if the other had already initialised.
ah, just took a closer look at this. from linux/pm_legacy.h:
...
#ifdef CONFIG_PM_LEGACY
...
#else
#define PM_IS_ACTIVE() 0
...
#endif
so if you choose not to configure legacy PM, that macro equates to
false and that if construct in arch/i386/kernel/apm.c doesn't come
into play, anyway.
so i re-iterate what i posted in my earlier e-mail -- if APM and ACPI
want to avoid clashing, they have to do it without invoking anything
related to legacy PM.
Here is how it should work.
CONFIG_ACPI and CONFIG_APM should both available in a kernel build.
However, at boot time, of ACPI is active, then APM should be disabled.
The pm_active flag used to handle this, but that method was BROKEN
when the CONFIG_PM_LEGACY #define was added. Today, there are systems
(such as the Thinkpad T30) that will not boot if CONFIG_PM_LEGACY
is not defined. The reason nobody is complaining is because the distros
are currently defining CONFIG_PM_LEGACY. But when you nuke that option
and everything under it, this bug will be exposed and some systems will stop
booting.
-Len
-
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][RFC] Kill off legacy power management stuff.
Hi! One reason was that there are (were?) a number of machines which only powered down properly using apm. It was discussed as part of shutting down after power failure when your UPS is running out of power. um ... what does APM have to do with legacy PM? two different issues, no? Since the patches are going into apm.c and apm was used for suspend and poweroff before ACPI was a feature of the hardware, I assume there's a relationship. As of 2.6.9 ACPI still couldn't power down one of my old There is not. The patches should not affect you unless you use obscure 68000 driver. We are removing infrastructure that has no users. 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: {Spam?} Re: [PATCH][RFC] Kill off legacy power management stuff.
On Wed, 18 Apr 2007, Len Brown wrote:
On Saturday 14 April 2007 09:01, Robert P. J. Day wrote:
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) Robert P. J. Day [EMAIL
PROTECTED] wrote:
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
One thing that comes to mind is that you will need some way to
make sure that only one of ACPI and APM get initialized ...
i don't see how that has anything to do with removing legacy PM
support. you can select both ACPI and APM *now*. if that's a bad
thing, then fixing it is a completely independent issue.
Except your patch removes this hunk:
@@ -2264,14 +2248,6 @@ static int __init apm_init(void)
apm_info.disabled = 1;
return -ENODEV;
}
- if (PM_IS_ACTIVE()) {
- printk(KERN_NOTICE apm: overridden by ACPI.\n);
- apm_info.disabled = 1;
- return -ENODEV;
- }
-#ifdef CONFIG_PM_LEGACY
- pm_active = 1;
-#endif
in apm.c and a similar piece of the ACPI initialisation that
prevented one initialising if the other had already initialised.
ah, just took a closer look at this. from linux/pm_legacy.h:
...
#ifdef CONFIG_PM_LEGACY
...
#else
#define PM_IS_ACTIVE() 0
...
#endif
so if you choose not to configure legacy PM, that macro equates to
false and that if construct in arch/i386/kernel/apm.c doesn't
come into play, anyway.
so i re-iterate what i posted in my earlier e-mail -- if APM and
ACPI want to avoid clashing, they have to do it without invoking
anything related to legacy PM.
Here is how it should work. CONFIG_ACPI and CONFIG_APM should both
available in a kernel build. However, at boot time, of ACPI is
active, then APM should be disabled.
The pm_active flag used to handle this, but that method was BROKEN
when the CONFIG_PM_LEGACY #define was added. Today, there are
systems (such as the Thinkpad T30) that will not boot if
CONFIG_PM_LEGACY is not defined. The reason nobody is complaining
is because the distros are currently defining CONFIG_PM_LEGACY.
But when you nuke that option and everything under it, this bug will
be exposed and some systems will stop booting.
ok, i get it now and -- correct me if i'm wrong -- all my legacy PM
removal patch was doing was exposing a design boo-boo in which
APM/ACPI contention was being handled by a macro in a subsystem even
older than either of them, right? so all that needs to be done is add
back in a contention solution of some kind that doesn't rely on that
ancient system, yes?
as for that thinkpad t30 situation, well, that's just borked, and
should be fixed.
rday
p.s. at the risk of repeating myself repetitively, do we now agree
that what i was trying to remove *was* adequately ancient? although
it's clear that it has to be done slightly more carefully than was
done in my initial patch.
p.p.s. patch improvements that will let me avoid doing any of that
myself always welcome. :-)
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
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][RFC] Kill off legacy power management stuff.
On Wednesday 18 April 2007 16:23, Robert P. J. Day wrote: On Wed, 18 Apr 2007, Len Brown wrote: Here is how it should work. CONFIG_ACPI and CONFIG_APM should both available in a kernel build. However, at boot time, of ACPI is active, then APM should be disabled. The pm_active flag used to handle this, but that method was BROKEN when the CONFIG_PM_LEGACY #define was added. Today, there are systems (such as the Thinkpad T30) that will not boot if CONFIG_PM_LEGACY is not defined. The reason nobody is complaining is because the distros are currently defining CONFIG_PM_LEGACY. But when you nuke that option and everything under it, this bug will be exposed and some systems will stop booting. ok, i get it now and -- correct me if i'm wrong -- all my legacy PM removal patch was doing was exposing a design boo-boo in which APM/ACPI contention was being handled by a macro in a subsystem even older than either of them, right? yeah, it didn't start out that way, the bug was added when the CONFIG_PM_LEGACY #define was added. so all that needs to be done is add back in a contention solution of some kind that doesn't rely on that ancient system, yes? Yes, it is a matter of making the variable not go away when the #define goes away. as for that thinkpad t30 situation, well, that's just borked, and should be fixed. yes, the actual failure is that APM mode on the T30 hangs -- and that is independent of the issue at hand. However, there could be other failures on other machines when both APM and ACPI think they are active. rday p.s. at the risk of repeating myself repetitively, do we now agree that what i was trying to remove *was* adequately ancient? although it's clear that it has to be done slightly more carefully than was done in my initial patch. yes, I think so. p.p.s. patch improvements that will let me avoid doing any of that myself always welcome. :-) well, I'm sorry that I've known about the APM issue for a long time and done nothing about it. I did ping davej when he broke it, but his to-do list is probably even longer than mine. -Len - 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][RFC] Kill off legacy power management stuff.
On Wed, 18 Apr 2007, Len Brown wrote: On Wednesday 18 April 2007 16:23, Robert P. J. Day wrote: ok, i get it now and -- correct me if i'm wrong -- all my legacy PM removal patch was doing was exposing a design boo-boo in which APM/ACPI contention was being handled by a macro in a subsystem even older than either of them, right? yeah, it didn't start out that way, the bug was added when the CONFIG_PM_LEGACY #define was added. so all that needs to be done is add back in a contention solution of some kind that doesn't rely on that ancient system, yes? Yes, it is a matter of making the variable not go away when the #define goes away. as for that thinkpad t30 situation, well, that's just borked, and should be fixed. yes, the actual failure is that APM mode on the T30 hangs -- and that is independent of the issue at hand. However, there could be other failures on other machines when both APM and ACPI think they are active. at this point, i think the proper approach is to locate and remove all dependencies on the legacy PM code, which includes making sure there's a reliable contention mechanism for APM and ACPI that doesn't need anything out of the legacy code or header files. once that's done, the legacy deletion itself should be trivial. the obvious place for the contention stuff is, i would think, include/linux/pm.h, yes? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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][RFC] Kill off legacy power management stuff.
On Wed, Apr 18, 2007 at 05:23:15PM -0400, Len Brown wrote: p.p.s. patch improvements that will let me avoid doing any of that myself always welcome. :-) well, I'm sorry that I've known about the APM issue for a long time and done nothing about it. I did ping davej when he broke it, but his to-do list is probably even longer than mine. ping timeout. I don't recall too many of the details surrounding those changes, but I certainly won't stand in the way of anyone trying to fix it. It sounds like you and Robert are on top of it, or do you want me to poke at 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][RFC] Kill off legacy power management stuff.
On Wed, 18 Apr 2007, Dave Jones wrote: On Wed, Apr 18, 2007 at 05:23:15PM -0400, Len Brown wrote: p.p.s. patch improvements that will let me avoid doing any of that myself always welcome. :-) well, I'm sorry that I've known about the APM issue for a long time and done nothing about it. I did ping davej when he broke it, but his to-do list is probably even longer than mine. ping timeout. I don't recall too many of the details surrounding those changes, but I certainly won't stand in the way of anyone trying to fix it. It sounds like you and Robert are on top of it, or do you want me to poke at it ? well, before i get even more confused by what was (once upon a time) a fairly straightforward removal patch, the first obvious question is -- are there *any* circumstances that *require* a config selection of CONFIG_PM_LEGACY, as opposed to a selection of APM and/or ACPI? if there are, then it can't simply be removed. my original patch submission was based on the assumption that absolutely no one needed the legacy stuff anymore and absolutely everything related to it could be scrapped. so, first things first: what *needs* legacy PM at the moment? rday p.s. i'm confused by the header file include/linux/pm_legacy.h, especially this part: #ifdef CONFIG_PM_LEGACY ... # else /* CONFIG_PM_LEGACY */ #define PM_IS_ACTIVE() 0 ... #endif === so the macro PM_IS_ACTIVE() represents whether *legacy* PM has been selected. in other words, it makes no (apparent) sense that the value of that macro would represent some kind of contention mechanism between APM and ACPI, which is entirely independent from the legacy stuff. right? -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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][RFC] Kill off legacy power management stuff.
On Tue, 17 Apr 2007, Bill Davidsen wrote: > Rafael J. Wysocki wrote: > > [appropriate CCs added] > > > > On Friday, 13 April 2007 02:33, Robert P. J. Day wrote: > > > just something i threw together, not in final form, but it represents > > > tossing the legacy PM stuff. at the moment, the menuconfig entry for > > > PM_LEGACY lists it as "DEPRECATED", while the help screen calls it > > > "obsolete." that's a good sign that it's getting close to the time > > > for it to go, and the removal is fairly straightforward, but there's > > > no mention of its removal in the feature removal schedule file. > > > > It's been like this for a long long time. I think you're right that it can > > be > > dropped, but I don't know the details (eg. why it hasn't been dropped yet). > > > One reason was that there are (were?) a number of machines which only powered > down properly using apm. It was discussed as part of shutting down after power > failure when your UPS is running out of power. um ... what does APM have to do with legacy PM? two different issues, no? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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] [PATCH][RFC] Kill off legacy power management stuff.
On Tuesday 17 April 2007 3:12 pm, Bill Davidsen wrote: > > One reason was that there are (were?) a number of machines which only > powered down properly using apm. It was discussed as part of shutting > down after power failure when your UPS is running out of power. At least the notification mechanism had only the one client (68328serial.c), so that part should be easily removed even if APM emulation needs some of the other bits ... - 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][RFC] Kill off legacy power management stuff.
Rafael J. Wysocki wrote: [appropriate CCs added] On Friday, 13 April 2007 02:33, Robert P. J. Day wrote: just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as "DEPRECATED", while the help screen calls it "obsolete." that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. It's been like this for a long long time. I think you're right that it can be dropped, but I don't know the details (eg. why it hasn't been dropped yet). One reason was that there are (were?) a number of machines which only powered down properly using apm. It was discussed as part of shutting down after power failure when your UPS is running out of power. I haven't checked on that in a while, I'm just supplying one reason since you wondered. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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][RFC] Kill off legacy power management stuff.
Rafael J. Wysocki wrote: [appropriate CCs added] On Friday, 13 April 2007 02:33, Robert P. J. Day wrote: just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as DEPRECATED, while the help screen calls it obsolete. that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. It's been like this for a long long time. I think you're right that it can be dropped, but I don't know the details (eg. why it hasn't been dropped yet). One reason was that there are (were?) a number of machines which only powered down properly using apm. It was discussed as part of shutting down after power failure when your UPS is running out of power. I haven't checked on that in a while, I'm just supplying one reason since you wondered. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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] [PATCH][RFC] Kill off legacy power management stuff.
On Tuesday 17 April 2007 3:12 pm, Bill Davidsen wrote: One reason was that there are (were?) a number of machines which only powered down properly using apm. It was discussed as part of shutting down after power failure when your UPS is running out of power. At least the notification mechanism had only the one client (68328serial.c), so that part should be easily removed even if APM emulation needs some of the other bits ... - 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][RFC] Kill off legacy power management stuff.
On Tue, 17 Apr 2007, Bill Davidsen wrote: Rafael J. Wysocki wrote: [appropriate CCs added] On Friday, 13 April 2007 02:33, Robert P. J. Day wrote: just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as DEPRECATED, while the help screen calls it obsolete. that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. It's been like this for a long long time. I think you're right that it can be dropped, but I don't know the details (eg. why it hasn't been dropped yet). One reason was that there are (were?) a number of machines which only powered down properly using apm. It was discussed as part of shutting down after power failure when your UPS is running out of power. um ... what does APM have to do with legacy PM? two different issues, no? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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][RFC] Kill off legacy power management stuff.
Hi! > > just something i threw together, not in final form, but it represents > > tossing the legacy PM stuff. at the moment, the menuconfig entry for > > PM_LEGACY lists it as "DEPRECATED", while the help screen calls it > > "obsolete." that's a good sign that it's getting close to the time > > for it to go, and the removal is fairly straightforward, but there's > > no mention of its removal in the feature removal schedule file. Yes, it will be nice to see this old code be gone. 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: [PATCH][RFC] Kill off legacy power management stuff.
Hi! just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as DEPRECATED, while the help screen calls it obsolete. that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. Yes, it will be nice to see this old code be gone. 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/
{Spam?} Re: [PATCH][RFC] Kill off legacy power management stuff.
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
> On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) "Robert P. J. Day" <[EMAIL
> PROTECTED]> wrote:
> >
> > On Fri, 13 Apr 2007, Stephen Rothwell wrote:
> > >
> > > One thing that comes to mind is that you will need some way to
> > > make sure that only one of ACPI and APM get initialized ...
> >
> > i don't see how that has anything to do with removing legacy PM
> > support. you can select both ACPI and APM *now*. if that's a bad
> > thing, then fixing it is a completely independent issue.
>
> Except your patch removes this hunk:
>
> @@ -2264,14 +2248,6 @@ static int __init apm_init(void)
> apm_info.disabled = 1;
> return -ENODEV;
> }
> - if (PM_IS_ACTIVE()) {
> - printk(KERN_NOTICE "apm: overridden by ACPI.\n");
> - apm_info.disabled = 1;
> - return -ENODEV;
> - }
> -#ifdef CONFIG_PM_LEGACY
> - pm_active = 1;
> -#endif
>
> in apm.c and a similar piece of the ACPI initialisation that
> prevented one initialising if the other had already initialised.
ah, just took a closer look at this. from :
...
#ifdef CONFIG_PM_LEGACY
...
#else
#define PM_IS_ACTIVE() 0
...
#endif
so if you choose not to configure legacy PM, that macro equates to
false and that "if" construct in arch/i386/kernel/apm.c doesn't come
into play, anyway.
so i re-iterate what i posted in my earlier e-mail -- if APM and ACPI
want to avoid clashing, they have to do it without invoking anything
related to legacy PM.
rday
p.s. if someone wants to take that previously-submitted patch
proposal and tidy it up and submit it officially, feel free.
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
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/
{Spam?} Re: [PATCH][RFC] Kill off legacy power management stuff.
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
> On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) "Robert P. J. Day" <[EMAIL
> PROTECTED]> wrote:
> >
> > On Fri, 13 Apr 2007, Stephen Rothwell wrote:
> > >
> > > One thing that comes to mind is that you will need some way to
> > > make sure that only one of ACPI and APM get initialized ...
> >
> > i don't see how that has anything to do with removing legacy PM
> > support. you can select both ACPI and APM *now*. if that's a bad
> > thing, then fixing it is a completely independent issue.
>
> Except your patch removes this hunk:
>
> @@ -2264,14 +2248,6 @@ static int __init apm_init(void)
> apm_info.disabled = 1;
> return -ENODEV;
> }
> - if (PM_IS_ACTIVE()) {
> - printk(KERN_NOTICE "apm: overridden by ACPI.\n");
> - apm_info.disabled = 1;
> - return -ENODEV;
> - }
> -#ifdef CONFIG_PM_LEGACY
> - pm_active = 1;
> -#endif
>
> in apm.c and a similar piece of the ACPI initialisation that prevented
> one initialising if the other had already initialised.
you have a point, but note that the macro "PM_IS_ACTIVE" is *defined*
in the header file "linux/pm_legacy.h". so if that macro is still
essential, its definition will have to be moved elsewhere, no?
my approach was to rip out everything that seemed to be related
to pm_legacy.h, so if that macro disappears, then any references to it
must similarly disappear.
can someone clarify this? if only one of APM or ACPI can be enabled,
they should find a way to agree on that without needing legacy code to
do it.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
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/
{Spam?} Re: [PATCH][RFC] Kill off legacy power management stuff.
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) Robert P. J. Day [EMAIL
PROTECTED] wrote:
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
One thing that comes to mind is that you will need some way to
make sure that only one of ACPI and APM get initialized ...
i don't see how that has anything to do with removing legacy PM
support. you can select both ACPI and APM *now*. if that's a bad
thing, then fixing it is a completely independent issue.
Except your patch removes this hunk:
@@ -2264,14 +2248,6 @@ static int __init apm_init(void)
apm_info.disabled = 1;
return -ENODEV;
}
- if (PM_IS_ACTIVE()) {
- printk(KERN_NOTICE apm: overridden by ACPI.\n);
- apm_info.disabled = 1;
- return -ENODEV;
- }
-#ifdef CONFIG_PM_LEGACY
- pm_active = 1;
-#endif
in apm.c and a similar piece of the ACPI initialisation that prevented
one initialising if the other had already initialised.
you have a point, but note that the macro PM_IS_ACTIVE is *defined*
in the header file linux/pm_legacy.h. so if that macro is still
essential, its definition will have to be moved elsewhere, no?
my approach was to rip out everything that seemed to be related
to pm_legacy.h, so if that macro disappears, then any references to it
must similarly disappear.
can someone clarify this? if only one of APM or ACPI can be enabled,
they should find a way to agree on that without needing legacy code to
do it.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
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/
{Spam?} Re: [PATCH][RFC] Kill off legacy power management stuff.
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) Robert P. J. Day [EMAIL
PROTECTED] wrote:
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
One thing that comes to mind is that you will need some way to
make sure that only one of ACPI and APM get initialized ...
i don't see how that has anything to do with removing legacy PM
support. you can select both ACPI and APM *now*. if that's a bad
thing, then fixing it is a completely independent issue.
Except your patch removes this hunk:
@@ -2264,14 +2248,6 @@ static int __init apm_init(void)
apm_info.disabled = 1;
return -ENODEV;
}
- if (PM_IS_ACTIVE()) {
- printk(KERN_NOTICE apm: overridden by ACPI.\n);
- apm_info.disabled = 1;
- return -ENODEV;
- }
-#ifdef CONFIG_PM_LEGACY
- pm_active = 1;
-#endif
in apm.c and a similar piece of the ACPI initialisation that
prevented one initialising if the other had already initialised.
ah, just took a closer look at this. from linux/pm_legacy.h:
...
#ifdef CONFIG_PM_LEGACY
...
#else
#define PM_IS_ACTIVE() 0
...
#endif
so if you choose not to configure legacy PM, that macro equates to
false and that if construct in arch/i386/kernel/apm.c doesn't come
into play, anyway.
so i re-iterate what i posted in my earlier e-mail -- if APM and ACPI
want to avoid clashing, they have to do it without invoking anything
related to legacy PM.
rday
p.s. if someone wants to take that previously-submitted patch
proposal and tidy it up and submit it officially, feel free.
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
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] [PATCH][RFC] Kill off legacy power management stuff.
On Friday 13 April 2007 1:22 am, Rafael J. Wysocki wrote: > [appropriate CCs added] > > On Friday, 13 April 2007 02:33, Robert P. J. Day wrote: > > > > just something i threw together, not in final form, but it represents > > tossing the legacy PM stuff. at the moment, the menuconfig entry for > > PM_LEGACY lists it as "DEPRECATED", while the help screen calls it > > "obsolete." that's a good sign that it's getting close to the time > > for it to go, and the removal is fairly straightforward, but there's > > no mention of its removal in the feature removal schedule file. > > It's been like this for a long long time. I think you're right that it can be > dropped, but I don't know the details (eg. why it hasn't been dropped yet). I was just thinking about this the other day. I did an inventory of the actual _users_ of this code when I added the deprecation to Kconfig, and the only driver that would catch the notification was for some old m68k platform serial driver (Amiga?) ... that won't have changed. So the only reason not to remove it at that time was to make sure that folk had a chance to squawk about it going away. I think it's past time for this ancient stuff to vanish, since it's been obsolete for most of 2.5..2.6 and there's only that one event consumer left. Go for it! - Dave - 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][RFC] Kill off legacy power management stuff.
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
> On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) "Robert P. J. Day" <[EMAIL
> PROTECTED]> wrote:
> >
> > On Fri, 13 Apr 2007, Stephen Rothwell wrote:
> > >
> > > One thing that comes to mind is that you will need some way to make sure
> > > that only one of ACPI and APM get initialized ...
> >
> > i don't see how that has anything to do with removing legacy PM
> > support. you can select both ACPI and APM *now*. if that's a bad
> > thing, then fixing it is a completely independent issue.
>
> Except your patch removes this hunk:
>
> @@ -2264,14 +2248,6 @@ static int __init apm_init(void)
> apm_info.disabled = 1;
> return -ENODEV;
> }
> - if (PM_IS_ACTIVE()) {
> - printk(KERN_NOTICE "apm: overridden by ACPI.\n");
> - apm_info.disabled = 1;
> - return -ENODEV;
> - }
> -#ifdef CONFIG_PM_LEGACY
> - pm_active = 1;
> -#endif
>
> in apm.c and a similar piece of the ACPI initialisation that
> prevented one initialising if the other had already initialised.
ah, gotcha. i'll take a closer look at that once in land in sunny
california. but not right away. :-)
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
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][RFC] Kill off legacy power management stuff.
On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) "Robert P. J. Day" <[EMAIL PROTECTED]>
wrote:
>
> On Fri, 13 Apr 2007, Stephen Rothwell wrote:
> >
> > One thing that comes to mind is that you will need some way to make sure
> > that only one of ACPI and APM get initialized ...
>
> i don't see how that has anything to do with removing legacy PM
> support. you can select both ACPI and APM *now*. if that's a bad
> thing, then fixing it is a completely independent issue.
Except your patch removes this hunk:
@@ -2264,14 +2248,6 @@ static int __init apm_init(void)
apm_info.disabled = 1;
return -ENODEV;
}
- if (PM_IS_ACTIVE()) {
- printk(KERN_NOTICE "apm: overridden by ACPI.\n");
- apm_info.disabled = 1;
- return -ENODEV;
- }
-#ifdef CONFIG_PM_LEGACY
- pm_active = 1;
-#endif
in apm.c and a similar piece of the ACPI initialisation that prevented
one initialising if the other had already initialised.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpn9wuNsU4bB.pgp
Description: PGP signature
Re: [PATCH][RFC] Kill off legacy power management stuff.
On Fri, 13 Apr 2007, Stephen Rothwell wrote: > On Thu, 12 Apr 2007 20:33:16 -0400 (EDT) "Robert P. J. Day" <[EMAIL > PROTECTED]> wrote: > > > > just something i threw together, not in final form, but it > > represents tossing the legacy PM stuff. at the moment, the > > menuconfig entry for PM_LEGACY lists it as "DEPRECATED", while the > > help screen calls it "obsolete." that's a good sign that it's > > getting close to the time for it to go, and the removal is fairly > > straightforward, but there's no mention of its removal in the > > feature removal schedule file. > > One thing that comes to mind is that you will need some way to make sure > that only one of ACPI and APM get initialized ... i don't see how that has anything to do with removing legacy PM support. you can select both ACPI and APM *now*. if that's a bad thing, then fixing it is a completely independent issue. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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][RFC] Kill off legacy power management stuff.
[appropriate CCs added] On Friday, 13 April 2007 02:33, Robert P. J. Day wrote: > > just something i threw together, not in final form, but it represents > tossing the legacy PM stuff. at the moment, the menuconfig entry for > PM_LEGACY lists it as "DEPRECATED", while the help screen calls it > "obsolete." that's a good sign that it's getting close to the time > for it to go, and the removal is fairly straightforward, but there's > no mention of its removal in the feature removal schedule file. It's been like this for a long long time. I think you're right that it can be dropped, but I don't know the details (eg. why it hasn't been dropped yet). > NOTE: this is not a working patch as it will fail on a MIPS or FR-V > build, as i didn't remove the final vestiges from those two > architectures. that would require simply killing off the remaining > calls to pm_send_all(), that's all. (i think.) > > anyway, this has been compile-tested on x86 with "make allyesconfig." > > > Documentation/pm.txt | 123 --- > arch/i386/kernel/apm.c | 27 > drivers/acpi/bus.c | 14 -- > drivers/net/3c509.c |1 > drivers/serial/68328serial.c | 59 - > include/linux/pm.h | 70 --- > include/linux/pm_legacy.h| 41 -- > kernel/power/Kconfig | 10 - > kernel/power/Makefile|1 > kernel/power/pm.c| 209 - > 10 files changed, 1 insertion(+), 554 deletions(-) > > > diff --git a/Documentation/pm.txt b/Documentation/pm.txt > index da8589a..d0fcfe2 100644 > --- a/Documentation/pm.txt > +++ b/Documentation/pm.txt > @@ -36,93 +36,6 @@ system the associated daemon will exit gracefully. >apmd: http://worldvisions.ca/~apenwarr/apmd/ >acpid: http://acpid.sf.net/ > > -Driver Interface -- OBSOLETE, DO NOT USE! > -* > - > -Note: pm_register(), pm_access(), pm_dev_idle() and friends are > -obsolete. Please do not use them. Instead you should properly hook > -your driver into the driver model, and use its suspend()/resume() > -callbacks to do this kind of stuff. > - > -If you are writing a new driver or maintaining an old driver, it > -should include power management support. Without power management > -support, a single driver may prevent a system with power management > -capabilities from ever being able to suspend (safely). > - > -Overview: > -1) Register each instance of a device with "pm_register" > -2) Call "pm_access" before accessing the hardware. > - (this will ensure that the hardware is awake and ready) > -3) Your "pm_callback" is called before going into a > - suspend state (ACPI D1-D3) or after resuming (ACPI D0) > - from a suspend. > -4) Call "pm_dev_idle" when the device is not being used > - (optional but will improve device idle detection) > -5) When unloaded, unregister the device with "pm_unregister" > - > -/* > - * Description: Register a device with the power-management subsystem > - * > - * Parameters: > - * type - device type (PCI device, system device, ...) > - * id - instance number or unique identifier > - * cback - request handler callback (suspend, resume, ...) > - * > - * Returns: Registered PM device or NULL on error > - * > - * Examples: > - * dev = pm_register(PM_SYS_DEV, PM_SYS_VGA, vga_callback); > - * > - * struct pci_dev *pci_dev = pci_find_dev(...); > - * dev = pm_register(PM_PCI_DEV, PM_PCI_ID(pci_dev), callback); > - */ > -struct pm_dev *pm_register(pm_dev_t type, unsigned long id, pm_callback > cback); > - > -/* > - * Description: Unregister a device with the power management subsystem > - * > - * Parameters: > - * dev - PM device previously returned from pm_register > - */ > -void pm_unregister(struct pm_dev *dev); > - > -/* > - * Description: Unregister all devices with a matching callback function > - * > - * Parameters: > - * cback - previously registered request callback > - * > - * Notes: Provided for easier porting from old APM interface > - */ > -void pm_unregister_all(pm_callback cback); > - > -/* > - * Power management request callback > - * > - * Parameters: > - * dev - PM device previously returned from pm_register > - * rqst - request type > - * data - data, if any, associated with the request > - * > - * Returns: 0 if the request is successful > - * EINVAL if the request is not supported > - * EBUSY if the device is now busy and cannot handle the request > - * ENOMEM if the device was unable to handle the request due to > memory > - * > - * Details: The device request callback will be called before the > - * device/system enters a suspend state (ACPI D1-D3) or > - * or after the device/system resumes from suspend (ACPI D0). > - * For PM_SUSPEND, the ACPI D-state being entered is passed > - * as the "data" argument to the callback. The device > - * driver should
Re: [PATCH][RFC] Kill off legacy power management stuff.
On Thu, 12 Apr 2007 20:33:16 -0400 (EDT) "Robert P. J. Day" <[EMAIL PROTECTED]> wrote: > > just something i threw together, not in final form, but it represents > tossing the legacy PM stuff. at the moment, the menuconfig entry for > PM_LEGACY lists it as "DEPRECATED", while the help screen calls it > "obsolete." that's a good sign that it's getting close to the time > for it to go, and the removal is fairly straightforward, but there's > no mention of its removal in the feature removal schedule file. One thing that comes to mind is that you will need some way to make sure that only one of ACPI and APM get initialized ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp3dq7qKWx4J.pgp Description: PGP signature
Re: [PATCH][RFC] Kill off legacy power management stuff.
On Thu, 12 Apr 2007 20:33:16 -0400 (EDT) Robert P. J. Day [EMAIL PROTECTED] wrote: just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as DEPRECATED, while the help screen calls it obsolete. that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. One thing that comes to mind is that you will need some way to make sure that only one of ACPI and APM get initialized ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp3dq7qKWx4J.pgp Description: PGP signature
Re: [PATCH][RFC] Kill off legacy power management stuff.
[appropriate CCs added] On Friday, 13 April 2007 02:33, Robert P. J. Day wrote: just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as DEPRECATED, while the help screen calls it obsolete. that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. It's been like this for a long long time. I think you're right that it can be dropped, but I don't know the details (eg. why it hasn't been dropped yet). NOTE: this is not a working patch as it will fail on a MIPS or FR-V build, as i didn't remove the final vestiges from those two architectures. that would require simply killing off the remaining calls to pm_send_all(), that's all. (i think.) anyway, this has been compile-tested on x86 with make allyesconfig. Documentation/pm.txt | 123 --- arch/i386/kernel/apm.c | 27 drivers/acpi/bus.c | 14 -- drivers/net/3c509.c |1 drivers/serial/68328serial.c | 59 - include/linux/pm.h | 70 --- include/linux/pm_legacy.h| 41 -- kernel/power/Kconfig | 10 - kernel/power/Makefile|1 kernel/power/pm.c| 209 - 10 files changed, 1 insertion(+), 554 deletions(-) diff --git a/Documentation/pm.txt b/Documentation/pm.txt index da8589a..d0fcfe2 100644 --- a/Documentation/pm.txt +++ b/Documentation/pm.txt @@ -36,93 +36,6 @@ system the associated daemon will exit gracefully. apmd: http://worldvisions.ca/~apenwarr/apmd/ acpid: http://acpid.sf.net/ -Driver Interface -- OBSOLETE, DO NOT USE! -* - -Note: pm_register(), pm_access(), pm_dev_idle() and friends are -obsolete. Please do not use them. Instead you should properly hook -your driver into the driver model, and use its suspend()/resume() -callbacks to do this kind of stuff. - -If you are writing a new driver or maintaining an old driver, it -should include power management support. Without power management -support, a single driver may prevent a system with power management -capabilities from ever being able to suspend (safely). - -Overview: -1) Register each instance of a device with pm_register -2) Call pm_access before accessing the hardware. - (this will ensure that the hardware is awake and ready) -3) Your pm_callback is called before going into a - suspend state (ACPI D1-D3) or after resuming (ACPI D0) - from a suspend. -4) Call pm_dev_idle when the device is not being used - (optional but will improve device idle detection) -5) When unloaded, unregister the device with pm_unregister - -/* - * Description: Register a device with the power-management subsystem - * - * Parameters: - * type - device type (PCI device, system device, ...) - * id - instance number or unique identifier - * cback - request handler callback (suspend, resume, ...) - * - * Returns: Registered PM device or NULL on error - * - * Examples: - * dev = pm_register(PM_SYS_DEV, PM_SYS_VGA, vga_callback); - * - * struct pci_dev *pci_dev = pci_find_dev(...); - * dev = pm_register(PM_PCI_DEV, PM_PCI_ID(pci_dev), callback); - */ -struct pm_dev *pm_register(pm_dev_t type, unsigned long id, pm_callback cback); - -/* - * Description: Unregister a device with the power management subsystem - * - * Parameters: - * dev - PM device previously returned from pm_register - */ -void pm_unregister(struct pm_dev *dev); - -/* - * Description: Unregister all devices with a matching callback function - * - * Parameters: - * cback - previously registered request callback - * - * Notes: Provided for easier porting from old APM interface - */ -void pm_unregister_all(pm_callback cback); - -/* - * Power management request callback - * - * Parameters: - * dev - PM device previously returned from pm_register - * rqst - request type - * data - data, if any, associated with the request - * - * Returns: 0 if the request is successful - * EINVAL if the request is not supported - * EBUSY if the device is now busy and cannot handle the request - * ENOMEM if the device was unable to handle the request due to memory - * - * Details: The device request callback will be called before the - * device/system enters a suspend state (ACPI D1-D3) or - * or after the device/system resumes from suspend (ACPI D0). - * For PM_SUSPEND, the ACPI D-state being entered is passed - * as the data argument to the callback. The device - * driver should save (PM_SUSPEND) or restore (PM_RESUME) - * device context when the request callback is called. - * - * Once a
Re: [PATCH][RFC] Kill off legacy power management stuff.
On Fri, 13 Apr 2007, Stephen Rothwell wrote: On Thu, 12 Apr 2007 20:33:16 -0400 (EDT) Robert P. J. Day [EMAIL PROTECTED] wrote: just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as DEPRECATED, while the help screen calls it obsolete. that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. One thing that comes to mind is that you will need some way to make sure that only one of ACPI and APM get initialized ... i don't see how that has anything to do with removing legacy PM support. you can select both ACPI and APM *now*. if that's a bad thing, then fixing it is a completely independent issue. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - 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][RFC] Kill off legacy power management stuff.
On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) Robert P. J. Day [EMAIL PROTECTED]
wrote:
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
One thing that comes to mind is that you will need some way to make sure
that only one of ACPI and APM get initialized ...
i don't see how that has anything to do with removing legacy PM
support. you can select both ACPI and APM *now*. if that's a bad
thing, then fixing it is a completely independent issue.
Except your patch removes this hunk:
@@ -2264,14 +2248,6 @@ static int __init apm_init(void)
apm_info.disabled = 1;
return -ENODEV;
}
- if (PM_IS_ACTIVE()) {
- printk(KERN_NOTICE apm: overridden by ACPI.\n);
- apm_info.disabled = 1;
- return -ENODEV;
- }
-#ifdef CONFIG_PM_LEGACY
- pm_active = 1;
-#endif
in apm.c and a similar piece of the ACPI initialisation that prevented
one initialising if the other had already initialised.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpn9wuNsU4bB.pgp
Description: PGP signature
Re: [PATCH][RFC] Kill off legacy power management stuff.
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
On Fri, 13 Apr 2007 04:20:10 -0400 (EDT) Robert P. J. Day [EMAIL
PROTECTED] wrote:
On Fri, 13 Apr 2007, Stephen Rothwell wrote:
One thing that comes to mind is that you will need some way to make sure
that only one of ACPI and APM get initialized ...
i don't see how that has anything to do with removing legacy PM
support. you can select both ACPI and APM *now*. if that's a bad
thing, then fixing it is a completely independent issue.
Except your patch removes this hunk:
@@ -2264,14 +2248,6 @@ static int __init apm_init(void)
apm_info.disabled = 1;
return -ENODEV;
}
- if (PM_IS_ACTIVE()) {
- printk(KERN_NOTICE apm: overridden by ACPI.\n);
- apm_info.disabled = 1;
- return -ENODEV;
- }
-#ifdef CONFIG_PM_LEGACY
- pm_active = 1;
-#endif
in apm.c and a similar piece of the ACPI initialisation that
prevented one initialising if the other had already initialised.
ah, gotcha. i'll take a closer look at that once in land in sunny
california. but not right away. :-)
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
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] [PATCH][RFC] Kill off legacy power management stuff.
On Friday 13 April 2007 1:22 am, Rafael J. Wysocki wrote: [appropriate CCs added] On Friday, 13 April 2007 02:33, Robert P. J. Day wrote: just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as DEPRECATED, while the help screen calls it obsolete. that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. It's been like this for a long long time. I think you're right that it can be dropped, but I don't know the details (eg. why it hasn't been dropped yet). I was just thinking about this the other day. I did an inventory of the actual _users_ of this code when I added the deprecation to Kconfig, and the only driver that would catch the notification was for some old m68k platform serial driver (Amiga?) ... that won't have changed. So the only reason not to remove it at that time was to make sure that folk had a chance to squawk about it going away. I think it's past time for this ancient stuff to vanish, since it's been obsolete for most of 2.5..2.6 and there's only that one event consumer left. Go for it! - Dave - 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/
[PATCH][RFC] Kill off legacy power management stuff.
just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as "DEPRECATED", while the help screen calls it "obsolete." that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. NOTE: this is not a working patch as it will fail on a MIPS or FR-V build, as i didn't remove the final vestiges from those two architectures. that would require simply killing off the remaining calls to pm_send_all(), that's all. (i think.) anyway, this has been compile-tested on x86 with "make allyesconfig." Documentation/pm.txt | 123 --- arch/i386/kernel/apm.c | 27 drivers/acpi/bus.c | 14 -- drivers/net/3c509.c |1 drivers/serial/68328serial.c | 59 - include/linux/pm.h | 70 --- include/linux/pm_legacy.h| 41 -- kernel/power/Kconfig | 10 - kernel/power/Makefile|1 kernel/power/pm.c| 209 - 10 files changed, 1 insertion(+), 554 deletions(-) diff --git a/Documentation/pm.txt b/Documentation/pm.txt index da8589a..d0fcfe2 100644 --- a/Documentation/pm.txt +++ b/Documentation/pm.txt @@ -36,93 +36,6 @@ system the associated daemon will exit gracefully. apmd: http://worldvisions.ca/~apenwarr/apmd/ acpid: http://acpid.sf.net/ -Driver Interface -- OBSOLETE, DO NOT USE! -* - -Note: pm_register(), pm_access(), pm_dev_idle() and friends are -obsolete. Please do not use them. Instead you should properly hook -your driver into the driver model, and use its suspend()/resume() -callbacks to do this kind of stuff. - -If you are writing a new driver or maintaining an old driver, it -should include power management support. Without power management -support, a single driver may prevent a system with power management -capabilities from ever being able to suspend (safely). - -Overview: -1) Register each instance of a device with "pm_register" -2) Call "pm_access" before accessing the hardware. - (this will ensure that the hardware is awake and ready) -3) Your "pm_callback" is called before going into a - suspend state (ACPI D1-D3) or after resuming (ACPI D0) - from a suspend. -4) Call "pm_dev_idle" when the device is not being used - (optional but will improve device idle detection) -5) When unloaded, unregister the device with "pm_unregister" - -/* - * Description: Register a device with the power-management subsystem - * - * Parameters: - * type - device type (PCI device, system device, ...) - * id - instance number or unique identifier - * cback - request handler callback (suspend, resume, ...) - * - * Returns: Registered PM device or NULL on error - * - * Examples: - * dev = pm_register(PM_SYS_DEV, PM_SYS_VGA, vga_callback); - * - * struct pci_dev *pci_dev = pci_find_dev(...); - * dev = pm_register(PM_PCI_DEV, PM_PCI_ID(pci_dev), callback); - */ -struct pm_dev *pm_register(pm_dev_t type, unsigned long id, pm_callback cback); - -/* - * Description: Unregister a device with the power management subsystem - * - * Parameters: - * dev - PM device previously returned from pm_register - */ -void pm_unregister(struct pm_dev *dev); - -/* - * Description: Unregister all devices with a matching callback function - * - * Parameters: - * cback - previously registered request callback - * - * Notes: Provided for easier porting from old APM interface - */ -void pm_unregister_all(pm_callback cback); - -/* - * Power management request callback - * - * Parameters: - * dev - PM device previously returned from pm_register - * rqst - request type - * data - data, if any, associated with the request - * - * Returns: 0 if the request is successful - * EINVAL if the request is not supported - * EBUSY if the device is now busy and cannot handle the request - * ENOMEM if the device was unable to handle the request due to memory - * - * Details: The device request callback will be called before the - * device/system enters a suspend state (ACPI D1-D3) or - * or after the device/system resumes from suspend (ACPI D0). - * For PM_SUSPEND, the ACPI D-state being entered is passed - * as the "data" argument to the callback. The device - * driver should save (PM_SUSPEND) or restore (PM_RESUME) - * device context when the request callback is called. - * - * Once a driver returns 0 (success) from a suspend - * request, it should not process any further requests or - * access the device hardware until a call to "pm_access" is made. - */ -typedef int (*pm_callback)(struct pm_dev *dev, pm_request_t rqst, void *data); - Driver Details -- This is just a quick Q as a stopgap
[PATCH][RFC] Kill off legacy power management stuff.
just something i threw together, not in final form, but it represents tossing the legacy PM stuff. at the moment, the menuconfig entry for PM_LEGACY lists it as DEPRECATED, while the help screen calls it obsolete. that's a good sign that it's getting close to the time for it to go, and the removal is fairly straightforward, but there's no mention of its removal in the feature removal schedule file. NOTE: this is not a working patch as it will fail on a MIPS or FR-V build, as i didn't remove the final vestiges from those two architectures. that would require simply killing off the remaining calls to pm_send_all(), that's all. (i think.) anyway, this has been compile-tested on x86 with make allyesconfig. Documentation/pm.txt | 123 --- arch/i386/kernel/apm.c | 27 drivers/acpi/bus.c | 14 -- drivers/net/3c509.c |1 drivers/serial/68328serial.c | 59 - include/linux/pm.h | 70 --- include/linux/pm_legacy.h| 41 -- kernel/power/Kconfig | 10 - kernel/power/Makefile|1 kernel/power/pm.c| 209 - 10 files changed, 1 insertion(+), 554 deletions(-) diff --git a/Documentation/pm.txt b/Documentation/pm.txt index da8589a..d0fcfe2 100644 --- a/Documentation/pm.txt +++ b/Documentation/pm.txt @@ -36,93 +36,6 @@ system the associated daemon will exit gracefully. apmd: http://worldvisions.ca/~apenwarr/apmd/ acpid: http://acpid.sf.net/ -Driver Interface -- OBSOLETE, DO NOT USE! -* - -Note: pm_register(), pm_access(), pm_dev_idle() and friends are -obsolete. Please do not use them. Instead you should properly hook -your driver into the driver model, and use its suspend()/resume() -callbacks to do this kind of stuff. - -If you are writing a new driver or maintaining an old driver, it -should include power management support. Without power management -support, a single driver may prevent a system with power management -capabilities from ever being able to suspend (safely). - -Overview: -1) Register each instance of a device with pm_register -2) Call pm_access before accessing the hardware. - (this will ensure that the hardware is awake and ready) -3) Your pm_callback is called before going into a - suspend state (ACPI D1-D3) or after resuming (ACPI D0) - from a suspend. -4) Call pm_dev_idle when the device is not being used - (optional but will improve device idle detection) -5) When unloaded, unregister the device with pm_unregister - -/* - * Description: Register a device with the power-management subsystem - * - * Parameters: - * type - device type (PCI device, system device, ...) - * id - instance number or unique identifier - * cback - request handler callback (suspend, resume, ...) - * - * Returns: Registered PM device or NULL on error - * - * Examples: - * dev = pm_register(PM_SYS_DEV, PM_SYS_VGA, vga_callback); - * - * struct pci_dev *pci_dev = pci_find_dev(...); - * dev = pm_register(PM_PCI_DEV, PM_PCI_ID(pci_dev), callback); - */ -struct pm_dev *pm_register(pm_dev_t type, unsigned long id, pm_callback cback); - -/* - * Description: Unregister a device with the power management subsystem - * - * Parameters: - * dev - PM device previously returned from pm_register - */ -void pm_unregister(struct pm_dev *dev); - -/* - * Description: Unregister all devices with a matching callback function - * - * Parameters: - * cback - previously registered request callback - * - * Notes: Provided for easier porting from old APM interface - */ -void pm_unregister_all(pm_callback cback); - -/* - * Power management request callback - * - * Parameters: - * dev - PM device previously returned from pm_register - * rqst - request type - * data - data, if any, associated with the request - * - * Returns: 0 if the request is successful - * EINVAL if the request is not supported - * EBUSY if the device is now busy and cannot handle the request - * ENOMEM if the device was unable to handle the request due to memory - * - * Details: The device request callback will be called before the - * device/system enters a suspend state (ACPI D1-D3) or - * or after the device/system resumes from suspend (ACPI D0). - * For PM_SUSPEND, the ACPI D-state being entered is passed - * as the data argument to the callback. The device - * driver should save (PM_SUSPEND) or restore (PM_RESUME) - * device context when the request callback is called. - * - * Once a driver returns 0 (success) from a suspend - * request, it should not process any further requests or - * access the device hardware until a call to pm_access is made. - */ -typedef int (*pm_callback)(struct pm_dev *dev, pm_request_t rqst, void *data); - Driver Details -- This is just a quick QA as a stopgap until a real driver
