[patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[David Brownell]

Following are three patches for basic driver model wakeup flag support on
PCs.  I think the first two are nearly mergable.  The third previously broke
powerpc, so it's likely not yet mergeable ... the issue was arch-specific
differences in PCI initialization, someone else will need to solve them.

The patches are:

 - Define a platform_enable_wakeup() PM hook and use it with PCI.  (This
   might help OLPC with its non-RTC events...)

 - Make ACPI init and use driver model wakeup flags for the (motherboard)
   devices in its table ... and implement that new platform hook.  Now
   /proc/acpi/wakeup is almost purely informative.

 - Update PCI to set those flags on devices that can issue PME#/WAKE#;
   this gets overridden by ACPI, except for add-on cards.

Now, I've not yet made time to test whether the results _work_ but they
do look like they do the right thing.  (So far I've had lousy luck seeing
ACPI recover from wake events...)  The script I append (which I've posted
before) gave the following on one system:

	input      on  acpi_system:00/device:00/PNP0C0E:00
	           on  pci0000:00/0000:00:09.0
	lan        on  pci0000:00/0000:00:04.0
	hub        on  pci0000:00/0000:00:03.3/usb1
	usb_host   on  pci0000:00/0000:00:03.3
	hub        on  pci0000:00/0000:00:03.1/usb3
	usb_host   on  pci0000:00/0000:00:03.1
	input      on  pci0000:00/0000:00:03.0/usb2/2-1/2-1.1
	hub        on  pci0000:00/0000:00:03.0/usb2/2-1
	hub        on  pci0000:00/0000:00:03.0/usb2
	usb_host   on  pci0000:00/0000:00:03.0
	modem      on  pci0000:00/0000:00:02.7
	           on  pci0000:00
	tty        on  pnp0/00:08
	           on  pnp0/00:06
	           on  pnp0/00:05
	rtc        on  pnp0/00:02

Notice the external USB hub and keyboard.  The i8042 drivers don't
seem to list themselvs as input drivers in the usual way, or those
PS2 kbd/aux nodes would also say "input".  PCI 00:09.0 is an add-in
card, invisible without the third patch; it'd be a USB host if it
had a Linux driver.

- Dave

#!/bin/bash
# pm-wake

# classfilename *:* ==> $type
class_label ()
{
	case $1 in
	# recognize common types of wakeup-capable devices
	i2c-dev:*)	type="smbus     "; return 0;;
	input:*)	type="input     "; return 0;;
	mmc_host:*)	type="mmc_host  "; return 0;;
	net:eth*)	type="lan       "; return 0;;
	net:*)		type="net       "; return 0;;
	pcmcia_socket:*)type="pcmcia    "; return 0;;
	rtc:*)		type="rtc       "; return 0;;
	sound:*)	type="modem     "; return 0;;
	tty:*)		type="tty       "; return 0;;
	usb_host:*)	type="usb_host  "; return 0;;
	esac
	return 1
}

# interface_label $PATH ==> $type
interface_label ()
{
	for F in $(cd $1 >/dev/null 2>&1 ; echo *:*)
	do
		class_label $F && return
	done
}

# devtype $PATH ==> $type
devtype ()
{
	local F T

	# fixed length, currently ten spaces
	type=""

	for F in $(cd $1 >/dev/null 2>&1 ; echo *:*)
	do
		if [ ! -d "$1/$F" ]
		then
			break;
		fi

		# is this a usb interface?
		if [ -f $1/$F/bInterfaceClass ]
		then
			interface_label $1/$F && return
		fi

		case $F in
		# use interface's label if possible, else generic
		usb_device:*)
			read T < $1/maxchild
			if [ 0 -lt $T ]
			then
				type="hub       "
				return
			fi
			type="(usb)     "
			continue;;
		*:*)	class_label $F && return ;;
		esac

	done

	if [ "$type" = "" ]
	then
		for T in $(cd $1 >/dev/null 2>&1 ; echo fw-host*/ieee1394_host:*)
		do
			if [ ! -L "$1/$T" ]
			then
				break;
			fi
			type="firewire  "
			return
		done
	fi

	if [ "$type" = "" ]
		then
		type="          "
	fi
}

