Moore, Robert wrote:
Rui, Thanks for examining this issue in detail. Your proposal to read/update/write the GPE enable register to simply disable one GPE sounds interesting. I want to think about this a bit more -- it has been a long time since I have looked closely at the GPE handling. With my discussions with Alexey Starikovskiy, we have concluded that there is something incorrect about the current design, where there exist windows where a GPE could come in with no driver available to handle it. I'm no longer intimate with the GPE handling model, but it would seem to me that GPEs should be treated like other interrupts where an interrupt level remains disabled until a driver is installed which in turn calls the kernel to install a handler for that interrupt. Only then can the interrupt be safely enabled. There is added complexity since drivers (with the exception of the Embedded Controller) do not handle GPEs directly; instead, an _Lxx/_Exx method is run which in turn (usually) generates a Notify on a device. We expect the device driver for the device to have installed a notify handler. So it would seem to me that it would be architecturally best to leave a GPE disabled until either a handler for the GPE is installed, or a notify handler is installed for the device associated with the GPE.
Currently, there is no way to tell if GPE hanler method would do Notify() to some device. There could be any number of calls to other methods, which might cause call of Notify(). So, probably this is a dead end. The only implementable way I see is to move enabling of _Lxx/_Exx GPEs to after bus scan, there we have devices autoloaded and installed. Regards, Alex. -- 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
