I have a couple of comments and questions:

1) The core issue that needs to be solved concerns enabling/disabling the wake and wake/run GPEs, is this correct? As far as I can tell, the normal runtime GPEs do not need any change. The runtime GPEs are mostly defined by _Lxx/_Exx methods. The main exception to this is the EC, it has a GPE defined by the _GPE method under the EC device. Are there any issues here?

2) A large change that goes unmentioned is that the ACPICA core would no longer execute the _PRW control methods in order to discover the wake GPEs. This makes sense to me because it is clear that the bus scan code must execute these _PRW methods anyway, in order to obtain the wake GPE and other info. So it makes sense to just remove the _PRW and wake GPE management code from ACPICA and let the host OS and drivers handle this task, since it does it already anyway. Do I understand this correctly?

Thanks,
Bob

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
Sent: Tuesday, September 15, 2009 2:31 PM
To: Matthew Garrett
Cc: Moore, Robert; linux-acpi@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] ACPI: Add infrastructure for refcounting GPE
consumers

On Wednesday 02 September 2009, Matthew Garrett wrote:

quoted

ACPI GPEs may map to multiple devices. The current GPE interface only
provides a mechanism for enabling and disabling GPEs, making it difficult
to change the state of GPEs at runtime without extensive cooperation
between devices. Add an API to allow devices to indicate whether or not
they want their device's GPE to be enabled for both runtime and wakeup
events.

Looks fine in general, but are we going to do anything about unbalanced
puts?

Rafael