cd /sys/devices
for F in $(find * -name 'wakeup')
do
	# F=.../power/wakeup
	read value < $F
	if [ "$value" = "" ]
	then
		continue
	fi

	# F=...
	F=$(dirname $(dirname $F))
	devtype $F

	# for each entry that actually supports wakeup, one line with:
	#  - device type (if recognized)
	#  - wake on/OFF
	#  - /sys/devices/... path
	case "$value" in
	"disabled")	echo "$type OFF $F" ;;
	"enabled")	echo "$type on  $F" ;;
	esac
done

Re: [patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[David Brownell]

On Thursday 05 April 2007 12:48 pm, David Brownell wrote:
> 
> Now, I've not yet made time to test whether the results _work_ but they
> do look like they do the right thing.  (So far I've had lousy luck seeing
> ACPI recover from wake events...) 

Positive results to report here!  Some of the changes in 2.6.21 really
seem to have made a difference (my guess still being the ACPI IDE stuff).

I did a basic test with ohci-hcd loaded, plugging a device into the root
port when a system entered S1 ... it woke correctly and enumerated the
device, exactly as it should have done.  (But never did before!!)

Same thing with S3 ... except in that case the display was trashed; I
was able to ssh in, and switch the vt from raw console to X using the
PS2 keyboard, but that's about it.

I think it's fair to assume that other bugs would just be internal to
the USB stack -- e.g. remote wakeup, ehci-hcd, etc -- so this looks
fairly good to me now.

- Dave

Re: [patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[Matthew Garrett]

On Thu, Apr 05, 2007 at 04:20:59PM -0700, David Brownell wrote:

> Same thing with S3 ... except in that case the display was trashed; I
> was able to ssh in, and switch the vt from raw console to X using the
> PS2 keyboard, but that's about it.

Excellent news. Regarding the display, you may want to give vbetool a go 
- there's nothing in Linux to reinitialise the display hardware on most 
machines, and nothing in the ACPI spec that requires the firmware to.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[David Brownell]

On Thursday 05 April 2007 4:30 pm, Matthew Garrett wrote:
> On Thu, Apr 05, 2007 at 04:20:59PM -0700, David Brownell wrote:
> 
> > Same thing with S3 ... except in that case the display was trashed; I
> > was able to ssh in, and switch the vt from raw console to X using the
> > PS2 keyboard, but that's about it.
> 
> Excellent news. Regarding the display, you may want to give vbetool a go 
> - there's nothing in Linux to reinitialise the display hardware on most 
> machines, and nothing in the ACPI spec that requires the firmware to.

That system happens to be 32 bits, but a similar one is 64 bits ...
has vbetool been made to work on x86_64 yet?

- Dave

Re: [patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[Matthew Garrett]

On Thu, Apr 05, 2007 at 04:48:55PM -0700, David Brownell wrote:

> That system happens to be 32 bits, but a similar one is 64 bits ...
> has vbetool been made to work on x86_64 yet?

Yes, the latest version uses libx86 to execute BIOS code, which includes 
x86emu on machines which don't have vm86(). 
http://www.codon.org.uk/~mjg59/vbetool/ has the current code.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[Rafael J. Wysocki]

On Friday, 6 April 2007 01:54, Matthew Garrett wrote:
> On Thu, Apr 05, 2007 at 04:48:55PM -0700, David Brownell wrote:
> 
> > That system happens to be 32 bits, but a similar one is 64 bits ...
> > has vbetool been made to work on x86_64 yet?
> 
> Yes, the latest version uses libx86 to execute BIOS code, which includes 
> x86emu on machines which don't have vm86(). 
> http://www.codon.org.uk/~mjg59/vbetool/ has the current code.

Or look at http://en.opensuse.org/s2ram (it uses vbetool internally ;-)).

Re: x86_pc and ACPI support /sys/devices/.../wakeup

[Jordan Crouse]

On 05/04/07 12:48 -0700, David Brownell wrote:
> Following are three patches for basic driver model wakeup flag support on
> PCs.  I think the first two are nearly mergable.  The third previously broke
> powerpc, so it's likely not yet mergeable ... the issue was arch-specific
> differences in PCI initialization, someone else will need to solve them.
> 
> The patches are:
> 
>  - Define a platform_enable_wakeup() PM hook and use it with PCI.  (This
>    might help OLPC with its non-RTC events...)

Neat!  I'll looking forward to studying it in more detail.  I've also
forwarded this e-mail and the three patches to devel@laptop.org for their
perusual.

Jordan

Re: [patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[David Brownell]

So, ACPI team ... will there be any signed-off-by lines forthcoming?
On at least the first two patches, which are now known to work and
which don't raise any cross-platform issues.

And if you could share an explanation for why sometimes PCI bridges
seem to get marked as wakeup-capable in the ACPI tables, that would
be nice too ...

- Dave



On Thursday 05 April 2007 12:48 pm, David Brownell wrote:
> Following are three patches for basic driver model wakeup flag support on
> PCs.  I think the first two are nearly mergable.  The third previously broke
> powerpc, so it's likely not yet mergeable ... the issue was arch-specific
> differences in PCI initialization, someone else will need to solve them.
> 
> The patches are:
> 
>  - Define a platform_enable_wakeup() PM hook and use it with PCI.  (This
>    might help OLPC with its non-RTC events...)
> 
>  - Make ACPI init and use driver model wakeup flags for the (motherboard)
>    devices in its table ... and implement that new platform hook.  Now
>    /proc/acpi/wakeup is almost purely informative.
> 
>  - Update PCI to set those flags on devices that can issue PME#/WAKE#;
>    this gets overridden by ACPI, except for add-on cards.
> 
> Now, I've not yet made time to test whether the results _work_ but they
> do look like they do the right thing.  (So far I've had lousy luck seeing
> ACPI recover from wake events...)  The script I append (which I've posted
> before) gave the following on one system:
> 
> 	input      on  acpi_system:00/device:00/PNP0C0E:00
> 	           on  pci0000:00/0000:00:09.0
> 	lan        on  pci0000:00/0000:00:04.0
> 	hub        on  pci0000:00/0000:00:03.3/usb1
> 	usb_host   on  pci0000:00/0000:00:03.3
> 	hub        on  pci0000:00/0000:00:03.1/usb3
> 	usb_host   on  pci0000:00/0000:00:03.1
> 	input      on  pci0000:00/0000:00:03.0/usb2/2-1/2-1.1
> 	hub        on  pci0000:00/0000:00:03.0/usb2/2-1
> 	hub        on  pci0000:00/0000:00:03.0/usb2
> 	usb_host   on  pci0000:00/0000:00:03.0
> 	modem      on  pci0000:00/0000:00:02.7
> 	           on  pci0000:00
> 	tty        on  pnp0/00:08
> 	           on  pnp0/00:06
> 	           on  pnp0/00:05
> 	rtc        on  pnp0/00:02
> 
> Notice the external USB hub and keyboard.  The i8042 drivers don't
> seem to list themselvs as input drivers in the usual way, or those
> PS2 kbd/aux nodes would also say "input".  PCI 00:09.0 is an add-in
> card, invisible without the third patch; it'd be a USB host if it
> had a Linux driver.
> 
> - Dave
> 
> #!/bin/bash
> # pm-wake
> 
> # classfilename *:* ==> $type
> class_label ()
> {
> 	case $1 in
> 	# recognize common types of wakeup-capable devices
> 	i2c-dev:*)	type="smbus     "; return 0;;
> 	input:*)	type="input     "; return 0;;
> 	mmc_host:*)	type="mmc_host  "; return 0;;
> 	net:eth*)	type="lan       "; return 0;;
> 	net:*)		type="net       "; return 0;;
> 	pcmcia_socket:*)type="pcmcia    "; return 0;;
> 	rtc:*)		type="rtc       "; return 0;;
> 	sound:*)	type="modem     "; return 0;;
> 	tty:*)		type="tty       "; return 0;;
> 	usb_host:*)	type="usb_host  "; return 0;;
> 	esac
> 	return 1
> }
> 
> # interface_label $PATH ==> $type
> interface_label ()
> {
> 	for F in $(cd $1 >/dev/null 2>&1 ; echo *:*)
> 	do
> 		class_label $F && return
> 	done
> }
> 
> # devtype $PATH ==> $type
> devtype ()
> {
> 	local F T
> 
> 	# fixed length, currently ten spaces
> 	type=""
> 
> 	for F in $(cd $1 >/dev/null 2>&1 ; echo *:*)
> 	do
> 		if [ ! -d "$1/$F" ]
> 		then
> 			break;
> 		fi
> 
> 		# is this a usb interface?
> 		if [ -f $1/$F/bInterfaceClass ]
> 		then
> 			interface_label $1/$F && return
> 		fi
> 
> 		case $F in
> 		# use interface's label if possible, else generic
> 		usb_device:*)
> 			read T < $1/maxchild
> 			if [ 0 -lt $T ]
> 			then
> 				type="hub       "
> 				return
> 			fi
> 			type="(usb)     "
> 			continue;;
> 		*:*)	class_label $F && return ;;
> 		esac
> 
> 	done
> 
> 	if [ "$type" = "" ]
> 	then
> 		for T in $(cd $1 >/dev/null 2>&1 ; echo fw-host*/ieee1394_host:*)
> 		do
> 			if [ ! -L "$1/$T" ]
> 			then
> 				break;
> 			fi
> 			type="firewire  "
> 			return
> 		done
> 	fi
> 
> 	if [ "$type" = "" ]
> 		then
> 		type="          "
> 	fi
> }
> 
> cd /sys/devices
> for F in $(find * -name 'wakeup')
> do
> 	# F=.../power/wakeup
> 	read value < $F
> 	if [ "$value" = "" ]
> 	then
> 		continue
> 	fi
> 
> 	# F=...
> 	F=$(dirname $(dirname $F))
> 	devtype $F
> 
> 	# for each entry that actually supports wakeup, one line with:
> 	#  - device type (if recognized)
> 	#  - wake on/OFF
> 	#  - /sys/devices/... path
> 	case "$value" in
> 	"disabled")	echo "$type OFF $F" ;;
> 	"enabled")	echo "$type on  $F" ;;
> 	esac
> done
> 

