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@xxxxxxx] >Sent: Tuesday, September 15, 2009 2:31 PM >To: Matthew Garrett >Cc: Moore, Robert; linux-acpi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx >Subject: Re: [PATCH 1/3] ACPI: Add infrastructure for refcounting GPE >consumers > >On Wednesday 02 September 2009, Matthew Garrett wrote: >> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
