.\" This manpage has been automatically generated by docbook2man 
.\" from a DocBook document.  This tool can be found at:
.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
.\" Please send any bug reports, improvements, comments, patches, 
.\" etc. to Steve Cheng <steve@ggi-project.org>.
.TH "IBM_HANDLE_EVENTS" "9" "09 October 2005" "" ""

.SH NAME
ibm_handle_events \- listens for ACPI events for the IBM37D0 device
.SH SYNOPSIS
"SYNOPSIS"
.sp
\fB
.sp
void ibm_handle_events  (acpi_handle \fIhandle\fB, u32 \fIevent\fB, void * \fIcontext\fB);
\fR
.SH "ARGUMENTS"
.TP
\fB\fIhandle\fB\fR
an ACPI handle to the device that caused the event
.TP
\fB\fIevent\fB\fR
the event info (device specific)
.TP
\fB\fIcontext\fB\fR
passed context (our notification struct)
.SH "DESCRIPTION"
.PP
this method is registered as a callback with the ACPI
subsystem it is called when this device has an event to notify the OS of
.PP
The events actually come from the device as two events that get
synthesized into one event with data by this function.  The event
ID comes first and then the slot number that caused it.  We report
this as one event to the OS.
.PP
From section 5.6.2.2 of the ACPI 2.0 spec, I understand that the OSPM will
only re-enable the interrupt that causes this event AFTER this method
has returned, thereby enforcing serial access for the notification struct.