Re: [patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[Zhang Rui]

Hi, David,

On Thu, 2007-04-05 at 12:48 -0700, David Brownell wrote:
> Following are three patches for basic driver model wakeup flag support on
> PCs.  I think the first two are nearly mergable.  The third previously broke
> powerpc, so it's likely not yet mergeable ... the issue was arch-specific
> differences in PCI initialization, someone else will need to solve them.
> 
> The patches are:
> 
>  - Define a platform_enable_wakeup() PM hook and use it with PCI.  (This
>    might help OLPC with its non-RTC events...)
> 
>  - Make ACPI init and use driver model wakeup flags for the (motherboard)
>    devices in its table ... and implement that new platform hook.  Now
>    /proc/acpi/wakeup is almost purely informative.
> 
Yes.
But /proc/acpi/wakeup is exporting the wrong information then.
I.e. when a physical device is set to may_wakeup, the corresponding GPE
will be enabled before entering a system sleep state.
But we always get status of the ACPI device is disabled
via /proc/acpi/wakeup, even if they could be enabled in
acpi_platform_enable_wakeup when suspending.

Thanks,
Rui

Re: [patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[David Brownell]

On Wednesday 18 April 2007 2:51 am, Zhang Rui wrote:
> Hi, David,
> 
> On Thu, 2007-04-05 at 12:48 -0700, David Brownell wrote:
> > Following are three patches for basic driver model wakeup flag support on
> > PCs.  I think the first two are nearly mergable.  The third previously broke
> > powerpc, so it's likely not yet mergeable ... the issue was arch-specific
> > differences in PCI initialization, someone else will need to solve them.
> > 
> > The patches are:
> > 
> >  - Define a platform_enable_wakeup() PM hook and use it with PCI.  (This
> >    might help OLPC with its non-RTC events...)
> > 
> >  - Make ACPI init and use driver model wakeup flags for the (motherboard)
> >    devices in its table ... and implement that new platform hook.  Now
> >    /proc/acpi/wakeup is almost purely informative.
> 
> Yes.
> But /proc/acpi/wakeup is exporting the wrong information then.

I'd say it's always exported the wrong information ... and
since those /proc files are going away, this there's no
strong need to continue following that path.

The literal meaning hasn't changed:  it still reflects the
value of the acpi_device.wakeup.state.enabled flag.  This
version of the patch avoided changing that meaning, to make
the compatibility story simpler.

But managing that ACPI flag through that procfs file has never
related well to what has been needed, or how non-ACPI systems
(e.g. without GPEs) behave.


> I.e. when a physical device is set to may_wakeup, the corresponding
> GPE will be enabled before entering a system sleep state.

The GPE is not always enabled when device_may_wakeup(dev)
returns true.  When drivers aren't set up to handle wakeups,
they won't make requests that boil down to enabling GPEs.

What /proc/acpi/wakeup shows in those cases is the state
of what I called "manual overrides".  Drivers that aren't
wakeup-aware will use those settings ... same as always.
(Unless userspace disables wakeup for that device through
the driver model.)


Wakeup-aware drivers will manage their GPEs directly, by
calling pci_enable_wake() -- or whatever -- according to
what device_may_wakeup(dev) tells them to do.

It's always been strange that /proc/acpi/wakeup flags just
ignored pci_enable_wake() directions from drivers.  From the
driver perspective, those flags have been sadly divorced from
what they needed to do ... I count that as a bug, so that
these two patches are a bugfix for pci_enable_wake() in the
context of ACPI.


> But we always get status of the ACPI device is disabled
> via /proc/acpi/wakeup, even if they could be enabled in
> acpi_platform_enable_wakeup when suspending.

If a driver enables wakeup earlier, then it would be
displayed earlier.  But of course, pci_enable_wake()
and similar wakeup control logic mostly triggers when
a system leaves (or reenters) the S0 state(*).

You're overlooking the flip side.  Previously, that
flag would be shown as "enabled" even when drivers
requested that their device NOT be a wakeup source.
Surely that has been equally wrong...

- Dave

(*) The separate issue of wanting devices enter e.g. a
    D3hot state to save power when the system is in S0,
    and then rely on wake events, still remains.

Re: [patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[Zhang Rui]

On Wed, 2007-04-18 at 09:33 -0700, David Brownell wrote:
> On Wednesday 18 April 2007 2:51 am, Zhang Rui wrote:
> > Hi, David,
> > 
> > On Thu, 2007-04-05 at 12:48 -0700, David Brownell wrote:
> > > Following are three patches for basic driver model wakeup flag support on
> > > PCs.  I think the first two are nearly mergable.  The third previously broke
> > > powerpc, so it's likely not yet mergeable ... the issue was arch-specific
> > > differences in PCI initialization, someone else will need to solve them.
> > > 
> > > The patches are:
> > > 
> > >  - Define a platform_enable_wakeup() PM hook and use it with PCI.  (This
> > >    might help OLPC with its non-RTC events...)
> > > 
> > >  - Make ACPI init and use driver model wakeup flags for the (motherboard)
> > >    devices in its table ... and implement that new platform hook.  Now
> > >    /proc/acpi/wakeup is almost purely informative.
> > 
> > Yes.
> > But /proc/acpi/wakeup is exporting the wrong information then.
> 
> I'd say it's always exported the wrong information ... and
> since those /proc files are going away, this there's no
> strong need to continue following that path.
> 
> The literal meaning hasn't changed:  it still reflects the
> value of the acpi_device.wakeup.state.enabled flag.  This
> version of the patch avoided changing that meaning, to make
> the compatibility story simpler.
> 
> > I.e. when a physical device is set to may_wakeup, the corresponding
> > GPE will be enabled before entering a system sleep state.
> 
> The GPE is not always enabled when device_may_wakeup(dev)
> returns true.  When drivers aren't set up to handle wakeups,
> they won't make requests that boil down to enabling GPEs.
> 
> What /proc/acpi/wakeup shows in those cases is the state
> of what I called "manual overrides".  Drivers that aren't
> wakeup-aware will use those settings ... same as always.
> (Unless userspace disables wakeup for that device through
> the driver model.)
> 

> Wakeup-aware drivers will manage their GPEs directly, by
> calling pci_enable_wake() -- or whatever -- according to
> what device_may_wakeup(dev) tells them to do.
> 

That's true.
Now acpi_device.wakeup.state.enabled is handled by
the wakeup-aware drivers of the "real" device.

I love the first two patches which help user space get rid of
this ACPI specific GPE control.

What I meant yesterday is that, as /proc/acpi/wakeup won't be
removed until we are able to map all the ACPI devices shown to
the real device node, if they have one,
it would be better if we either remove this GPE status information
from /proc/acpi/wakeup, or export something that really makes sense.
But now I think it's wrong. Because the other devices that are not
mapped yet still need this I/F to enable/disable GPE, we can not
remove/change this at the current stage.

Then the first two patches are OK with me.:)

Signed-off-by: Zhang Rui <rui.zhang@intel.com>

Thanks,
Rui

Re: [patch 2.6.21-rc5-git 0/3] x86_pc and ACPI support /sys/devices/.../wakeup

[David Brownell]

> > > > The patches are:
> > > > 
> > > >  - Define a platform_enable_wakeup() PM hook and use it with PCI.  (This
> > > >    might help OLPC with its non-RTC events...)
> > > > 
> > > >  - Make ACPI init and use driver model wakeup flags for the (motherboard)
> > > >    devices in its table ... and implement that new platform hook.  Now
> > > >    /proc/acpi/wakeup is almost purely informative.
> > > 
> > > Yes.
> > > But /proc/acpi/wakeup is exporting the wrong information then.
> > 
> > I'd say it's always exported the wrong information ... and
> > since those /proc files are going away, this there's no
> > strong need to continue following that path.
> > 
> > The literal meaning hasn't changed:  it still reflects the
> > value of the acpi_device.wakeup.state.enabled flag.  This
> > version of the patch avoided changing that meaning, to make
> > the compatibility story simpler.
> > 
> > > I.e. when a physical device is set to may_wakeup, the corresponding
> > > GPE will be enabled before entering a system sleep state.
> > 
> > The GPE is not always enabled when device_may_wakeup(dev)
> > returns true.  When drivers aren't set up to handle wakeups,
> > they won't make requests that boil down to enabling GPEs.
> > 
> > What /proc/acpi/wakeup shows in those cases is the state
> > of what I called "manual overrides".  Drivers that aren't
> > wakeup-aware will use those settings ... same as always.
> > (Unless userspace disables wakeup for that device through
> > the driver model.)
> > 
> 
> > Wakeup-aware drivers will manage their GPEs directly, by
> > calling pci_enable_wake() -- or whatever -- according to
> > what device_may_wakeup(dev) tells them to do.
> > 
> 
> That's true.
> Now acpi_device.wakeup.state.enabled is handled by
> the wakeup-aware drivers of the "real" device.
> 
> I love the first two patches which help user space get rid of
> this ACPI specific GPE control.

OK, good -- we're on the same page then!


> What I meant yesterday is that, as /proc/acpi/wakeup won't be
> removed until we are able to map all the ACPI devices shown to
> the real device node, if they have one,
> it would be better if we either remove this GPE status information
> from /proc/acpi/wakeup, or export something that really makes sense.

That's a bit of a sticky situation.  I went back and forth
on it a bit ... and eventually decided the simplest, and
clearest, approach was not to change how /proc/acpi/wakeup
handles those flags.


> But now I think it's wrong. Because the other devices that are not
> mapped yet still need this I/F to enable/disable GPE, we can not
> remove/change this at the current stage.

Exactly!


> Then the first two patches are OK with me.:)
> 
> Signed-off-by: Zhang Rui <rui.zhang@intel.com>

Great -- thanks!  I'll append that to these patches and ask
Andrew to merge them.

Given these and the PNP patches, most /proc/acpi/wakeup
devices will now get the right annotations.  There will still
be some puzzles to work out over time though ... the PS2
devices, some ACPI buttons, and PCI bridges.

Plus of course the PCI issues addressed in the third patch.
I switched things around a bit; maybe it's now easier to
have something that won't break powerpc.

- Dave

 
> Thanks,
> Rui
>