.\" 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 "PM_SEND" "9" "09 October 2005" "" ""

.SH NAME
pm_send \- send request to a single device
.SH SYNOPSIS
"SYNOPSIS"
.sp
\fB
.sp
int pm_send  (struct pm_dev * \fIdev\fB, pm_request_t \fIrqst\fB, void * \fIdata\fB);
\fR
.SH "ARGUMENTS"
.TP
\fB\fIdev\fB\fR
device to send to
.TP
\fB\fIrqst\fB\fR
power management request
.TP
\fB\fIdata\fB\fR
data for the callback
.SH "DESCRIPTION"
.PP
Issue a power management request to a given device. The 
PM_SUSPEND and PM_RESUME events are handled specially. The
data field must hold the intended next state. No call is made
if the state matches.
.SH "BUGS"
.PP
what stops two power management requests occurring in parallel
and conflicting.
.SH "WARNING"
.PP
Calling pm_send directly is not generally recommended, in
particular there is no locking against the pm_dev going away. The
caller must maintain all needed locking or have 'inside knowledge'
on the safety. Also remember that this function is not locked against
pm_unregister. This means that you must handle SMP races on callback
execution and unload yourself.